Các loại Requirement và Output của Business Analyst (BA)

Khi đọc các mô tả yêu cầu từ nhà tuyển dụng, hoặc đi phỏng vấn thì các bạn sẽ gặp các yêu cầu lúc thì BA biết BRD, lúc thì SRS, lúc thì User Story…

Đôi lúc công việc đó bạn đã làm, tài liệu dạng đó đã viết nhưng đâu đó tên gọi có thể khác nên làm cho bạn lúng túng không biết trả lời hoặc tự tin trả lời sao cho đúng, cho tổng quát nhất.

Về cơ bản thì Yêu cầu đầu vào của BA thì thường chia làm 4 loại lớn đó là:

1. Business requirement,
2. Stakeholder Requirement,
3. Solution Requirement,
4. Transition requirements.

Trong đó có 3 loại phổ biến mà Business Analyst thường gặp trong dự án: 

1. Business requirement.

• Đây là yêu cầu ở tầng cao nhất, phổ quát nhất. Business requirement sẽ mô tả về yêu cầu ở tầng business, đưa ra lí do cần sự thay đổi.

Business requirement có thể áp dụng ở tầng chiến lược của toàn bộ tổ chức và doanh nghiệp. Đây là cơ sở cốt lõi nhất phát triển các tầng yêu cầu tiếp theo. Tức là kim chỉ nam cho việc phát triển các loại yêu cầu phía sau. Là một người BA thực sự, bạn cần tìm hiểu và đặt câu hỏi Why? Tại sao lại cần sự thay đổi này? Tại sao lại cần yêu cầu này?

• Output: của loại yêu cầu này đó là BRD, Product Vision, Business Case đối với dự án phát triển theo mô hình Waterfall. Còn trong dự án phát triển theo Agile/Scrum đó có thể là Epic, Feature hay Scope Document.
• Những tài liệu này thường phù hợp với các bên tham gia dự án như Product Owner, Sponsor, BOD của dự án. Các loại tài liệu này mang tính tổng quan về mặt Business và nghiệp vụ.

2. Stakeholder requirement

• Stakeholder requirement hay còn gọi là User Requirement là tập hợp những yêu cầu của các bên liên quan đến dự án để đạt được các yêu cầu kinh doanh (Business requirement).

Đây có thể được cho là cầu nối giữa yêu cầu kinh doanh và yêu cầu mặt giải pháp. User Requirement mô tả cụ thể và chi tiết những yêu cầu nghiệp vụ của từng bên liên quan.

• Output: Trong các dự án phát triển theo mô hình Waterfall thì đó có thể là User Requirement Document (URD), Functional Requirement Document (FRD). Đối với dự án phát triển theo mô hình Agile/Scrum thì đó là User Story, Product Backlog, Product requirement document.

3. Solution Requirement

• Solution requirement miêu tả chức năng và phẩm chất cần có của hệ thống. Nó sẽ có 2 mục quan trọng chính mà bạn cần phải đề cập đến đó là Functional requirement và Non-functional requirement. Tức là yêu cầu chức năng và yêu cầu phi chức năng của hệ thống.​

Solution requirement sẽ cung cấp những thông tin chi tiết nhất để đội phát triển sản phẩm triển khai giải pháp. Đối tượng sử dụng là đội kĩ thuật phát triển sản phẩm.

• Functional requirement: Tức là yêu cầu về mặt chức năng của hệ thống. Tức là hệ thống làm được những chức năng gì?
• Non-Functional requirement: Yêu cầu phi chức năng, là những yêu cầu mang lại giá trị tăng thêm cho hệ thống. Ví dụ như hiệu suất, bảo mật, tính dễ dùng.
• Output: SRS, NFR, UC hay User Story detail, Acceptance Criteria, Wireframe, Prototype.

Tuy thuộc vào đối tượng sử dụng bộ tài liệu và mục tiêu của tài liệu mà BA sẽ lựa chọn mô hình và hình thức mô tả phù hợp.

• Sâu hơn về Functional requirement và Non-Functional requirement: https://bit.ly/32EN6j3
• Đọc thêm về các chủ đề BA: https://bit.ly/30zyqz0

Để hiểu và làm được chi tiết những công việc BA bạn có thể tham gia chương trình đào tạo đăc biệt của BAC, Khóa học: Phân tích nghiệp vụ phần mềm cơ bản – Chương trình chuẩn IIBA

Nhu cầu đào tạo doanh nghiệp

BAC là đơn vị đào tạo BA đầu tiên tại Việt Nam. Đối tác chính thức của IIBA quốc tế. Ngoài các khóa học public, BAC còn có các khóa học in house dành riêng cho từng doanh nghiệp. Chương trình được thiết kế riêng theo yêu cầu của doanh nghiệp, giúp doanh nghiệp giải quyết những khó khăn và tư vấn phát triển.