Trong bất kỳ dự án phần mềm hay dự án chuyển đổi nghiệp vụ nào, Business Analyst đều phải làm việc với rất nhiều loại tài liệu BA khác nhau — từ tài liệu mô tả yêu cầu nghiệp vụ ở mức tổng quan cho đến tài liệu đặc tả kỹ thuật chi tiết. Việc nắm vững từng loại tài liệu, biết khi nào dùng loại nào, sẽ giúp BA làm việc hiệu quả hơn và tránh được tình trạng hiểu sai yêu cầu giữa các bên liên quan.
Bài viết này tổng hợp đầy đủ các loại tài liệu BA phổ biến nhất, kèm quy trình viết, lỗi thường gặp và công cụ hỗ trợ.
Link tài liệu: Nhận trọn bộ tài liệu
1. Tổng hợp các loại tài liệu BA quan trọng
1.1. BRD – Business Requirement Document
BRD mô tả yêu cầu nghiệp vụ ở mức tổng quan: mục tiêu kinh doanh, phạm vi dự án, các bên liên quan, lợi ích mong đợi. Đây là tài liệu được lập ở giai đoạn đầu dự án, thường dùng để trình bày với ban lãnh đạo hoặc khách hàng nhằm thống nhất về "bức tranh lớn" trước khi đi vào chi tiết kỹ thuật.
Khi nào dùng: Giai đoạn khởi tạo dự án, khi cần sự phê duyệt từ cấp quản lý hoặc khách hàng.
1.2. SRS – Software Requirement Specification
SRS là tài liệu đặc tả yêu cầu phần mềm chi tiết, bao gồm cả yêu cầu chức năng (system phải làm gì) và phi chức năng (hiệu năng, bảo mật, khả năng mở rộng...). Đây là tài liệu kỹ thuật quan trọng để đội phát triển tham chiếu trong suốt quá trình xây dựng sản phẩm.
Khi nào dùng: Giai đoạn thiết kế hệ thống, làm căn cứ cho đội dev và QA.
1.3. FRS – Functional Requirement Specification
FRS tập trung mô tả chi tiết từng chức năng cụ thể của hệ thống: hệ thống phản ứng ra sao với từng thao tác của người dùng. So với BRD, FRS chi tiết hơn nhiều nhưng hẹp hơn SRS vì chỉ tập trung vào khía cạnh chức năng.
Khi nào dùng: Khi cần mô tả chi tiết một module hoặc tính năng cụ thể trước khi lập trình.
1.4. Use Case Document
Use Case mô tả các kịch bản tương tác giữa người dùng (actor) và hệ thống, bao gồm luồng chính (main flow), luồng thay thế (alternative flow) và các trường hợp ngoại lệ (exception flow).
Khi nào dùng: Khi cần mô tả rõ hành vi tương tác giữa người dùng và hệ thống, đặc biệt hữu ích cho đội test viết test case.
1.5. User Story (Agile/Scrum)
User Story thường dùng trong mô hình Agile/Scrum, viết theo cấu trúc: "Là [vai trò], tôi muốn [chức năng], để [mục đích]". Đi kèm User Story thường có Acceptance Criteria để xác định tiêu chí hoàn thành.
Khi nào dùng: Trong các dự án chạy Scrum/Agile, đưa vào backlog để lập kế hoạch từng sprint.
1.6. Process Flow Diagram (Sơ đồ quy trình)
Trực quan hóa quy trình nghiệp vụ hoặc luồng xử lý hệ thống bằng sơ đồ (BPMN, flowchart), giúp các bên dễ hình dung hơn so với mô tả bằng văn bản thuần túy.
Khi nào dùng: Khi cần mô tả quy trình nghiệp vụ có nhiều bước, nhiều điều kiện rẽ nhánh.
1.7. Wireframe / Mockup
Không hẳn là văn bản thuần túy, nhưng wireframe/mockup là tài liệu BA quan trọng thể hiện trực quan giao diện và trải nghiệm người dùng trước khi bước vào thiết kế UI/UX chi tiết.
Khi nào dùng: Giai đoạn thiết kế giao diện sơ bộ, giúp stakeholder hình dung sản phẩm trước khi triển khai.
2. Quy trình viết tài liệu BA hiệu quả
Thu thập yêu cầu: Phỏng vấn stakeholder, khảo sát, tổ chức workshop.
Phân tích và làm rõ: Xác định yêu cầu nào là bắt buộc (must-have), yêu cầu nào chỉ là mong muốn (nice-to-have).
Lựa chọn loại tài liệu phù hợp: Tùy vào giai đoạn dự án và đối tượng đọc (BRD cho lãnh đạo, SRS/FRS cho đội kỹ thuật...).
Trình bày rõ ràng, có cấu trúc: Sử dụng tiêu đề, bảng biểu, sơ đồ để nội dung dễ theo dõi.
Rà soát và xác nhận: Gửi lại cho stakeholder để xác nhận trước khi chuyển giao cho đội phát triển.
3. Lỗi thường gặp khi viết tài liệu BA
Viết yêu cầu mơ hồ, thiếu tiêu chí đo lường rõ ràng (thiếu Acceptance Criteria).
Nhầm lẫn giữa yêu cầu nghiệp vụ và yêu cầu kỹ thuật.
Thiếu nhất quán giữa các tài liệu (BRD nói một đằng, SRS lại nói một nẻo).
Không cập nhật tài liệu khi yêu cầu thay đổi trong quá trình dự án, dẫn đến tài liệu "lỗi thời" so với thực tế.
4. Công cụ hỗ trợ viết tài liệu BA
Confluence, Notion: quản lý và lưu trữ tài liệu tập trung, dễ chia sẻ với team.
Jira: quản lý User Story, backlog trong dự án Agile.
Draw.io, Visio, Lucidchart: vẽ sơ đồ quy trình, use case diagram.
Balsamiq, Figma: thiết kế wireframe, mockup giao diện.
5. Câu hỏi thường gặp (FAQ)
BA mới vào nghề cần học viết tài liệu nào trước? Nên bắt đầu với User Story và Use Case Document vì đây là hai loại tài liệu phổ biến, dễ tiếp cận và được dùng nhiều trong các dự án Agile hiện nay. Sau đó mới nâng dần lên BRD, SRS/FRS.
BRD, SRS, FRS khác nhau như thế nào? BRD tập trung vào mục tiêu và phạm vi nghiệp vụ ở mức tổng quan, dành cho cấp quản lý. SRS mô tả đầy đủ cả yêu cầu chức năng lẫn phi chức năng, dùng cho đội kỹ thuật. FRS chỉ tập trung chi tiết vào các chức năng cụ thể, thường hẹp hơn SRS.
Tài liệu BA trong dự án Agile có khác Waterfall không? Có. Trong Waterfall, tài liệu thường đầy đủ và chi tiết ngay từ đầu (BRD, SRS đầy đủ trước khi code). Trong Agile, tài liệu được viết linh hoạt, tăng dần theo từng sprint, phổ biến nhất là User Story kèm Acceptance Criteria thay vì SRS dài dòng.
Có cần biết vẽ sơ đồ (UML, BPMN) để làm tài liệu BA không? Có, đây là kỹ năng gần như bắt buộc. Sơ đồ giúp trực quan hóa quy trình, use case, giúp các bên không rành kỹ thuật cũng dễ hiểu hơn so với đọc văn bản thuần túy.
Tài liệu BA do BA viết hay do PM/Dev cùng tham gia? BA thường là người chủ trì soạn thảo, nhưng trong thực tế cần có sự phối hợp với PM (về phạm vi, tiến độ) và Dev/Tech Lead (để đảm bảo tính khả thi kỹ thuật) trước khi tài liệu được chốt.
Kết luận
Nắm vững các loại tài liệu BA — từ BRD, SRS, FRS đến Use Case, User Story, Process Flow và Wireframe — là kỹ năng cốt lõi giúp Business Analyst làm cầu nối hiệu quả giữa khách hàng, đội phát triển và các bên liên quan. Việc lựa chọn đúng loại tài liệu cho từng giai đoạn dự án, kết hợp quy trình viết rõ ràng và công cụ hỗ trợ phù hợp, sẽ giúp giảm thiểu rủi ro hiểu sai yêu cầu và nâng cao chất lượng sản phẩm cuối cùng.
>>> Tham gia: Khóa học IT Business Analyst thực chiến, Cơ hội việc làm sau khóa học.
