Phân biệt các tài liệu BRD, SRS và FSD (FS)
Bạn đã từng nghe về tài liệu Use Case, SRS (Spec). Nhưng như thế là chưa đủ. Đối với những dự án lớn, hoặc lộ trình triển khai dài như ERP, các hệ thống phần mềm chuyển đổi số thì một BA chuyên nghiệp sẽ phải chuẩn bị ít nhất 5-10 tài liệu, trong đó có BRD và FSD.

Theo thông kê của TheBusinessAnalyst, có 9 loại tài liệu QUAN TRỌNG được tạo bởi bất cứ BA nào.
1. Project Vision Document
2. Requirement Management Plan
3. Use Cases
4. User Stories
5. Business Requirement Document (BRD)
6. Requirement Traceability Matrix (RTM)
7. Functional Requirement Specification (FRS) / Functional Specification Document (FSD)
8. System Requirement Specification (SRS) / System Requirement Document (SRD)
9. Test Case


Tất cả các tài liệu nói trên đều xoay quanh các yêu cầu (Requirements) nhìn ở các góc độ khác nhau: góc độ nghiệp vụ, góc độ kỹ thuật, góc độ nhà đầu tư, góc độ người dùng cuối và cả góc độ phát triển kinh doanh của doanh nghiệp. Thông thường có 4 loại requirement: Business Requirement, Stakeholder Requirement, Solution Requirement và Transition Requirement.

Bạn đọc có thể tìm hiểu thêm về các tài liệu Requirements tại: 4 loại requirements nào Business Analyst (BA) thường hay làm việc?

Bài viết này sẽ so sánh đặc tính của 3 loại tài liệu: 1. Business Requirement Document (BRD), 2. System requirement specification (SRS)/ System Requirement Document (SRD) và 3 . Functional Requirement Specification (FRS)/ Functional Specification Document (FSD).

1. Business Requirement Document – BRD

Theo định nghĩa về BRD: Tập hợp các yêu cầu nghiệp vụ và yêu cầu của các bên liên quan (BRD ghi lại những mong muốn của doanh nghiệp hơn là các yêu cầu).

BRD thường là loại tài liệu có đầu tiên trong quy trình phát triển của tổ chức. Nó mô tả chiến lược của công ty (Company’s high-level goals) mà họ đang nỗ lực để đạt được trong tương lai bằng cách tạo ra một sản phẩm/ dịch vụ. Bên cạnh đó, BRD còn bao gồm mối quan tâm/ nhu cầu của các bên liên quan đến sản phẩm/dịch vụ cuối cùng. Nói cách khác, BRD là câu trả lời cho câu hỏi “Tại sao?” Có các yêu cầu trên, kết quả mong đợi – sự thay đổi gì từ hệ thống.

Ví dụ về BRD: Công ty muốn cải thiện hiệu suất làm việc bằng cách theo dõi thời gian dành cho từng hoạt động của nhân viên.

Người BA luôn luôn là người chuẩn bị tài liệu này sau những buổi nói chuyện đầu tiên với doanh nghiệp và các bên liên quan. Sự xác nhận cuối cùng lại từ những bên liên quan chính sẽ là đảm bảo rằng BA đã nắm bắt chính xác kì vọng của họ cũng như tại sao họ muốn như vậy (context của doanh nghiệp).

Đối tượng sử dụng BRD là các nhà tài trợ, quản lí cấp cao, quản lí cấp trung và BA.

Một tài liệu BRD thường có các nội dung chính như:

  • Bối cảnh kinh doanh, phạm vi dự án, lý do tổ chức cần sự thay đổi (trạng thái hiện hành AS-IS).
  • Các bên liên quan chính đến dự án (Stakeholder)
  • Mục tiêu hướng đến (TO-BE) và các kỳ vọng của các bên.
  • Quy tắc kinh doanh (Business Rule)
  • Mục tiêu dự án (tức là dự án này làm ra để giải quyết vấn đề nào của tổ chức)
  • Phạm vi của dự án (Scope)
  • Chức năng chính trong phạm vi dự án
  • Chức năng ngoài phạm vi dự án (nghĩa là sẽ có chức năng này trong tương lai, do nguồn lực và phạm vi hiện tại chưa cho phép triển khai các chức năng này)
  • Xác định những khó khăn của dự án.
  • Những rủi ro cơ bản khi triển khai. Các giả định (assumption) có thể xảy ra.
  • Tổng qua về quy trình nghiệp vụ trong dự án (Ở đây tùy vào từng dự án mà có thể mô tả dưới dạng Use Case, BPMN, Activity Diagram…)
  • Mô tả màn hình (skech, wireframe, mockup, prototype)
  • Project Glossary: Danh sách từ vựng, từ ngữ chuyên ngành. Đây là lý do BA cần đặt mình vào vị trí của người đọc tài liệu, có những từ ngữ với bạn thì quen nhưng với người đọc thì khó hiểu nên cần phải ghi ra các từ ngữ mới, thuật ngữ chuyên ngành để tránh mất thời gian giải thích.

