Mở đầu — vì sao bài này quan trọng
Suốt 56 bài vừa qua, bạn đã học rất nhiều lý thuyết: 6 Knowledge Areas của BABOK, hàng chục technique, các competency nền tảng. Nhưng có một sự thật phũ phàng mà nhiều bạn sẽ gặp khi đi làm: nhà tuyển dụng không bao giờ hỏi bạn "Định nghĩa Requirements Life Cycle Management là gì?". Họ hỏi: "Em đã từng viết tài liệu nghiệp vụ cho dự án nào chưa? Cho anh xem một mẫu."
Đây chính là lý do Bài 57 tồn tại. Đây là bài hands-on đầu tiên trong cặp project cuối khóa — nơi bạn ngừng ghi nhớ và bắt đầu làm. Sản phẩm bạn tạo ra trong bài này — một BRD (Business Requirements Document) hoàn chỉnh — sẽ là vật chứng cụ thể trong portfolio, thứ bạn đưa ra phỏng vấn để chứng minh "tôi biết làm, không chỉ biết nói".
Một lưu ý quan trọng về phạm vi: kỳ thi ECBA không yêu cầu bạn nộp BRD. ECBA là thi trắc nghiệm dựa trên BABOK. Nhưng việc tự tay viết một BRD sẽ giúp bạn thấm cách các khái niệm rời rạc kết nối với nhau trong một dòng chảy thực tế — từ stakeholder analysis, đến elicitation, đến requirements documentation. Khi bạn đã tự ráp toàn bộ bức tranh một lần, những câu hỏi trắc nghiệm về "đâu là output của KA này" sẽ trở nên hiển nhiên. Học bằng cách làm là cách ghi nhớ bền nhất.
Khái niệm cốt lõi
BRD là gì và nó ở đâu trong BABOK?
BRD — Business Requirements Document — là tài liệu tổng hợp mô tả nhu cầu nghiệp vụ (business needs) và các yêu cầu cấp cao của một giải pháp, dưới góc nhìn của doanh nghiệp chứ không phải kỹ thuật. Nó trả lời ba câu hỏi nền tảng: Tại sao chúng ta làm dự án này? Chúng ta muốn đạt được gì? Giải pháp phải đáp ứng những gì?
Lưu ý: BABOK Guide v3 không định nghĩa một template "BRD" cứng nhắc — đây là tài liệu phổ biến trong thực tế ngành chứ không phải artifact bắt buộc của framework. Trong ngôn ngữ BABOK, BRD là một dạng đóng gói của requirements ở mức business requirements và stakeholder requirements (xem lại phân loại requirements: business → stakeholder → solution → transition).
Bốn tầng requirements bạn cần phân biệt
Khi viết BRD, bạn phải luôn ý thức requirement của mình đang ở tầng nào:
- Business requirements: mục tiêu, lý do của tổ chức. Ví dụ: "Tăng doanh thu đặt hàng online 30% trong 12 tháng."
- Stakeholder requirements: nhu cầu của một nhóm liên quan cụ thể. Ví dụ: "Chủ nhà hàng muốn xem báo cáo doanh thu theo ngày."
- Solution requirements: chia thành functional (chức năng) và non-functional (phi chức năng). Ví dụ functional: "Hệ thống cho phép khách thanh toán bằng MoMo." Non-functional: "Màn hình menu tải dưới 2 giây."
- Transition requirements: yêu cầu tạm thời để chuyển từ trạng thái hiện tại sang trạng thái mới. Ví dụ: "Di chuyển dữ liệu 5.000 món ăn từ Excel sang hệ thống mới."
Các thành phần xương sống của một BRD
Một BRD thực dụng thường gồm: (1) Executive Summary, (2) Business Objectives & Success Metrics, (3) Project Scope (in-scope / out-of-scope), (4) Stakeholders, (5) Current State & Problem Statement, (6) Business Requirements, (7) Functional & Non-Functional Requirements ở mức cao, (8) Assumptions & Constraints, (9) Risks, (10) Acceptance Criteria. Bạn không cần phát minh template — chỉ cần điền có chủ đích.
Tình huống thực tế
Tình huống 1 — FastBite: scope mơ hồ suýt làm chìm dự án
Đây chính là bối cảnh chúng ta sẽ thực hành. FastBite là một startup F&B tại TP.HCM, muốn ra mắt app đặt hàng kết nối 50 chuỗi nhà hàng, mục tiêu 100.000 người dùng trong năm đầu. Founder — anh Tuấn — giao cho bạn (BA mới) viết BRD.
Trong buổi họp đầu, anh Tuấn nói một mạch: "App phải có đặt hàng, giao hàng, loyalty point, chat với shipper, đặt bàn, review món, có cả tính năng livestream nấu ăn nữa cho hot." Một BA non kinh nghiệm sẽ ghi hết vào BRD. Nhưng bạn nhận ra: với ngân sách giai đoạn 1 và mục tiêu chính là đặt hàng giao đi, thì livestream và đặt bàn là phạm vi "nice to have" — phải đẩy xuống out-of-scope của bản 1.0.
Bài học: BRD không phải nơi chép lại mọi mong muốn. Sức mạnh thật của BA nằm ở mục Out-of-Scope — dám viết rõ "phiên bản này KHÔNG làm livestream" để bảo vệ team khỏi scope creep. Khi bạn đưa danh sách out-of-scope cho anh Tuấn ký xác nhận, bạn vừa làm đúng tinh thần Define the Solution Scope của Strategy Analysis.
Tình huống 2 — Một ví dụ đời thực kiểu Baemin Việt Nam
Khi Baemin (thương hiệu giao đồ ăn từng hoạt động mạnh tại Việt Nam) thâm nhập thị trường, một bài toán BA điển hình của họ là thanh toán nội địa. Một solution requirement tưởng đơn giản — "cho phép thanh toán" — thực ra ẩn chứa cả business requirement: người dùng Việt Nam thời điểm đó vẫn ưa COD (trả tiền mặt khi nhận hàng). Nếu BA chỉ viết "tích hợp thẻ Visa/Master", app sẽ thất bại với phân khúc lớn.
Bài học: requirement luôn phải truy ngược về nhu cầu nghiệp vụ thực và bối cảnh người dùng địa phương. Trong BRD FastBite, bạn phải ghi rõ: "Hỗ trợ COD, MoMo, ZaloPay là bắt buộc; thẻ quốc tế là tùy chọn." Con số biện minh: theo các khảo sát thị trường giai đoạn 2020–2022, ví điện tử và COD chiếm phần áp đảo giao dịch F&B online tại Việt Nam. Requirement không có dẫn chứng dễ bị stakeholder bác bỏ.
Tình huống 3 — Non-functional bị bỏ quên ở một chuỗi trà sữa
Một chuỗi trà sữa giả định, "BoBa Tea" với 30 cửa hàng, từng tự build app đặt hàng. BRD của họ liệt kê đầy đủ chức năng nhưng quên hẳn non-functional về tải đồng thời. Vào khung 17h–19h giờ cao điểm, hàng nghìn đơn đổ về cùng lúc, app sập 20 phút mỗi tối. Doanh thu thiệt hại không nhỏ, và nguyên nhân gốc là một dòng requirement bị thiếu.
Bài học: trong BRD FastBite, mục non-functional phải có dòng cụ thể: "Hệ thống chịu tải tối thiểu 2.000 đơn hàng đồng thời trong khung giờ cao điểm 11h–13h và 17h–20h, thời gian phản hồi dưới 3 giây." Một requirement non-functional viết rõ con số đáng giá hơn cả trăm dòng mô tả chức năng đẹp đẽ.
Hướng dẫn từng bước
Dưới đây là quy trình viết BRD cho FastBite. Hãy thực hiện đúng thứ tự.
Bước 1 — Viết Problem Statement & Business Objectives. Bắt đầu bằng vấn đề, không phải giải pháp. Ví dụ: "Hiện 50 chuỗi nhà hàng đối tác nhận đơn qua điện thoại và Facebook, dẫn đến sai sót đơn 12% và không có dữ liệu khách hàng." Rồi đặt mục tiêu SMART: "Đạt 100.000 người dùng đăng ký và 30.000 đơn/tháng trong 12 tháng kể từ launch." Mỗi objective phải đo được.
Bước 2 — Xác định Success Metrics. Gắn từng objective với một chỉ số: số user đăng ký, tỷ lệ đặt lại đơn (repeat order rate), giá trị đơn trung bình (AOV), tỷ lệ giao thành công. Đây là cơ sở để sau này đo Solution Performance.
Bước 3 — Định nghĩa Scope rõ ràng hai chiều. Lập bảng In-Scope (đặt hàng, thanh toán COD/ví, theo dõi đơn, loyalty point cơ bản) và Out-of-Scope (livestream, đặt bàn, app cho shipper riêng — giai đoạn 2). Viết câu cảnh báo: "Mọi thay đổi scope phải qua change request."
Bước 4 — Liệt kê Stakeholders. Ít nhất: Founder, chủ nhà hàng đối tác, khách hàng cuối, shipper, đội vận hành, phòng marketing. Với mỗi nhóm, ghi nhu cầu chính một dòng. Đây là đầu vào để viết stakeholder requirements.
Bước 5 — Viết Business Requirements. Mỗi requirement một dòng, đánh mã (BR-01, BR-02…), có thể truy vết về objective. Ví dụ: "BR-03: Hệ thống thu thập dữ liệu hành vi đặt hàng để phục vụ marketing."
Bước 6 — Viết Functional Requirements mức cao. Đánh mã FR-01… Ví dụ: "FR-05: Khách hàng có thể lọc món theo nhà hàng, danh mục và khoảng giá." Đừng đi sâu vào màn hình — đó là việc của thiết kế.
Bước 7 — Viết Non-Functional Requirements với con số. Hiệu năng, bảo mật (mã hóa thông tin thanh toán), khả dụng (uptime 99,5%), tải đồng thời. Mỗi dòng phải đo được.
Bước 8 — Ghi Assumptions, Constraints, Risks. Giả định: "Các nhà hàng đối tác có nhân viên cập nhật menu." Ràng buộc: "Ngân sách giai đoạn 1 cố định, launch trong 4 tháng." Rủi ro: "Nhà hàng không cập nhật tồn kho kịp dẫn đến hủy đơn."
Bước 9 — Định nghĩa Acceptance Criteria cấp dự án. Điều kiện để nghiệm thu BRD/giải pháp: ví dụ "Đặt được đơn hoàn chỉnh end-to-end với 3 phương thức thanh toán."
Bước 10 — Rà soát với stakeholder và lấy phê duyệt. BRD chưa được ký thì chỉ là bản nháp. Gửi cho anh Tuấn và đại diện nhà hàng, ghi nhận phản hồi, cập nhật version, lấy sign-off.
Lỗi thường gặp & mẹo
Lỗi 1 — Viết solution thay vì requirement. Câu "Làm một nút màu cam ở góc phải để đặt hàng" là thiết kế, không phải requirement. Đúng phải là "Khách hàng có thể đặt hàng từ màn hình menu". Mẹo: nếu câu của bạn mô tả cách làm, hãy lùi lại hỏi cần gì.
Lỗi 2 — Requirement không đo được. "App phải nhanh", "giao diện thân thiện" là vô nghĩa với người kiểm thử. Mẹo: mỗi requirement phải vượt qua bài kiểm tra "làm sao biết nó đạt?". Nếu không trả lời được, viết lại với con số.
Lỗi 3 — Bỏ quên out-of-scope. Đây là lỗi chí mạng dẫn đến scope creep. Mẹo: dành riêng một mục in đậm cho out-of-scope và bắt stakeholder xác nhận.
Lỗi 4 — Trộn lẫn các tầng requirement. Để business objective nằm chung lộn xộn với chi tiết chức năng khiến tài liệu rối. Mẹo: tách section rõ ràng theo bốn tầng.
Lỗi 5 — Viết một mình rồi mới gửi. BRD là sản phẩm cộng tác. Mẹo: rà soát sớm và thường xuyên với stakeholder, đừng đợi hoàn hảo mới gửi.
Mẹo vàng — Traceability. Đánh mã mọi requirement (BR-xx, FR-xx, NFR-xx) và liên kết ngược về objective. Khi stakeholder hỏi "tại sao có tính năng này?", bạn truy được ngay. Đây là tinh thần của Requirements Life Cycle Management áp dụng vào thực tế.
Bài tập thực hành
Hãy tự tay hoàn thành BRD cho FastBite. Đừng đọc cho biết — hãy mở một file và viết thật.
- Problem Statement & 3 Business Objectives SMART: viết đoạn mô tả vấn đề hiện tại của 50 chuỗi nhà hàng và 3 mục tiêu đo được.
- Bảng Scope: liệt kê tối thiểu 6 mục in-scope và 4 mục out-of-scope, kèm câu cảnh báo change request.
- Stakeholder list: 6 nhóm stakeholder, mỗi nhóm một nhu cầu chính.
- 5 Business Requirements (BR-01 đến BR-05) truy vết về objective.
- 8 Functional Requirements (FR-01 đến FR-08) mức cao, không lậm thiết kế.
- 4 Non-Functional Requirements (NFR-01 đến NFR-04), mỗi cái có con số đo được.
- 3 Assumptions, 3 Constraints, 3 Risks.
- Acceptance Criteria cấp dự án: 3 điều kiện nghiệm thu.
Tóm tắt
BRD là tài liệu đóng gói nhu cầu nghiệp vụ và yêu cầu cấp cao dưới góc nhìn doanh nghiệp, gồm các phần xương sống: mục tiêu, success metrics, scope hai chiều, stakeholders, requirements bốn tầng, assumptions/constraints/risks và acceptance criteria. Sức mạnh của một BA giỏi không nằm ở việc chép lại mọi mong muốn, mà ở khả năng định nghĩa scope rõ ràng (đặc biệt là out-of-scope), viết requirement đo được, phân tầng đúng và truy vết được về mục tiêu. Qua project FastBite, bạn đã đi trọn dòng chảy từ vấn đề đến yêu cầu — biến lý thuyết BABOK thành một sản phẩm cụ thể có thể đưa vào portfolio. Hãy hoàn thành bài tập, vì một BRD bạn tự viết đáng giá hơn mười bài lý thuyết bạn chỉ đọc qua. Ở Bài 58, chúng ta sẽ chuyển sang viết User Stories — một dạng đóng gói requirement linh hoạt hơn cho môi trường Agile.