Sơ lược về requirement
Sơ lược về requirement
Hello anh em. Lần này mình sẽ note về các loại requirement mà anh em sẽ gặp trong suốt chặng hành trình của một BA chuyên nghiệp 
Lét xờ gâu anh em eiii!
Nội dung [Hide]
- 1. Requirement là gì?
- 2. Loại 1: Business Requirement
- 3. Loại 2: Stakeholder Requirement
- 4. Loại 3: Solution Requirement
- 4.1. Functional Requirement
- 4.2. Non-Functional Requirement
- 5. Loại 4: Transition Requirement
- 6. Tạm kết
1. Requirement là gì?
Đầu tiên mình sẽ lật ngược lại BABOK để xem Requirement được định nghĩa như thế nào.
Requirement is a usable representation of a need
BABOK v3.0
Usable tức là khả năng dùng được cho một mục đích nào đó.
Representation nghĩa là sự mô tả, sự diễn đạt.
Còn Need đơn giản là nhu cầu.
Nôm na, Requirement là sự diễn đạt cho một nhu cầu nào đó, nhưng sự diễn đạ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 các stakeholders đọc hiểu chẳng hạn.
Thực tế là không phải anh em nào trong team nào cũng hiểu rõ bản chất của chữ “Requirement”. Nhiều góc nhìn khác nhau là tốt, nhưng khi teamwork mà 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 chính xác.
Thực tế thì hầu như 96,69% những gì mà khách hàng nói đều chính là Requirement. Và đều thể hiện được một “usable representation of a need” như mình nói ở trên.
Ví dụ,
Ông CEO đi workshop bên châu Âu, thấy nhà máy người ta áp dụng IoT thứ dữ quá, ghê quá, hiệu quả quá. Về mới họp ban điều hành lại và nói rằng:
“Ô kê, tui muốn triển khai IoT cho nhà máy chúng ta, nó sẽ cắt giảm 40% chi phí nhân công và tăng 25% hiệu suất quản lý, 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 chính 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 công, tăng hiệu suất, với sự diễn đạt là 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 Mua Hàng mới bắt đầu liên hệ công ty Bosch để yêu cầu về giải pháp IoT.
Khi gặp team Bosch, ông Giám Đốc Mua Hàng mới phát biểu:
“Nè nha, tụi tui muốn triển khai IoT, mà phải xong trong vòng 2 năm rưỡi, ưu tiên trước mắt là Smart Metering và Asset Management, các module khác để sau cũng được…”
So 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ể nào đó (có thể là để đạt target của công ty trong vòng 5 năm tới…).
Dựa vào đó, yêu cầu cứ được dưa dần xuống các bộ phận trực tiếp làm việc, a usable representation of a need cứ thế sẽ được phát biểu rõ ràng và chi tiết hơn nữa.
Ví dụ các yêu cầu sẽ chi tiết đến mức như:
- Phần mềm quản lý phải được viết bằng .NET 4.5
- Toàn bộ Sensors và Actuators (cảm biến & thiết bị truyền động) phải do Bosch sản xuất và cung cấp.
- Report được render không quá 3 giây.
- Phải có ít nhất 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 cấp độ chi tiết khác nhau.
Nếu cùng gom nó lại và để chung vô một document thì sẽ rất… rối vô đối. Vì những requirement này có thể sẽ overlap lên nhau, khó theo dõi được cho cả BA lẫn khách hàng.
Do đó, IIBA mới chia nồi lẩu thập cẩm requirements ra thành 4 loại để anh em dễ quản lý. 4 loại đó đượ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 yêu cầu rất high-level từ phía khách hàng.
High-level nghĩa là nó rất TỔNG QUÁT, và thể hiện được mục tiêu của tổ chức. Một số dấu hiệu nhận biết đó là Business Requirement:
- Thường là các mục tiêu dài hạn của tổ chức
- Được áp dụng cho toàn tổ chức đó
- 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 các Manager,…
Đó 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 goals, 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 số ví dụ 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 50% tỉ lệ sai sót trong quá trình xử lý đơn hàng trước Q4/2019.
- Tăng 10% tỉ lệ khách quay lại mua hàng trong vòng 6 tháng áp dụng giải pháp CRM.
3. Loại 2: Stakeholder Requirement
Cái tên cũng khá rõ ràng, Stakeholder Requirement là những yêu cầu cụ thể của từng đối tượng Stakeholder. Những yêu cầu này phải thể hiện được cái need – nhu cầu cụ thể của các Stakeholder.
Anh em hãy chú ý đến các SME – Subject Matter Expert, đặc biệt là các Domain SME.
Vì các stakeholder này họ sẽ đưa ra requirement là những thứ, mà họ sẽ tương tác với hệ thống, dựa trên vai trò cụ thể của họ trong tổ chức.
Ví dụ anh em làm hệ thống quản lý nội bộ cho một công ty du lịch cỡ bự như Expedia đi chẳng hạn. Những Domain SME có thể anh em cần chú ý là Giám đốc chăm sóc khách hàng, Giám đốc nhân sự, Trưởng bộ phận điều phối tour…
Từ đó, chúng ta có một số ví dụ cho Stakeholder Requirement:
- From HR Director: 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 nhân viên phải được cập nhật 2 lần mỗi năm, hay hệ thống phải có chế độ tự động gia hạn hợp đồng lao động dựa trên những tùy chỉnh trước đó.
- From Customer Service Director: Hệ thống phải theo dõi được mức độ tương tác của Expedia với 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: Quy trình điều phối tour trên hệ thống sẽ không fix cố định, mà người dùng có thể tùy chỉnh linh động vì nhu cầu thực tế thay đổi rất nhiều 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ử Booking ngay trên hệ thống.
- Hoặc Sales Director nói rằng: Nhân viên kinh doanh phải dễ dàng kiểm tra được số tiền khách hàng đã chi ra trong tháng/ quý/ hoặc trong khoảng thời gian nhất định.
BABOK định nghĩa 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 rất ăn rơ và bổ trợ cho nhau. Theo nguyên tắc: Business Requirement chỉ đạt được khi Stakeholder Requirement đã đạt đượ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 thông tin khách hàng ==> Hệ thống phải quản lý được thông tin khách hàng
- Theo dõi được các hoạt động tương tác với khách hàng ==> Hệ thống phải lưu trữ được các hoạt động tương tác
- Hoặc Sales Team phải đo lường được giá trị mà từng khách hàng đóng góp cho công ty ==> 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à các Stakeholder Requirements của Domain SME là Sales Team.
Nếu chúng ta không đạt được những yêu cầu 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 các quyết định giúp tăng 10% tỉ lệ khách quay lại mua hàng cả.
4. Loại 3: Solution Requirement
Sau khi nắm được Business Requirement và Stakeholder Requirement, anh em sẽ đi tới bước nắm chi tiết được từng Solution Requirement.
Solution Requirement là những yêu cầu về khả năng và tiêu chuẩn mà giải pháp phải có để đạt được Business Requirement và Stakholder Requirement ở trên.
Chính xác thì các requirement này nó dây mơ rễ má, ăn nhậu và bỗ trợ cho nhau rất nhiều.
BABOK định nghĩa 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ả chi tiết, kỹ càng hơn bất kỳ các loại requirement nào khác có trong dự án. Và hơn hết, nó được chia làm 2 loại rõ rệt: một nói về capability và một nói về quality.
4.1. Functional Requirement
Functional Requirement là thứ nói về capability, tức là những 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 quan trọng ở dòng trên là Behavior và Information.
Behavior tức là hành vi của hệ thống, những gì hệ thống có thể làm được.
Ví dụ:
- Hệ thống có thể xuất báo cáo ra dạng Excel lẫn PDF
- Hệ thống có thể hoạt động offline khi không có internet
- Hệ thống có thể tích 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 mô tả 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 gì hệ thống có thể lưu trữ được.
Ví dụ:
- Hệ thống quản lý được danh sách các món ăn trong menu theo thời vụ
- Hệ thống có thể lấy được dữ liệu chuyến bay từ Airlines GDS (Global Distribution System)
- Hoặc hệ thống có thể tự động ghi nhận các hoạt động tương tác với khách hàng dựa trên các 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 gì, và biết được 50% Solution Requirement.
50% còn lại chính là nằm ở Non-Functional Requirement (NFR)
Tin mình đi, sẽ có không ít những anh em BA dễ dàng bỏ qua các NFR – một thứ quan trọng không kém Functional Requirement bên trên. Đặc biệt là đối với những anh em làm Outsource hay Service, như mình hehe.
Anh em đọc 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ể
- 23 loại Non-Functional Requirements trôi nổi ít ai để ý
Một ví dụ về NFR (Nguồn ảnh: CartoonStock.com)
5. Loại 4: Transition Requirement
Transition nghĩa là chuyển đổi, chuyển dịch từ một cái gì đó cũ sang một cái gì đó mới.
Transition Requirement là toàn bộ những yêu cầu của khách hàng liên quan tới việc áp dụng giải pháp vào tổ chức như thế nào cho hiệu quả. Tức là những yêu cầu liên quan tới việc chuyển đổi tổ chức từ trạng thái cũ, sang trạng thái mới.
Nguy hiểm hơn, anh em có thể nói là quá trình chuyển đổi từ As-is state thành To-be state, chuyển đổi từ lúc tổ chức chưa áp dụng hệ thống sang áp dụng hệ thống, hoặc từ lúc áp dụng hệ thống cũ sang lúc áp dụng 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
Facilitate có nghĩa là làm cho đơn giản, làm cho dễ dàng.
Facilitate, một từ rất quan trọng với anh em BA (nguồn ảnh: Cambridge Dicitonary)
Đây là một từ khóa cực kỳ quan trọng với BA, với mình nó giống như một kim chỉ nam để làm việc vậy. Càng làm thì mọi thứ phải càng đơn giản, chứ càng làm mà càng phức tạp hơn thì có vẻ công việc mình làm không hiệu quả cho lắm.
Còn cụm “but which are not needed once the change is complete” nghĩa là BABOK muốn nhấn mạnh: transition requirement chỉ quan trọng trong lúc triển khai, lúc đưa giải pháp vào sử dụng thực tế. Còn khi áp dụng xong xuôi, mọi thứ chạy êm ru rồi thì mớ transition requirement này không còn quan trọng nữa.
Một số ví dụ về Transition Requirement từ phía khách hàng cho anh em dễ hình dung:
- Ít nhất phải có 3 buổi đào tạo sử dụng hệ thống cho mỗi phòng ban
- Toàn bộ các Test Case phải được chạy test 2 lần bởi khách hàng trước khi Go-live
- Giải pháp phải được xây dựng trên nền Java 64-bit.
- Hoặc thậm chí có yêu cầu như: bộ phận ABC phải duy trì hoạt động trong suốt quá trình triển khai dự án
- Hoặc đối với một số dự án ở Nhật: Nếu có thiên tai (động đất, sóng thần…) xảy ra, dự án sẽ tạm hoãn cho đến khi tổ chức hoạt động trở lại và không phải chịu bất cứ chi phí nào cho việc hoãn dự án.
6. Tạm kết
Hi vọng qua note này anh em sẽ hình dung rõ hơn về requirement, cũng như các loại của nó.
Đây là 4 loại requirement. Theo trình tự thì thường đầu dự án anh em sẽ nhận được các yêu cầu rất sơ khởi như Business Requirement hoặc một vài Stakeholder Requirement.
Theo thời gian, anh em sẽ bắt đầu moi móc, cùng làm với team, với khách hàng để ra được những Solution Requirement sát sườn nhất, phù hợp với cả 2 bên. Khi đó mình mới có cái nhìn rõ ràng nhất về những thứ cần phải làm.
Còn Transition Requirement có thể có hoặc không. Vì thường nó sẽ được xem là “additional requirement” trong dự án.
Để hiểu rõ hơn về requirement, anh em có thể đọc thêm các notes về:
Bái baiii, hẹn gặp anh em ở các bài notes khác về requirement trong tương lai. Anh em cùng chờ nhé 
See yaaaa!!!
Nguồn: thinhnotes.com