Tài liệu BRD quan trọng vì lý do:

  • Giảm sự thất bại của dự án: BRD sẽ mô tả, giải thích các khía cạnh về business, quy trình nghiệp vụ, yêu cầu kinh doanh từ các bên liên quan. Do đó BRD sẽ giúp BA giao tiếp, xác nhận tốt hơn về yêu cầu cần thiết. Giảm thiểu được những sai sót trong quá trình phát triển dự án.
  • Kết nối với các mục tiêu kinh doanh: Các yêu cầu kinh doanh được xác định rõ sẽ giúp đưa ra một điều lệ dự án, một bước quan trọng trong việc thực hiện chiến lược kinh doanh hoặc các mục tiêu kinh doanh và đưa nó đến bước hợp lý tiếp theo để phát triển nó thành một hệ thống CNTT trong giải pháp tổng thể.
  • Tạo sự đồng thuận: Khi các yêu cầu được mô tả và tài liệu hóa, xác nhận từ các bên liên quan sẽ tạo ra sự đồng thuận trong quá trình phát triển.
  • Tiết kiệm chi phí: BRD giúp giảm thiểu rủi ro về phạm vi dự án, giúp tiết kiệm thời gian và tiền bạc cho dự án.
  • Tạo nguồn tài liệu quản lý dự án: Các phiên bản BRD cũng là một loại tài liệu lưu giữ các phiên bản của dự án, giúp cho việc phát triển dự án sau này được thuận lợi hơn.

2. Software Requirement Documen Specifications – SRS

Tên gọi khác:

  • Product Requirements Document (PRD)
  • hay System Requirements Specification (SRS) 

Sau khi đã chuẩn bị tài liệu BRD, tức là đã trả lời được câu hỏi “Tại sao?” Cần xây dựng hệ thống này, sẽ đến bước tìm câu trả lời cho câu hỏi “Cái gì?”, tức là những yêu cầu nào được đặt ra để đáp ứng được nhu cầu của doanh nghiệp.


Theo định nghĩa quốc tế, SRS là tài liệu yêu cầu có cấu trúc và chi tiết, bao gồm các yêu cầu chức năng (The Functional Requirtements, dùng để minh họa hành vi người dùng) và Phi chức năng (Non-Functional Requirements – mô tả đặc điểm xoay quanh tính năng) cùng tất cả trường hợp khác mà phần mềm cần đáp ứng.


Vi dụ: Các modules cần có cho hệ thống theo dõi nhân viên như sau

  • Module đăng nhập: Xác thực người dùng dựa trên thông tin đăng nhập đã nhập vào hệ thống, và chỉ cho phép người dùng đã đăng kí đăng nhập.
  • Module Administrator: Bao gồm các chức năng cho phép quản trị viên quản lí người dùng: Thêm, chỉnh sửa, xóa người dùng; phân quyền / nhóm người dùng, thêm dự án, ….
  • Module nhân viên: Bao gồm các chức năng giúp nhân viên ghi nhận lại thời gain và các công việc mà họ đã làm, chỉnh sửa thông tin cá nhân, xem báo cáo ngày làm việc, …
  • Module báo cáo: Dành riêng cho Admin, cho phép họ trích xuất ra các báo cáo về nhân viên, dự án. Admin cũng có quyền xuất tài liệu dưới các file như .xlsx hoặc .pdf.

SRS là một tài liệu quan trọng như cầu nối giữa những gì doanh nghiệp muốn và những gì được tài liệu dưới dạng bố cục, đặc điểm, quy trình mà hệ thống đang xây dựng.

Dựa vào các yêu cầu phần mềm được ghi nhận rõ ràng trong SRS cũng giúp ước tính chi phí và thời gian cần có để hoàn thiện hệ thống. Đây cũng là cơ sở để tạo lập hợp đồng giữa các bên.

Nếu BRD do các BA chuẩn bị thì SRS sẽ được viết bởi các nhà phân tích hệ thống (the system analyst - SA). Tuy nhiên, trong thực tế ở một số doanh nghiệp đề cao quy trình tinh gọn và tốc độ (RAPID Development), khi đó sẽ không có SA thì BA sẽ là người làm cả tài liệu SRS nhưng ở mức độ vừa đủ, không quá chi tiết. Lúc này, người BA cần tiến hành tổng hợp yêu cầu của từng bên liên quan, phân tích chi tiết các chức năng của phần mềm và liệt kê lại các yêu cầu kỹ thuật đối với từng chức năng đó. Điều đó đảm bảo rằng, từng yêu cầu được liệt kê trong SRS sẽ đáp ứng các mục tiêu kinh doanh có trong BRD.

Đối tượng sử dụng SRS là quản lí dự án, chuyên gia tư vấn trong lĩnh vực (Subject Matter Experts), trưởng bộ phận kỹ thuật và thực thi.

Chú ý: Trong một số doanh nghiệp hoặc dự án nhỏ sẽ không cần sử dụng đến SRS vì trong BRD chi tiết đã bao gồm các yêu cầu chức năng và phi chức năng của hệ thống.

3. Functional Requirement Specifications – FRS

Tên gọi khác:

  • Functional Specifications Document (FSD),
  • Functional Specification (FS),
  • Product Specification,
  • and Functional SpecsProjec (FS).

FRS là loại tài liệu chi tiết nhất trong 3 loại trên, và sẽ là loại tài liệu cuối cùng trả lời cho câu hỏi “Như thế nào?”, tức là hệ thống dự kiến sẽ hoạt động như thế nào để làm thỏa mãn các yêu cầu nêu trong BRD và SRS.