Requirement là gì là một trong những từ khóa được search nhiều nhất google về chủ đề Requirement là gì. Trong bài viết này, các bạn hãy cùng ATPCARE.VN sẽ cùng tìm hiểu về chủ đề “Requirement là gì? Hiểu về khái niệm này sao cho đúng”
1. Requirement là gì?
Trước tiên mình sẽ lật trái lại BABOK để coi Requirement được khái niệm như thế nào.
Usable có nghĩa là khả năng sử dụng được cho một mục tiêu nào đấy.
Representation nghĩa là sự biểu đạt, sự mô tả.
Còn Need giản đơn là nhu cầu.
Nôm na, Requirement là sự mô tả cho một nhu cầu gì đó, tuy nhiên sự mô tả này phải rõ ràng nhé anh em, để còn được sử dụng cho nhiều mục đích sau đó, như để làm document, cho những stakeholders đọc hiểu chẳng hạn.
Thực tế là không hẳn anh em nào tại team nào thì cũng hiểu rõ thực chất của chữ “Requirement”. Nhiều góc Quan sát không giống nhau là tốt, nhưng khi teamwork mà dường như không cùng Nhìn chung một hướng thì dễ tèo lắm.
…
tuy nhiên, đó cũng chỉ là lý thuyết để anh em BA nắm một cách đúng chuẩn.
Thực tế thì gần như 9,69% những gì mà quý khách hàng nói đều chính là Requirement. & đều thể hiện được một “usable representation of a need” như mình nói ở trên.
VD,
Ông CEO đi workshop bên Âu lục, thấy nhà máy người ta áp dụng IoT thứ dữ quá, ghê quá, hiệu suất cao quá. Về mới họp ban điều hành lại và nói rằng:
“Ô kê, tui mong muốn triển khai IoT cho nhà máy chúng ta, nó sẽ cắt giảm 40% chi phí nhân lực & tăng 25% hiệu năng cai quản, anh em thấy thế nào”.
Một câu phát biểu rất đại khái, chung chung như vầy đó là requirement. Vì đơn giản nhu cầu của ổng đã rõ ràng, là muốn cắt giảm phí nhân lực, tăng hiệu suất, với sự mô tả là mong muốn áp dụng IoT vào hoạt động của nhà máy.
Từ yêu cầu trên của CEO, ông Giám Đốc đặt đơn hàng mới mở đầu liên lạc công ty Bosch để đòi hỏi về giải pháp IoT.
Khi gặp team Bosch, ông Giám Đốc đặt hàng mới phát biểu:
“Nè nha, tụi tui mong muốn khai triển IoT, mà phải xong trong vòng 2. năm rưỡi, ưu tiên trước mắt là Smart Metering & Asset Management, các module khác để sau cũng được…”
so sánh với câu phát biểu của anh CEO thì câu này của anh Procurement Director có vẻ chi tiết hơn chút xíu.
Ảnh diễn đạt rõ ảnh cần gì trước, cần gì sau, cho một mục đích cụ thể gì đấy (có thể là để đạt target của doanh nghiệp tại vòng 5 năm tới…).
phụ thuộc đấy, đòi hỏi cứ được dưa dần xuống những bộ phận trực tiếp thao tác, a usable representation of a need cứ thế sẽ được phát biểu rõ ràng và chi tiết thêm nữa.
VD các yêu cầu sẽ chi tiết đến mức như:
- ứng dụng quản lý phải được viết bằng .NET 4.5
- toàn bộ Sensors & Actuators (cảm biến và dòng thiết bị truyền động) phải do Bosch chế tạo & bổ sung.
- Report được render không quá 3. giây.
- nên có tối thiểu 2 tuần đào tạo sử dụng cho người dùng là nhân công nhà máy
Anh em thấy những ví dụ trên đều là những requirement, nhưng với mức độ chi tiết không giống nhau.
nếu như cùng gom nó lại & để chung vô một document thì sẽ rất… rối vô đối. Vì các requirement này có thể sẽ overlap lên nhauvà khó theo dõi được cho cả BA lẫn khách hàng.
vì lẽ đó, IIBA mới chia nồi lẩu thập cẩm requirements ra thành 4 loại để anh em dễ cai quản. 4 loại đấy được chia theo vòng tròn công việc của BA như sau. 
2. Loại 1 Business Requirement
Business Requirement là những đòi hỏi rất high-level từ phía quý khách hàng.
High-level nghĩa là nó rất TỔNG QUÁT, & thể hiện được mục đích của tổ chức. một số dấu hiệu nhận biết chính là Business Requirement:
- thường hay là những mục đích lâu dài của tổ chức
- Được ứng dụng cho toàn tổ chức đấy
- và thường được các nhân vật chủ chốt phát biểu, như các nhân vật C-Level, hoặc những Manager,…
chính là nói theo kiểu bình dân – dễ hiểu. Còn nói theo kiểu pho mồ như BABOK thì Business Requirement nghĩa là:
Business Requirement is statements of goalsvà objectives, and outcomes that describe why a change has been initiated.
They can apply to the whole of an enterprise, a business area, or a specific initiative.
BABOK v3.0
một vài VD về Business Requirement để anh em dễ hình dung:
- áp dụng thành công hệ thống IoT cho nhà máy Hà Nam, Bình Dương và Bắc Ninh trước Q3/2025.
- Giảm một nửa tỉ lệ sai sót trong lúc xử lý đơn hàng trước Q4/2019.
- Tăng 10% tỉ lệ khách quay lại đặt hàng tại vòng 6 tháng ứng dụng chiến thuật CRM.
3. Loại 2 Stakeholder Requirement
Cái tên cũng rất rõ ràng, Stakeholder Requirement là những yêu cầu cụ thể của từng đối tượng Stakeholder. các đòi hỏi này phải thể hiện ra được cái need – nhu cầu cụ thể của những Stakeholder.
Anh em hãy chú ý đến các SME – Subject Matter Expert, đặc biệt là những Domain SME.
Vì các stakeholder này họ sẽ đưa ra requirement là các thứ, mà người ta sẽ tương tác với hệ thống, dựa trên vai trò chi tiết của họ trong tổ chức.
VD anh em làm hệ thống quản lý nội bộ cho một doanh nghiệp du lịch cỡ bự như Expedia đi chẳng hạn. những Domain SME có khả năng anh em cần chú ý là Giám đốc hỗ trợ khách hàng, Giám đốc nhân sự, Trưởng bộ phận điều phối tour…
Từ đấy, chúng ta có 1 số VD cho Stakeholder Requirement:
- From HR Director: khối hệ thống phải tuân thủ đúng bộ policy của Expedia, bao gồm quy trình tuyển dụng phải qua 5 vòng, lương chuyên viên phải được cập nhật 2. lần mỗi năm, hay khối hệ thống nên có chế độ tự động gia hạn Hợp Đồng lao động dựa trên các tùy chỉnh trước đây.
- From Customer Service Director: hệ thống phải theo dõi được mức độ tương tác của Expedia với quý khách hàng, và cho ra số liệu cụ thể theo đúng form mẫu mà Expedia đang theo dõi hàng ngày bằng Excel.
- From Tour Coordinator: tiến trình điều phối tour trên hệ thống sẽ không fix cố định, mà người sử dụng có thể tùy chỉnh hoạt bát vì nhu cầu thực tế điều chỉnh không ít theo thời vụ.
- Hoặc đơn giản hơn, IT Manager nói rằng: nhân viên kinh doanh phải quản lý và xem được lịch sử vẻ vang Booking ngay trên khối hệ thống.
- Hoặc Sales Director nói rằng: nhân viên kinh doanh phải dễ dàng kiểm duyệt được số tiền khách hàng đã chi ra tại tháng/ quý/ hoặc tại khoảng thời gian nhất định.
BABOK khái niệm Stakeholder Requirement như sau:
Stakeholder requirements describe the needs of stakeholders that must be met in order to achieve the business requirements.
BABOK v3.0
Business Requirement và Stakeholder Requirement phải vô cùng ăn rơ & bổ trợ cho nhau. Theo nguyên tắc: Business Requirement chỉ đạt cho được khi Stakeholder Requirement đã đạt cho được.
ví dụ Business Requirement là “tăng 10% tỉ lệ khách quay lại mua hàng”, thì Sales Team phải:
- Biết được nội dung quý khách hàng ==> khối hệ thống phải quản lý được thông tin quý khách hàng
- Theo dõi được những chuyển động tương tác với quý khách hàng ==> khối hệ thống phải lưu trữ được các chuyển động tương tác
- Hoặc Sales Team phải thống kê được giá trị mà từng quý khách hàng đóng góp cho doanh nghiệp ==> hệ thống phải tính toán được chỉ số Customer Lifetime Value (CLV) cho từng khách hàng chẳng hạn.
đó rõ ràng là những Stakeholder Requirements của Domain SME là Sales Team.
nếu chúng ta không đạt cho được các đòi hỏi này, thì rất khó, hoặc hầu như là không thể để đạt được Business Requirement [tăng 10% tỉ lệ khách quay lại mua hàng]. Vì rõ ràng Sales Team chẳng có thông tin gì bám víu vào để ra những quyết định giúp tăng 10% tỉ lệ khách quay lại đặt đơn hàng cả.
4. Loại 3 Solution Requirement
Khi mà đã nắm được Business Requirement & Stakeholder Requirement, anh em sẽ đi tới bước nắm cụ thể được từng Solution Requirement.
Solution Requirement là những yêu cầu về năng lực & chuẩn mực mà phương án phải có để đạt được Business Requirement & Stakholder Requirement ở trên.
đúng chuẩn thì những requirement này nó dây mơ rễ má, nhậu nhẹt và bỗ trợ cho nhau không hề ít.
BABOK khái niệm Solution Requirement như sau:
Solution requirements describe the capabilities and qualities of a solution that meets the stakeholder requirements
BABOK v3.0
Solution Requirement là thứ được mô tả cụ thể, kỹ lưỡng hơn bất cứ các loại requirement nào khác có tại dự án. và hơn hết, nó được chia làm 2 loại rõ rệt: một đề cập về capability và một nói về quality.
4.1. Functional Requirement
Functional Requirement là thứ nói về capability, có nghĩa là các thứ mà hệ thống làm được, nôm na là như vậy.
BABOK v3.0 định nghĩa như sau: Functional Requirements describe the capabilities that a solution must have in terms of the behavior and information that the solution will manage.
Mình có highlight 2. từ khóa đặc biệt ở dòng trên là Behavior & Information.
Behavior có nghĩa là hành vi của hệ thống, những gì hệ thống có thể làm được.
Ví dụ:
- khối hệ thống có khả năng xuất báo cáo ra dạng Excel lẫn PDF
- khối hệ thống có khả năng hoạt động offline khi không có internet
- khối hệ thống có khả năng tích phù hợp với Microsoft Project để thêm Gantt chart vào một record bất kỳ
- Hoặc đơn gản là việc biểu đạt khối hệ thống có thể Cread/ Read/ Update/ Delete dữ liệu Đơn hàng.
Còn Information tức là dữ liệu của hệ thống, những cái gì hệ thống có khả năng lưu trữ được.
Ví dụ:
- hệ thống quản lý được danh sách những món ăn trong menu theo thời vụ
- khối hệ thống có thể lấy được dữ liệu chuyến bay từ Airlines GDS (Global Distribution System)
- Hoặc khối hệ thống có thể tự động ghi nhận những hoạt động tương tác với quý khách hàng dựa trên những API có sẵn…
4..2. Non-Functional Requirement
Chúng ta đã biết được Functional Requirement, biết được hệ thống có thể làm những gì, và biết được một nửa Solution Requirement.
50% còn lại đó là nằm ở Non-Functional Requirement (NFR)
Tin mình đi, sẽ có khá nhiều những anh em BA dễ dàng bỏ lỡ các NFR – một thứ đặc biệt không kém Functional Requirement bên trên. đặc biệt là đối với các anh em làm Outsource hay Service, như mình hehe.
Anh em xem thêm bài dưới đây mình có note về Non-Functional Requirements nhé.
- Non-Functional Requirements và chuyện về cái xô bể
- 2 loại Non-Functional Requirements trôi nổi ít ai để ý
5. Loại 4 Transition Requirement
Transition nghĩa là chuyển đổi, dịch chuyển từ một cái nào đấy cũ sang một chiếc nào đó mới.
Transition Requirement là tất cả những đòi hỏi của khách hàng liên quan tới việc ứng dụng phương án vào tổ chức như làm thế nào để cho hiệu suất cao. tức là các đòi hỏi liên quan tới việc chuyển đổi tổ chức từ tình trạng cũ, sang trạng thái mới.
nguy nan hơn, anh em có thể nói là quá trình chuyển đổi từ As-is state thành To-be statevà chuyển đổi từ lúc tổ chức chưa ứng dụng hệ thống sang áp dụng khối hệ thống, hoặc từ lúc áp dụng hệ thống cũ sang lúc áp dụng khối hệ thống mới…
BABOK định nghĩa Transition Requirement như sau:
Transition requirements describe the capabilities that the solution must have and the conditions the solution must meet to facilitate transition from the current state to the future state, but which are not needed once the change is complete.
BABOK v3.0
Nguồn: Thinhnotes.com