Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa hoàn thành ba tuần phỏng vấn stakeholder, dự nhiều buổi workshop, vẽ hàng chục mô hình quy trình. Trong đầu bạn, mọi thứ rõ như ban ngày: ai cần gì, vì sao cần, hệ thống mới phải làm được gì. Nhưng rồi đến cuộc họp bàn giao cho đội phát triển, một lập trình viên hỏi: "Anh ơi, đoạn này khách hàng có được sửa đơn sau khi thanh toán không?" — và bạn ngớ người. Trong đầu bạn có câu trả lời, nhưng trong tài liệu thì không có. Kết quả: dev đoán, đoán sai, và ba tuần sau cả team họp lại để sửa.
Đây chính là lý do tài liệu hóa yêu cầu (requirements documentation) là một trong những năng lực cốt lõi mà kỳ thi ECBA kiểm tra, và quan trọng hơn, là thứ phân biệt một BA nghiệp dư với một BA chuyên nghiệp. Yêu cầu chỉ tồn tại trong đầu bạn thì vô giá trị. Yêu cầu được viết ra rõ ràng, đúng đối tượng đọc, đúng thời điểm — đó mới là tài sản của dự án.
Trong BABOK Guide v3, hoạt động này gắn với task "Specify and Model Requirements" (đặc tả và mô hình hóa yêu cầu) thuộc Knowledge Area Requirements Analysis and Design Definition. Bài học hôm nay không bàn về cách phân tích yêu cầu (việc đó các bài KA5 đã lo), mà tập trung vào câu hỏi rất thực tế: Khi đã có yêu cầu rồi, ta viết nó ra thành tài liệu như thế nào cho chuẩn? Các loại tài liệu nào tồn tại, mỗi loại dùng cho ai, và đâu là những nguyên tắc viết tài liệu chuyên nghiệp.
Khái niệm cốt lõi
Các loại tài liệu yêu cầu trong nghề BA
Trong thực tế doanh nghiệp, bạn sẽ gặp một "họ" các tài liệu yêu cầu. Hiểu rõ từng loại giúp bạn không nhầm lẫn — và đây cũng là kiến thức hay bị hỏi trong đề thi.
BRD — Business Requirements Document (Tài liệu Yêu cầu Nghiệp vụ). Đây là tài liệu ở tầng cao nhất, trả lời câu hỏi "Tại sao chúng ta làm dự án này và doanh nghiệp cần đạt được gì?". BRD mô tả nhu cầu kinh doanh (business need), mục tiêu, phạm vi, các bên liên quan, và các yêu cầu nghiệp vụ ở mức tổng quát. Đối tượng đọc là lãnh đạo, nhà tài trợ dự án (sponsor), và quản lý. BRD không đi vào chi tiết kỹ thuật. Ví dụ một dòng trong BRD: "Doanh nghiệp cần giảm thời gian xử lý đơn hàng từ 48 giờ xuống dưới 4 giờ để cạnh tranh với đối thủ."
FRD — Functional Requirements Document (Tài liệu Yêu cầu Chức năng). Tài liệu này cụ thể hơn một bậc, trả lời câu hỏi "Hệ thống phải LÀM được những gì?". FRD mô tả các chức năng cụ thể: hệ thống cho phép người dùng đăng nhập bằng số điện thoại, hệ thống tự động tính phí ship theo khoảng cách, hệ thống gửi email xác nhận khi đơn được tạo. Đối tượng đọc chính là đội phát triển và kiểm thử (QA).
SRS — Software/System Requirements Specification (Đặc tả Yêu cầu Phần mềm/Hệ thống). Đây là tài liệu kỹ thuật đầy đủ nhất, thường gộp cả yêu cầu chức năng (functional) và phi chức năng (non-functional — hiệu năng, bảo mật, khả năng mở rộng). SRS là chuẩn theo IEEE 830, rất phổ biến trong các dự án lớn, dự án gia công phần mềm (outsourcing). Nhiều công ty Việt Nam làm outsourcing cho khách nước ngoài bắt buộc dùng SRS vì hợp đồng yêu cầu.
Một mẹo ghi nhớ cho kỳ thi: BRD = why (tại sao), FRD/SRS = what (cái gì). Cả ba đều KHÔNG nói how (làm thế nào) — phần "làm thế nào" thuộc về thiết kế kỹ thuật và là việc của kiến trúc sư, lập trình viên.
Đặc tính của một yêu cầu được viết tốt
BABOK nêu các đặc tính chất lượng của yêu cầu. Một yêu cầu viết tốt cần:
- Atomic (nguyên tử): mỗi yêu cầu chỉ nói một việc, có thể hiểu độc lập.
- Complete (đầy đủ): chứa đủ thông tin để người đọc hành động mà không cần hỏi thêm.
- Consistent (nhất quán): không mâu thuẫn với yêu cầu khác.
- Concise (súc tích): không có chữ thừa.
- Feasible (khả thi): thực hiện được trong giới hạn nguồn lực.
- Unambiguous (không mơ hồ): chỉ hiểu được theo một nghĩa.
- Testable (kiểm thử được): có thể xác minh đã đáp ứng hay chưa.
- Prioritized (được ưu tiên): biết yêu cầu nào quan trọng hơn.
Các định dạng đặc tả yêu cầu
BABOK liệt kê nhiều cách đặc tả. Không có định dạng "đúng" tuyệt đối — chọn theo bối cảnh:
- Văn bản tự nhiên (textual): câu mô tả như "Hệ thống phải...". Dễ viết, nhưng dễ mơ hồ.
- Ma trận (matrix): bảng, ví dụ ma trận phân quyền, ma trận truy vết (traceability matrix).
- Mô hình hóa (modeling): sơ đồ use case, BPMN, ERD, decision table. Một hình vẽ đôi khi thay được mười đoạn văn.
- Định dạng Agile: user story theo mẫu "Là một [vai trò], tôi muốn [chức năng] để [lợi ích]".
Tình huống thực tế
Tình huống 1 — Tiki và cái BRD lẫn lộn tầng
Một BA junior tại một sàn thương mại điện tử (gọi là dự án tương tự Tiki) được giao viết tài liệu cho tính năng "đổi trả hàng". Bạn ấy viết một tài liệu duy nhất dài 40 trang, trong đó trộn lẫn câu kiểu "Công ty muốn nâng tỷ lệ giữ chân khách hàng lên 15%" (yêu cầu nghiệp vụ) với câu "Khi người dùng bấm nút Đổi trả, hệ thống gọi API kiểm tra trạng thái đơn hàng ở bảng orders với điều kiện status = delivered" (chi tiết kỹ thuật).
Khi tài liệu này gửi lên cho giám đốc vận hành duyệt, ông không đọc nổi vì quá kỹ thuật. Khi gửi cho dev, dev lại phải lọc bỏ những đoạn chiến lược để tìm phần mình cần, và bỏ sót vài quy tắc nghiệp vụ quan trọng.
Bài học: Một tài liệu phục vụ một đối tượng. Lẽ ra bạn ấy nên tách: một BRD ngắn 3 trang cho lãnh đạo (vì sao làm, kỳ vọng kinh doanh), và một FRD chi tiết cho đội kỹ thuật. Trộn các tầng thông tin vào một chỗ là lỗi tài liệu hóa kinh điển. Hãy luôn hỏi: "Ai sẽ đọc tài liệu này và họ cần ra quyết định gì?"
Tình huống 2 — Công ty outsourcing và yêu cầu mơ hồ trị giá 200 triệu
Một công ty phần mềm ở Đà Nẵng nhận dự án xây app đặt lịch spa cho khách Nhật. Trong SRS có dòng: "Hệ thống hỗ trợ thông báo nhắc lịch hẹn cho khách hàng." Câu này nghe đầy đủ, nhưng thực ra cực kỳ mơ hồ. Nhắc qua kênh gì — email, SMS, push notification? Nhắc trước bao lâu? Nhắc mấy lần? Khách hủy lịch thì có nhắc nữa không?
Đội dev hiểu là "gửi một email trước 1 giờ". Khách hàng Nhật lại kỳ vọng "gửi SMS trước 24 giờ và push notification trước 2 giờ, đúng phong cách dịch vụ Nhật". Khi nghiệm thu, khách từ chối, dự án phải làm lại phần thông báo, phát sinh thêm khoảng 200 triệu đồng chi phí và trễ một tháng.
Bài học: Yêu cầu phải không mơ hồ và kiểm thử được. Nếu BA viết: "Hệ thống gửi nhắc lịch qua SMS trước 24 giờ và push notification trước 2 giờ; nếu khách chưa xác nhận trong 12 giờ trước hẹn, gửi nhắc lần hai qua SMS" — thì dev không phải đoán, QA có cái để kiểm thử, và khách có cái để nghiệm thu. Mỗi từ mơ hồ trong tài liệu là một quả bom hẹn giờ về chi phí.
Tình huống 3 — Ngân hàng và sức mạnh của traceability
Một ngân hàng số tại TP.HCM xây tính năng vay tiêu dùng online. BA xây một ma trận truy vết (requirements traceability matrix) liên kết mỗi yêu cầu với: mục tiêu nghiệp vụ tương ứng, use case, test case, và quy định pháp lý của Ngân hàng Nhà nước. Khi cơ quan thanh tra yêu cầu chứng minh "hệ thống tuân thủ quy định về định danh khách hàng (eKYC)", BA chỉ cần mở ma trận, lọc ra đúng các yêu cầu liên quan và test case chứng minh, trong vòng 15 phút.
Ở một dự án khác không có traceability, khi khách yêu cầu bỏ một chức năng, không ai biết chức năng đó còn liên quan tới những phần nào khác. Họ xóa, và ba module khác hỏng theo.
Bài học: Tài liệu hóa tốt không chỉ là viết câu rõ ràng, mà còn là duy trì mối liên kết giữa các yêu cầu. Traceability biến tài liệu từ một xấp giấy tĩnh thành một công cụ quản lý sống động.
Hướng dẫn từng bước
Đây là quy trình thực tế để tạo tài liệu yêu cầu chuyên nghiệp:
Bước 1 — Xác định đối tượng đọc và loại tài liệu. Trước khi gõ chữ đầu tiên, hỏi: ai đọc? Lãnh đạo thì viết BRD. Đội phát triển thì viết FRD/SRS. Team Agile thì viết user story trong backlog. Đừng dùng một khuôn cho mọi đối tượng.
Bước 2 — Chọn template phù hợp. Hầu hết công ty trưởng thành đều có sẵn template BRD/SRS. Dùng template giúp bạn không bỏ sót mục (phạm vi, giả định, ràng buộc, yêu cầu phi chức năng...). Nếu chưa có, hãy tham khảo cấu trúc chuẩn IEEE 830 cho SRS.
Bước 3 — Viết theo nguyên tắc "một yêu cầu, một ý". Mỗi yêu cầu nên atomic. Nếu một câu của bạn chứa chữ "và" nối hai chức năng, hãy tách thành hai yêu cầu để dễ truy vết và kiểm thử.
Bước 4 — Gán mã định danh (unique ID) cho từng yêu cầu. Ví dụ FR-001, FR-002, NFR-001. Mã này là chìa khóa để làm traceability và để mọi người cùng nói về "yêu cầu FR-017" thay vì "cái yêu cầu về thông báo ấy".
Bước 5 — Bổ sung tiêu chí chấp nhận (acceptance criteria). Với mỗi yêu cầu quan trọng, viết rõ điều kiện để coi là "đã hoàn thành đúng". Đây là điều giúp yêu cầu trở nên kiểm thử được.
Bước 6 — Kết hợp văn bản với mô hình. Chỗ nào luồng phức tạp, chèn sơ đồ. Chỗ nào nhiều quy tắc điều kiện, dùng bảng quyết định. Đừng cố diễn đạt mọi thứ bằng văn bản thuần.
Bước 7 — Rà soát và lấy phê duyệt (review & sign-off). Cho stakeholder đọc lại, xác nhận. Một tài liệu chưa được duyệt thì chưa phải là baseline. Ghi lại phiên bản và lịch sử thay đổi.
Bước 8 — Quản lý phiên bản. Đặt version (v1.0, v1.1), ghi changelog. Yêu cầu luôn thay đổi; tài liệu không có quản lý phiên bản sẽ nhanh chóng lỗi thời và gây hỗn loạn.
Lỗi thường gặp & mẹo
Lỗi 1 — Trộn lẫn các tầng thông tin. Như tình huống Tiki: nhồi chiến lược, chức năng và kỹ thuật vào một tài liệu. Mẹo: trước khi viết mỗi đoạn, tự hỏi "đoạn này phục vụ ai?".
Lỗi 2 — Dùng từ ngữ mơ hồ. Các từ "nhanh", "thân thiện", "linh hoạt", "nếu cần", "v.v." là kẻ thù. Mẹo: thay mọi tính từ định tính bằng con số đo được. "Nhanh" → "dưới 2 giây".
Lỗi 3 — Mô tả giải pháp thay vì yêu cầu. BA non tay hay viết "thêm một nút màu xanh ở góc phải" — đó là thiết kế, không phải yêu cầu. Yêu cầu là "người dùng cần xuất báo cáo ra file Excel". Còn nút màu gì, đặt ở đâu là việc của thiết kế. Mẹo: tập trung vào cái gì và tại sao, để dành làm thế nào cho đội thiết kế.
Lỗi 4 — Quên yêu cầu phi chức năng. Nhiều BA chỉ viết chức năng mà bỏ quên hiệu năng, bảo mật, khả năng chịu tải. Bài 31 đã phân biệt functional và non-functional — hãy luôn dành một mục riêng cho non-functional trong SRS.
Lỗi 5 — Tài liệu chết. Viết xong rồi để đó, không cập nhật khi yêu cầu thay đổi. Mẹo: coi tài liệu là sản phẩm sống, gắn version và changelog, cập nhật ngay khi có thay đổi được duyệt.
Mẹo vàng cho kỳ thi ECBA: Khi gặp câu hỏi phân biệt loại tài liệu, nhớ rằng BRD ở tầng nghiệp vụ (business), SRS/FRD ở tầng giải pháp (solution). Khi gặp câu về "yêu cầu tốt", các từ khóa cần khoanh là unambiguous, testable, atomic, complete, consistent. Đề thi rất thích bẫy bằng các yêu cầu mơ hồ và hỏi "yêu cầu nào viết tốt nhất".
Bài tập thực hành
Bài 1 — Sửa yêu cầu mơ hồ. Cho yêu cầu sau: "Hệ thống đăng nhập phải an toàn và dễ dùng." Hãy viết lại thành 2–3 yêu cầu rõ ràng, không mơ hồ và kiểm thử được. Gợi ý: nghĩ về độ dài mật khẩu, số lần nhập sai cho phép, thời gian khóa tài khoản, hỗ trợ đăng nhập bằng số điện thoại.
Bài 2 — Phân loại tài liệu. Đọc 5 câu sau và xác định mỗi câu thuộc BRD hay FRD/SRS:
- "Doanh nghiệp muốn tăng doanh thu mảng giao hàng thêm 20% trong năm 2026."
- "Hệ thống cho phép người dùng theo dõi vị trí shipper theo thời gian thực."
- "Hệ thống phải xử lý tối thiểu 500 đơn đồng thời mà thời gian phản hồi không quá 3 giây."
- "Dự án giúp công ty đáp ứng quy định mới về hóa đơn điện tử."
- "Khi đơn hàng bị hủy, hệ thống tự động hoàn tiền vào ví trong vòng 24 giờ."
Bài 4 — Thiết kế ma trận truy vết mini. Tạo một bảng 4 cột (ID yêu cầu, Mô tả, Mục tiêu nghiệp vụ liên quan, Test case) cho 3 yêu cầu của một tính năng "giỏ hàng" trong app bán hàng. Bài này luyện tư duy traceability.
Tóm tắt
Tài liệu hóa yêu cầu là kỹ năng biến những gì trong đầu BA thành tài sản dùng được của cả dự án. Bạn cần phân biệt rõ ba loại tài liệu chính: BRD trả lời tại sao và phục vụ lãnh đạo; FRD và SRS trả lời hệ thống làm gì và phục vụ đội phát triển, kiểm thử — trong đó SRS theo chuẩn IEEE 830 thường gộp cả yêu cầu chức năng lẫn phi chức năng.
Một yêu cầu viết tốt phải đạt các đặc tính: nguyên tử, đầy đủ, nhất quán, súc tích, khả thi, không mơ hồ, kiểm thử được và được ưu tiên. Trong đó, không mơ hồ và kiểm thử được là hai thứ quyết định việc dự án có "vỡ trận" vì hiểu nhầm hay không — như bài học 200 triệu từ công ty Đà Nẵng.
Quy trình chuẩn: xác định đối tượng đọc, chọn template, viết mỗi yêu cầu một ý, gán mã định danh, bổ sung tiêu chí chấp nhận, kết hợp văn bản với mô hình, lấy phê duyệt và quản lý phiên bản. Tránh năm lỗi kinh điển: trộn tầng thông tin, dùng từ mơ hồ, mô tả giải pháp thay vì yêu cầu, quên non-functional, và để tài liệu chết. Cuối cùng, đừng quên sức mạnh của traceability — thứ biến một xấp giấy thành công cụ quản lý sống động, như ngân hàng đã làm được để vượt qua thanh tra trong 15 phút. Nắm vững những nguyên tắc này, bạn không chỉ qua được phần thi liên quan trong ECBA, mà còn trở thành một BA mà đội phát triển nào cũng muốn làm việc cùng.