Những Tài Liệu BA Cần Làm Trong Một Dự Án

Trong vai trò của một IT Business Analyst, việc xây dựng tài liệu đầy đủ, rõ ràng và chính xác là yếu tố then chốt quyết định sự thành công của dự án. Tài liệu không chỉ giúp đội ngũ phát triển hiểu đúng yêu cầu mà còn là cầu nối giúp các bên liên quan (stakeholders) luôn nắm bắt được mục tiêu và tiến độ công việc.

Vậy tài liệu BA cần làm trong một dự án IT gồm những gì? Bài viết này sẽ tổng hợp 9 loại tài liệu quan trọng nhất mà một Business Analyst thường xuyên phải xây dựng, từ giai đoạn khởi động dự án cho đến khi bàn giao sản phẩm.

1. Tài Liệu Yêu Cầu Nghiệp Vụ (Business Requirement Document – BRD)

BRD (Business Requirement Document) là tài liệu BA cần làm đầu tiên và quan trọng nhất trong hầu hết các dự án IT. Tài liệu này ghi lại toàn bộ yêu cầu từ phía doanh nghiệp: vấn đề đang gặp phải, mục tiêu cần đạt được và phạm vi giải pháp được kỳ vọng.

BRD đóng vai trò là “hợp đồng ngầm” giữa doanh nghiệp và đội ngũ phát triển. Nếu BRD không rõ ràng hoặc thiếu sót, toàn bộ dự án có nguy cơ đi sai hướng ngay từ đầu.

BRD thường bao gồm những gì?

• Mục tiêu kinh doanh: Doanh nghiệp muốn đạt được điều gì sau khi dự án hoàn thành.
• Phạm vi dự án: Những gì nằm trong và ngoài phạm vi triển khai.
• Các vấn đề hiện tại: Pain point mà doanh nghiệp đang đối mặt.
• Yêu cầu kinh doanh cụ thể: Danh sách các yêu cầu được ưu tiên theo mức độ quan trọng.
• Đề xuất giải pháp sơ bộ: Hướng tiếp cận được khuyến nghị để giải quyết vấn đề.
• Các bên liên quan chính: Stakeholders tham gia phê duyệt và cung cấp thông tin đầu vào.

Lưu ý thực tế: BA nên tổ chức các buổi workshop với stakeholders để thu thập yêu cầu BRD thay vì chỉ dựa vào email hoặc tài liệu nội bộ sẵn có. Điều này giúp phát hiện sớm các yêu cầu mâu thuẫn hoặc chưa được đề cập.

2. Tài Liệu Yêu Cầu Hệ Thống (System Requirement Specification – SRS)

SRS (System Requirement Specification) là tài liệu BA cần làm tiếp theo sau BRD. Nếu BRD trả lời câu hỏi “doanh nghiệp cần gì?”, thì SRS trả lời “hệ thống cần được xây dựng như thế nào để đáp ứng nhu cầu đó?”.

SRS là tài liệu đầu vào quan trọng nhất cho đội ngũ kỹ thuật (developers, architects, QA). Tài liệu này cần đủ chi tiết để team kỹ thuật có thể bắt đầu thiết kế kiến trúc hệ thống mà không cần hỏi lại quá nhiều.

SRS thường bao gồm những gì?

• Mô tả tổng quan hệ thống: Hệ thống làm gì, tích hợp với hệ thống nào.
• Yêu cầu chức năng (Functional Requirements): Danh sách chi tiết các tính năng hệ thống phải có.
• Yêu cầu phi chức năng (Non-Functional Requirements): Hiệu suất, bảo mật, khả năng mở rộng.
• Ràng buộc hệ thống: Giới hạn về công nghệ, ngân sách hoặc thời gian.
• Giao diện hệ thống: Cách hệ thống tương tác với người dùng và các hệ thống khác.

>>> Xem thêm: SRS trong dự án E-commerce: Tài liệu gốc định hình cả sản phẩm

3. Tài Liệu Đặc Tả Chức Năng (Functional Requirement Document – FRD)

FRD (Functional Requirement Document) là bước đi sâu hơn từ SRS. Trong khi SRS mô tả hệ thống cần làm gì ở mức tổng quát, FRD đi vào chi tiết từng chức năng cụ thể: luồng xử lý, điều kiện kích hoạt, kết quả đầu ra và cách các chức năng này phối hợp với nhau.

