1. What is Requirement?

Theo BABOK 3.0, họ đang định nghĩa Requirement là

A requirement is a usable representation of a need.

Chúng ta có thể hiểu đơn giản, Requirement là sự diễn đạt (rõ ràng) cho một nhu cầu nào đó, vàđượ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.

Requirement có nhiều cấp độ chi tiết khác nhau. Từ high level đến detail level. Dễ hiểu là từ mức chung chung đi đến mức độ cụ thể.

Trong BABOK 3.0 cũng đã chia requirement thành 4 cấp độ khác nhau, mỗi cấp độ sẽ thể hiện độ chi tiết khác nhau từ Formal đến Informal, từ mức độ tổng quát đến chi tiết cụ thể để làm rõ ra nhu cầu của stakeholder.

4 cấp độ của Requirement, cụ thể là:

1. Business Requirements
2. Stakeholder Requirements
3. Solution Requirements
4. Transition Requirements.

Vậy chúng ta, cùng tìm hiểu kỹ xem chi tiết của 4 cấp độ này thể hiện điều gì, ở đây BA join vào cần lấy thông tin gì nhen.

2. What is Business Requirements?

Theo BABOK 3.0, họ đang định nghĩa Business Requirement là

statements of goals, objectives, and outcomes that describe why a change has been initiated.

Chúng ta có thể hiểu đơn giản, Business Requirement là các yêu cầu high-level (tổng quan) từ phía khách hàng, nó thể hiện được mục tiêu của cty. Và có thể áp dụng cho toàn bộ của một doanh nghiệp, một lĩnh vực kinh doanh hoặc một sáng kiến ​​cụ thể.

Các yêu cầu ở mức “business requirements”, thể hiện ở các chi tiết đó là:

• Là các mục tiêu dài hạn, ngắn hạn của cty.

• Áp dụng cho toàn cty, hoặc 1 sáng kiến hoặc lĩnh vực ​​cụ thể.

• Xuất phát từ người đứng đầu cty hoặc các big boss, như các Manager, BOD, CEO,…

Một vài ví dụ, để chúng ta hiểu hơn về Business Requirements:

• Giảm tỷ lệ crash app trong H1-2024.
• Giảm tỷ lệ down server trong H1-2024.
• Tracking link, report không timeout quá 30p trong H1-2023.
• Revenue affiliate Geo VN > 23k$.
• ….

Business requirements thường được documented lại dưới dạng tài liệu là Business Requirements Document (BRD).

3. What is Stakeholder Requirements?

Theo BABOK 3.0, họ đang định nghĩa,

describe the needs of stakeholders that must be met in order to achieve the business requirements.

Chúng ta có thể hiểu đơn giản, Stakeholder Requirements là mô tả nhu cầu cụ thể của từng đối tượng (Stakeholder) phải đáp ứng được yêu cầu cty.

Một bước quan trọng và khó khăn trong việc thiết kế một phần mềm là xác định xem người dùng thực sự muốn nó làm gì. Điều này là do người dùng thường không thể truyền đạt toàn bộ nhu cầu và mong muốn của họ, đồng thời thông tin họ cung cấp cũng có thể không đầy đủ, không chính xác và gây mâu thuẫn. Trách nhiệm hiểu rõ những gì Stakeholder mong muốn phụ thuộc về BA. Đây là lý do tại sao các yêu cầu của người dùng thường được coi là tách biệt với các yêu cầu về giải pháp hoặc hệ thống. BA cần phân tích cẩn thận các yêu cầu của người dùng và cẩn thận xây dựng các yêu cầu hệ thống chất lượng cao để đảm bảo rằng các yêu cầu đó đáp ứng các đặc tính chất lượng nhất định.

Stakeholder Requirement thường được ghi lại bằng cách sử dụng use cases, scenarios, user stories, …

User requirements thường được documented dưới dạng tài liệu là User Requirements Document (URD).

4. What is Solution Requirements?

Theo BABOK 3.0, họ đang định nghĩa,

describe the capabilities and qualities of a solution that meets the stakeholder requirements.

Chúng ta có thể hiểu đơn giản, Solution Requirements 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.

Họ cung cấp mức độ chi tiết thích hợp để cho phép phát triển và thực hiện giải pháp. Solution Requirements có thể được chia thành hai mục:

1. Functional requirement
2. Nonfunctional requirement

4.1 Functional requirement

Theo BABOK 3.0, họ đang định nghĩa,

describe the capabilities that a solution must have in terms of the behavior and information that the solution will manage

Chúng ta có thể hiểu đơn giản, Functional requirement là mô tả các khả năng mà một giải pháp có thể làm được về mặt (hành vi) Behavior và (thông tin) Information.

• Behavior là hành vi của hệ thống, những gì hệ thống có thể làm được. Ví dụ: mô tả hệ thống có thể Cread/ Read/ Update/ Delete campaign.
• Information 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 campaign.

Ví dụ: một hệ thống có thể được yêu cầu nhập và in ước tính chi phí.

4.2 Nonfunctional requirement = Quality of Services.

Theo BABOK 3.0, họ đang định nghĩa,

do not relate directly to the behavior of functionality of the solution, but rather describe conditions under which a solution must remain effective or qualities that a solution must have

Chúng ta có thể hiểu đơn giản, Nonfunctional requirement là mô tả không liên quan trực tiếp đến hoạt động chức năng của giải pháp, mà là mô tả các điều kiện theo đó một giải pháp phải duy trì hiệu quả hoặc chất lượng mà một giải pháp phải có

Dưới đây là danh sách một số loại Nonfunctional requirement phổ biến:

• Availability
• Business continuity
• Compliance
• Interoperability
• Maintainability
• Performance
• Usability

Ví dụ: một hệ thống cho phép upload image, định dạng là PNG,GIF, giới hạn dung lượng là 2M.

5. What is Transition requirements

Theo BABOK 3.0, họ đang định nghĩa,

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.

Chúng ta có thể hiểu đơn giản, transition requirement là toàn bộ những yêu cầu của khách hàng về việc áp dụng giải pháp vào tổ chức như thế nào cho hiệu quả. Mục đích là 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… 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ế.

Ví dụ:

• Demo sử dụng tính năng cho stakeholader trước khi bàn giao sản phẩm.
• Toàn bộ testcase cần phải chạy 2 lần trước khi Deploy sản phẩm lên Production.

Đến đây là hết rồi, cảm ơn mn đã đọc đến đây ạ!!!