May 25, 2020

Phân biệt các tài liệu BRD vs SRS vs FRS

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 ?! (Nghĩa là 1 BA nào cũng có phải biết "mần" 9 loại tài liệu này)

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

BAC sẽ giới thiệu và so sánh đặc tính của 3 loại tài liệu: 1 - mục 5 - Business Requirement Document (BRD), 2 - mục 8 - System requirement specification (SRS)/ System Requirement Document (SRD) và 3 - mục 7 - Functional requirement specification (FRS)/ Functional Specification Document (FSD):

Một người phân tích nghiệp vụ phần mềm (Business Analyst (BA)) cần hiểu và phân biệt được các khái niệm về tài liệu yêu cầu như Business Requirement Document – BRD (Tạm dịch: Tài liệu yêu cầu nghiệp vụ), Software Requirement Documen Specifications – SRS (Tạm dịch: Thông số kỹ thuật yêu cầu của phần mềm) và Functional Requirement Specifications – FRS (Tạm dịch: Thông số kỹ thuật yêu cầu của chức năng). Trong bài viết này, BAC sẽ cùng các bạn tìm hiểu sự khác nhau giữa chúng.

Việc phân tích nghiệp vụ (Business Analysis) được chi phối bởi các khung tiêu chuẩn cụ thể và chúng nên được sử dụng trong bất kì dự án thực tế nào. Tuy nhiên, không hề có một quy chuẩn nào về cấu trúc tổng thể, nội dung, và mức độ chi tiết trong các tài liệu chính thống về BA như BABOK hay CMMI. Vì vậy, đối với từng dự án, các tổ chức cần điều chỉnh các tài liệu yêu cầu này tùy theo quy trình và tiêu chuẩn của công ty cũng như nguồn lực sẵn có của họ.

Thông tin mô tả dưới đây phù hợp với những phân tích tài liệu dự án (Project Document Practices) và phân tích nghiệp vụ (Business Analysis) được chấp nhận rộng rãi nhất.

1. Business Requirement Document – BRD

Theo định nghĩa được công nhận trên toàn thế giới về BRD là: 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.

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 – miêu tả đặc điểm) 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 làm 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, không có SA thì BA sẽ là người làm chuyện này. 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.

Theo định nghĩa đã được công nhận, FRS là tài liệu chi tiết để xây dựng đầy đủ các tiểu tiết có trong yêu cầu chức năng của dự án.

Ví dụ: Trong module đăng nhập sẽ có các chi tiết:

Nhập username: Là hộp văn bản cho phép người dùng nhập tên đăng nhập theo địa chỉ email công ty đã đăng kí cho họ
Nhập password: Là hộp văn bản cho phép người dùng nhập mật khẩu. Mật khẩu không được hiển thị và được mã hóa dưới dạng dấu ‘*’.
Nút submit: Khi click vào nút này, hệ thống sẽ xác nhận thông tin đăng nhập đã đúng hay chưa. Trong trường hợp tên đăng nhập hoặc mật khẩu không đúng sẽ hiện thông báo “Tên đăng nhập/ Mật khẩu không đúng”, …

FRS xây dựng các mô tả chi tiết, rõ ràng từng yêu cầu chức năng trong từng trường, và tương tác của người dùng trên từng trang của hệ thống.

FRS được thể hiện dưới các process flow diagrams (tạm dịch: sơ đồ dòng quy trình), UML diagrams, wireframs.

FRS được tạo từ quan điểm của người dùng và cách mà hệ thống sẽ tương tác với họ. Lúc này, team Dev sẽ phải rõ chính xác họ cần làm gì và team QA/testing cần biết có những kịch bản test nào cho hệ thống.

Tài liệu FRS do BA hoặc SA chuẩn bị, và sau khi hoàn thành sẽ đưa cho quản lí dự án xem xét. Tiếp theo, FRS sẽ được được đưa cho khách hàng, xác nhận lại lần cuối. Một khi đã có sự xác nhận của các bên, tài liệu này sẽ là bản tiêu chuẩn về cách thức hoạt động của phần mềm.

Đối tượng sử dụng FRS là trưởng bộ phận kỹ thuật, Team Dev và Team Testing.

Tổng hợp ngắn so sánh BRD và FRD:

Tham khảo thêm các định nghĩa thuật ngữ(glossary), so sánh/ ví dụ minh họa để rõ hơn:

Vui lòng điền thông tin qua form để tải mẫu tài liệu và ví dụ của BRD vs SRS vs FRS

Nguồn tài liệu tham khảo:

CÁC KHOÁ HỌC BUSINESS ANALYST BACs.VN DÀNH CHO BẠN

Khoá học Online:

Khoá học Offline:

Tại Tp.HCM:

Tại Hà Nội:

Tham khảo lịch khai giảng TẤT CẢ các khóa học mới nhất.

Ban biên tập nội dung BAC

Click để đọc tiếp

Các Business Analyst cần trau dồi những công nghệ gì trong năm 2025

Đối với sự phát triển nhanh chóng của công nghệ ngày này, việc không ngừng trau dồi và học hỏi là điều bắt buộc mà các Business Analyst phải làm để phát triển hơn trong lĩnh vực phân tích nghiệp vụ. Trong bài viết này, các bạn hãy cùng BAC tìm hiểu các xu hướng và các kỹ năng mới để làm hành trang trên sự nghiệp Business Analyst nhé!
Sự khác biệt giữa UAT và Usability Testing Business Analyst cần lưu ý

UAT và Usability Testing thường được mang lên bàn cân để so sánh nhưng, đây là 2 phương pháp kiểm thử khác nhau. Trong khi Usability Testing đảm bảo sự hài lòng của người dùng thì UAT lại giúp các Business Analyst xác thực chức năng. Cả hai đều là một phần không thể thiếu để cung cấp một sản phẩm chất lượng cao. Hãy cùng BAC tìm hiểu ngay nhé!
API là gì? Khám phá cầu nối giữa các ứng dụng

API là nền tảng quan trọng kết nối các ứng dụng và dịch vụ trong kỷ nguyên số, tạo ra sự linh hoạt, hiệu quả và mở rộng cho các hệ thống. Bài viết sau giới thiệu API, cách hoạt động, các kiểu kiến trúc phổ biến cùng các công cụ kiểm thử API như Postman.
Meta AI là gì và cách sử dụng Meta AI hiệu quả 2025

Meta AI là một công cụ Trí Tuệ Nhân Tạo do chính công ty mẹ của Facebook, Instagram, WhatsApp ra mắt. Đây được xem là một cuộc cách mạng sẽ làm thay đổi cách mà các doanh nghiệp và người dùng sử dụng mạng xã hội.

Bình luận

Nguyễn Thị Mai Bình

Business Analyst

Với một người ngoại đạo như mình thì những chuyên đề về "kỹ thuật" của BA hết sức quan trọng. Ví dụ như sử dụng các diagram để mô hình hóa requirement, viết User Story/Use case, v...v..

Đến với khóa học Fundamental Business Analysis, mình đã được gặp thầy Lộc, một người người rất nhiệt tình và có tâm. Ngoài việc chia sẻ các kinh nghiệm thực tế trên lớp thì thầy còn dành thời gian ra để tư vấn, hỗ trợ, góp ý CV cho mình. Bên cạnh đó trung tâm và anh Phụng cũng hỗ trợ gửi CV, kết nối học viên tới mạng lưới các công ty đối tác chất lượng, điều này giúp học viên như mình tìm được công việc phù hợp nhất. Cảm ơn BAC.
Xem chi tiết +
Phạm Quế

Business Analyst

Khoá học Product Design của BAC đã cung cấp cho tôi nhiều kiến thức và nền tảng vô cùng hữu ích. Giảng viên giảng dạy rất nhiệt tình, truyền cho chúng tôi ngọn lửa đam mê và nhiệt huyết trong ngành. Đồng thời chia sẻ các kiến thức và kỹ năng cần thiết trong bài giảng một cách dễ hiểu hơn. Số lượng học viên không quá nhiều nên chất lượng giảng giạy vô cùng tốt. Giảng viên sửa bài tập 1-1 nên bài giảng sẽ chuyên sâu hơn.
Xem chi tiết +
Nguyễn Văn Long

Chuyên viên về chế độ kế toán & Giải pháp nghiệp vụ Tài chính kế toán trong ứng dụng CNTT - Tập đoàn Điện lực Việt Nam (EVN)

Tôi đã tham gia khóa Phân tích nghiệp vụ phần mềm cơ bản 3.0 tại BAC. Ở đây, tài liệu đào tạo cung cấp nhiều nội dung bổ ích và trình bày dễ hiểu. Giảng viên rất nhiệt tình, ngoài nội dung giảng dạy theo giáo trình còn chia sẻ nhiều kinh nghiệm thực tiễn, các câu hỏi của học viên đều được giải đáp ngay trên lớp và có minh họa từ các dự án trong thực tế. Sau tất cả, tôi cảm ơn BAC và Thầy giáo Thái Sơn.
Xem chi tiết +