Đây là tài liệu BA cần làm tỉ mỉ nhất vì nó trực tiếp ảnh hưởng đến chất lượng code và trải nghiệm người dùng cuối.

FRD thường bao gồm những gì?

• Mô tả chi tiết từng chức năng: Tên, mục đích, điều kiện tiên quyết và hậu điều kiện.
• Luồng xử lý chính (Main Flow) và luồng thay thế (Alternate Flow): Các kịch bản xử lý bình thường và ngoại lệ.
• Giao diện người dùng (UI): Wireframe hoặc mô tả màn hình liên quan.
• Quy tắc nghiệp vụ (Business Rules): Các ràng buộc áp dụng cho chức năng đó.
• Tương tác giữa các chức năng: Chức năng A ảnh hưởng thế nào đến chức năng B.

Mẹo thực chiến: Khi viết FRD, BA nên phối hợp chặt chẽ với UI/UX Designer để đảm bảo mô tả chức năng luôn gắn với giao diện thực tế, tránh tình trạng “tài liệu một đằng, sản phẩm một nẻo”.

4. Tài Liệu Mô Hình Quy Trình Kinh Doanh (Business Process Model – BPM)

BPM (Business Process Model) là tài liệu dạng sơ đồ, mô tả chi tiết cách doanh nghiệp đang vận hành ở trạng thái hiện tại (As-Is) và kỳ vọng vận hành sau khi có hệ thống mới (To-Be). BA sử dụng BPM để xác định chính xác điểm cần cải tiến và thiết kế giải pháp phù hợp.

BPM thường được vẽ bằng ký hiệu chuẩn BPMN 2.0 (Business Process Model and Notation) và là tài liệu rất hữu ích khi thuyết phục lãnh đạo hoặc trình bày với đội kỹ thuật.

BPM thường bao gồm những gì?

• Sơ đồ As-Is: Quy trình hiện tại với các điểm nghẽn và vấn đề tồn đọng.
• Sơ đồ To-Be: Quy trình tối ưu sau khi giải pháp được triển khai.
• Vai trò và trách nhiệm: Ai làm gì trong từng bước của quy trình (Swim Lane).
• Điểm quyết định (Decision Points): Các nhánh rẽ dựa trên điều kiện cụ thể.
• Phân tích Gap: Khoảng cách giữa As-Is và To-Be cần được giải quyết.

5. Tài Liệu Use Case

Use Case là tài liệu BA cần làm để mô tả các kịch bản tương tác giữa người dùng (Actor) và hệ thống nhằm đạt được một mục tiêu cụ thể. Đây là cầu nối quan trọng giữa yêu cầu nghiệp vụ và thiết kế kỹ thuật, giúp cả hai phía hiểu hệ thống sẽ hoạt động thực tế như thế nào.

Use Case thường đi kèm với Use Case Diagram (sơ đồ tổng quan) và Use Case Specification (đặc tả chi tiết từng kịch bản).

Một Use Case Specification đầy đủ bao gồm:

• Tên và mã Use Case: Ví dụ UC-001: Đặt hàng trực tuyến.
• Actor: Người dùng hoặc hệ thống tham gia vào kịch bản này.
• Điều kiện tiên quyết (Preconditions): Điều kiện phải thỏa mãn trước khi Use Case bắt đầu.
• Luồng chính (Basic Flow): Các bước xảy ra trong điều kiện bình thường.
• Luồng thay thế và ngoại lệ: Xử lý khi có lỗi hoặc điều kiện đặc biệt.
• Hậu điều kiện (Postconditions): Trạng thái hệ thống sau khi Use Case kết thúc.

6. Tài Liệu Yêu Cầu Phi Chức Năng (Non-Functional Requirement – NFR)

Nhiều BA mới vào nghề thường tập trung quá nhiều vào yêu cầu chức năng mà bỏ quên NFR (Non-Functional Requirement) — nhóm yêu cầu quyết định chất lượng vận hành thực tế của hệ thống. Một hệ thống có đủ tính năng nhưng chậm, không bảo mật hoặc hay sập vẫn là một dự án thất bại.

Các nhóm NFR phổ biến BA cần xác định:

• Hiệu suất (Performance): Thời gian phản hồi, số lượng người dùng đồng thời tối đa.
• Bảo mật (Security): Xác thực, phân quyền, mã hóa dữ liệu, chống tấn công.
• Độ tin cậy (Reliability): Uptime tối thiểu, cơ chế backup và phục hồi.
• Khả năng mở rộng (Scalability): Hệ thống có thể nâng cấp khi lượng người dùng tăng.
• Khả năng bảo trì (Maintainability): Dễ cập nhật, vá lỗi và mở rộng tính năng mới.
• Tuân thủ quy định (Compliance): GDPR, ISO 27001, quy định ngành (ngân hàng, y tế, v.v.).

>>> Tìm hiểu thêm: Lộ trình học trở thành Business Analyst tại Cole.vn

7. Tài Liệu Báo Cáo Khả Thi (Feasibility Study)

Báo cáo khả thi là tài liệu BA cần làm ngay từ giai đoạn tiền dự án (pre-project). Trước khi doanh nghiệp quyết định đầu tư nguồn lực, BA phải đánh giá toàn diện liệu dự án có thực sự khả thi và có đáng để triển khai hay không.

Một báo cáo khả thi tốt giúp doanh nghiệp tránh đổ tiền vào dự án không có tiền đồ, đồng thời tạo sự tin tưởng với ban lãnh đạo và nhà đầu tư.

Báo cáo khả thi thường đánh giá các khía cạnh:

• Khả thi về kỹ thuật (Technical Feasibility): Công nghệ hiện tại có đáp ứng được yêu cầu không?
• Khả thi về tài chính (Financial Feasibility): Chi phí dự kiến, ROI (tỷ suất hoàn vốn) và thời gian thu hồi vốn.
• Khả thi về vận hành (Operational Feasibility): Tổ chức có đủ năng lực vận hành hệ thống sau triển khai không?
• Khả thi về thời gian (Schedule Feasibility): Timeline dự kiến có thực tế không?
• Đánh giá rủi ro: Các rủi ro chính và kế hoạch giảm thiểu.

8. Tài Liệu Test Case

Dù Test Case được biết đến nhiều hơn với vai trò của QA/Tester, nhưng BA vẫn cần tham gia viết hoặc review Test Case để đảm bảo hệ thống được kiểm thử đúng với yêu cầu ban đầu đã xác định trong BRD và FRD. Đây là cách BA “chốt vòng” — từ lúc thu thập yêu cầu cho đến khi xác nhận hệ thống hoạt động đúng.

Một Test Case đầy đủ bao gồm:

• Mã Test Case và tiêu đề: Ví dụ TC-001: Kiểm tra đăng nhập với thông tin hợp lệ.
• Điều kiện tiên quyết: Trạng thái hệ thống và dữ liệu cần có trước khi chạy test.
• Các bước thực hiện: Mô tả chi tiết từng bước cần thực hiện.
• Dữ liệu đầu vào (Test Data): Giá trị cụ thể dùng để kiểm thử.
• Kết quả mong đợi (Expected Result): Hệ thống phải phản hồi như thế nào.
• Tiêu chí Pass/Fail: Điều kiện để đánh giá test case đạt hay không đạt.

Lưu ý: BA nên tập trung vào Test Case nghiệp vụ (Business Acceptance Test) — kiểm thử xem hệ thống có thực sự giải quyết được vấn đề của doanh nghiệp hay không, thay vì chỉ kiểm tra từng tính năng kỹ thuật riêng lẻ.

9. Tài Liệu Hướng Dẫn Sử Dụng (User Manual)

User Manual là tài liệu BA cần làm ở giai đoạn cuối dự án, trước khi bàn giao hệ thống cho người dùng cuối. Dù thường bị xem nhẹ, tài liệu hướng dẫn sử dụng tốt có thể giảm đáng kể số lượng yêu cầu hỗ trợ sau triển khai và giúp người dùng tiếp cận hệ thống mới một cách tự tin hơn.

User Manual hiệu quả cần đảm bảo:

• Ngôn ngữ phù hợp với người dùng cuối: Tránh thuật ngữ kỹ thuật, viết theo góc nhìn của người dùng.
• Có ảnh chụp màn hình minh họa: Mỗi bước thao tác nên đi kèm hình ảnh thực tế của giao diện.
• Tổ chức theo tác vụ (task-based): “Cách đặt hàng”, “Cách tra cứu lịch sử giao dịch” thay vì mô tả theo menu.
• Bao gồm mục xử lý lỗi thường gặp: Người dùng sẽ làm gì khi gặp thông báo lỗi phổ biến.
• Phiên bản và lịch sử cập nhật: Đảm bảo tài liệu luôn đồng bộ với phiên bản hệ thống hiện tại.

Kết Luận

Trên đây là 9 loại tài liệu BA cần làm trong một dự án IT, từ giai đoạn khởi động cho đến khi bàn giao sản phẩm. Mỗi loại tài liệu đảm nhiệm một vai trò riêng biệt trong vòng đời dự án:

• BRD, Feasibility Study — xác định hướng đi và tính khả thi ngay từ đầu.
• SRS, FRD, NFR, Use Case, BPM — đảm bảo đội ngũ kỹ thuật xây dựng đúng sản phẩm.
• Test Case — xác nhận hệ thống hoạt động đúng yêu cầu.
• User Manual — giúp người dùng cuối làm chủ sản phẩm một cách nhanh nhất.

Làm tốt mảng tài liệu không chỉ thể hiện sự chuyên nghiệp của một BA mà còn là nền tảng giúp toàn bộ dự án vận hành trơn tru, hạn chế rủi ro và tiết kiệm chi phí sửa đổi về sau. Nếu bạn đang muốn xây dựng sự nghiệp trong lĩnh vực này, hãy tham khảo Khóa học Business Analyst tại Cole.vn — nơi bạn được học từ lý thuyết đến thực chiến với các dự án thực tế.

Bài Viết Liên Quan

• SRS Trong Dự Án E-commerce: Tài Liệu Gốc Định Hình Cả Sản Phẩm
• 5 Dự Án ERP Thực Chiến Mà Business Analyst Không Nên Bỏ Lỡ
• Top 8 Domain Tuyển Business Analyst Nhiều Nhất Giai Đoạn 2025–2035
• Lộ Trình Học Trở Thành Business Analyst Tại Cole.vn

Câu Hỏi Thường Gặp Về Tài Liệu BA

BA cần làm bao nhiêu loại tài liệu trong một dự án?

Không có con số cố định. Số lượng tài liệu phụ thuộc vào quy mô dự án, phương pháp triển khai (Waterfall hay Agile) và yêu cầu của tổ chức. Một dự án lớn theo phương pháp Waterfall thường cần đầy đủ cả 9 loại tài liệu, trong khi dự án Agile có thể thay thế một số tài liệu nặng bằng User Story và Acceptance Criteria.

BA mới có cần biết viết tất cả các tài liệu này không?

Không nhất thiết phải thành thạo ngay từ đầu. BA mới thường bắt đầu với BRD, Use Case và FRD — là những tài liệu gần gũi nhất với công việc thu thập và phân tích yêu cầu. Các tài liệu như SRS, NFR hay Feasibility Study thường đòi hỏi kinh nghiệm thực tế và hiểu biết kỹ thuật sâu hơn.

Tài liệu BA khác gì với tài liệu của Product Owner (PO)?

BA tập trung vào tài liệu phân tích và đặc tả chi tiết (BRD, SRS, FRD, Use Case), trong khi PO thường làm việc với Product Backlog, User Story và Acceptance Criteria. Trong nhiều tổ chức, hai vai trò này có thể kiêm nhiệm hoặc phối hợp chặt chẽ với nhau.

Viết tài liệu BA cần dùng công cụ gì?

Các công cụ phổ biến gồm: Microsoft Word và Confluence để viết tài liệu văn bản; Lucidchart, Draw.io hoặc Visio để vẽ sơ đồ Use Case và BPMN; Figma để wireframe; Jira hoặc Azure DevOps để quản lý yêu cầu theo dạng ticket. Lựa chọn công cụ phụ thuộc vào quy trình và văn hóa của từng tổ chức.

Học BA ở đâu tại Việt Nam?

Khóa học Business Analyst tại Cole.vn là một trong những chương trình được đánh giá cao, tập trung vào thực chiến với các dự án thực tế thay vì chỉ học lý thuyết. Bạn có thể tải miễn phí lộ trình chi tiết tại trang khóa học ITBA của Cole.vn.