BRD (Business Requirement Document) là tài liệu mô tả yêu cầu kinh doanh, được lập ở giai đoạn đầu dự án để thống nhất mục tiêu, phạm vi và kỳ vọng giữa doanh nghiệp, khách hàng và đội dự án. Cách viết một tài liệu BRD chuẩn gồm 7 bước cốt lõi: thu thập yêu cầu, xác định phạm vi, phân tích và tổng hợp, soạn thảo theo cấu trúc chuẩn, rà soát nội bộ, trình ký phê duyệt, và kiểm soát phiên bản khi có thay đổi.
Nếu bạn là Business Analyst mới vào nghề hoặc đang chuẩn bị viết BRD đầu tiên cho dự án, bài viết này sẽ hướng dẫn chi tiết từng bước, kèm cấu trúc chuẩn, ví dụ minh họa thực tế và những lỗi cần tránh để tài liệu của bạn không chỉ "đúng mẫu" mà còn thực sự hữu ích cho dự án. BRD chỉ là một trong nhiều loại tài liệu BA mà bạn sẽ cần thành thạo trong suốt sự nghiệp.
Mục Lục
BRD là gì? Phân biệt nhanh với SRS và FRS
BRD là tài liệu mô tả yêu cầu kinh doanh ở mức tổng quan — trả lời câu hỏi "Tại sao dự án này cần tồn tại?" và "Nó mang lại giá trị gì cho doanh nghiệp?". Đây là tài liệu dành cho cấp quản lý, nhà đầu tư và khách hàng, được lập trước khi đi vào các tài liệu kỹ thuật chi tiết hơn. Khái niệm này cũng nằm trong nhóm kỹ thuật phân tích yêu cầu (requirements analysis) được IIBA — tổ chức nghề nghiệp quốc tế dành cho Business Analyst — hệ thống hóa trong bộ khung kiến thức BABOK Guide.
Để tránh nhầm lẫn — một lỗi rất phổ biến với BA mới — dưới đây là bảng so sánh nhanh:
| Tiêu chí | BRD | SRS | FRS |
|---|---|---|---|
| Trả lời câu hỏi | Tại sao? (Why) | Hệ thống hoạt động thế nào? (How) | Hệ thống làm gì cụ thể? (What) |
| Đối tượng đọc | Ban lãnh đạo, khách hàng, nhà đầu tư | Đội kỹ thuật, kiến trúc sư hệ thống | Đội dev, tester |
| Mức độ chi tiết | Tổng quan | Chi tiết (chức năng + phi chức năng) | Rất chi tiết theo từng chức năng |
| Thời điểm lập | Đầu dự án | Sau khi BRD được duyệt | Sau hoặc song song với SRS |
Cấu trúc chuẩn của một tài liệu BRD
Một tài liệu BRD đầy đủ thường gồm các phần sau. Bạn có thể co giãn mức độ chi tiết tùy quy mô dự án, nhưng nên giữ đủ 8 phần cốt lõi này:
Title Page (Trang bìa) — Tên dự án, tác giả, ngày lập, phiên bản.
Document Revision History (Lịch sử chỉnh sửa) — Bảng theo dõi các lần cập nhật, ai sửa, sửa gì.
Executive Summary (Tóm tắt điều hành) — Tóm tắt ngắn gọn bối cảnh, mục tiêu và giá trị dự án mang lại.
Project Scope (Phạm vi dự án) — Rõ ràng những gì nằm trong phạm vi (in-scope) và ngoài phạm vi (out-of-scope).
Business Objectives (Mục tiêu kinh doanh) — Các mục tiêu cụ thể, đo lường được (nên áp dụng nguyên tắc SMART).
Stakeholders (Các bên liên quan) — Danh sách người liên quan, vai trò và mức độ ảnh hưởng.
Business Requirements (Yêu cầu kinh doanh chi tiết) — Liệt kê từng yêu cầu, có mã số để dễ truy vết (traceability).
Assumptions, Constraints & Risks (Giả định, ràng buộc và rủi ro) — Những yếu tố có thể ảnh hưởng đến dự án.
Approval / Sign-off (Phê duyệt) — Chữ ký xác nhận từ các bên liên quan chính.
Mẹo thực tế: Trước khi bắt tay viết BRD, hãy hỏi công ty hoặc dự án đã có template BRD sẵn chưa. Nếu có, hãy tận dụng và điều chỉnh theo tình hình dự án thay vì xây từ đầu — vừa tiết kiệm thời gian, vừa đảm bảo tính nhất quán với các tài liệu khác trong tổ chức.
Cách viết tài liệu BRD: 7 bước chi tiết
Bước 1: Thu thập yêu cầu từ stakeholder
Đây là bước nền tảng quyết định chất lượng toàn bộ tài liệu. BA cần tổ chức phỏng vấn, workshop hoặc khảo sát để thu thập yêu cầu trực tiếp từ các bên liên quan: chủ đầu tư, phòng ban nghiệp vụ, người dùng cuối.
Lưu ý quan trọng: Hãy luôn xác định rõ bạn đang viết tài liệu cho ai đọc. Một BRD viết cho ban lãnh đạo cần ngôn ngữ kinh doanh, súc tích; trong khi thông tin chi tiết kỹ thuật nên để dành cho SRS/FRS ở bước sau. Đặt mình vào góc nhìn người đọc sẽ giúp bạn chọn đúng mức độ chi tiết cần thiết.
Bước 2: Xác định phạm vi và mục tiêu dự án
Từ thông tin thu thập được, xác định rõ ràng ranh giới dự án: điều gì sẽ được thực hiện (in-scope) và điều gì không thuộc phạm vi lần này (out-of-scope). Đây là bước giúp phòng tránh tình trạng "phình phạm vi" (scope creep) — một trong những nguyên nhân hàng đầu khiến dự án trễ tiến độ.
Bước 3: Phân tích và tổng hợp yêu cầu nghiệp vụ
Sắp xếp các yêu cầu thu thập được theo nhóm logic, loại bỏ yêu cầu trùng lặp hoặc mâu thuẫn, và ưu tiên hóa theo mức độ quan trọng (ví dụ dùng mô hình MoSCoW: Must have, Should have, Could have, Won't have).
Bước 4: Soạn thảo nội dung theo cấu trúc chuẩn
Viết tài liệu theo 8-9 phần đã nêu ở trên. Một số nguyên tắc viết cần nhớ:
Mỗi yêu cầu nên có mã số riêng (VD: BR-001, BR-002) để thuận tiện truy vết sang các tài liệu sau (SRS, Use Case, Test Case).
Diễn đạt yêu cầu theo hướng kết quả kinh doanh, tránh lẫn vào giải pháp kỹ thuật cụ thể (đó là việc của SRS/FRS).
Sử dụng sơ đồ, bảng biểu để minh họa quy trình nghiệp vụ thay vì mô tả dài dòng bằng chữ — nếu chưa quen với các loại sơ đồ này, bạn có thể tham khảo thêm về UML trong công việc Business Analyst.
Bước 5: Rà soát nội bộ (Peer Review)
Trước khi gửi cho stakeholder bên ngoài, nên có ít nhất một BA khác hoặc PM rà soát lại tài liệu để phát hiện các điểm mâu thuẫn, thiếu sót hoặc diễn đạt chưa rõ ràng.
Bước 6: Trình bày và xin phê duyệt (Sign-off)
Gửi bản BRD hoàn chỉnh cho các stakeholder chính để xác nhận. Đây là bước bắt buộc — một BRD chưa được sign-off không nên dùng làm căn cứ để triển khai các bước tiếp theo, vì rủi ro hiểu sai yêu cầu vẫn còn tồn tại.
Bước 7: Kiểm soát phiên bản khi có thay đổi
Trong thực tế, yêu cầu kinh doanh có thể thay đổi trong quá trình dự án. Mỗi lần chỉnh sửa cần được ghi nhận vào phần Document Revision History, kèm lý do thay đổi và người phê duyệt thay đổi đó.
Ví dụ minh họa: Đoạn Executive Summary và Scope mẫu
Để bạn hình dung rõ hơn, dưới đây là ví dụ rút gọn cho hai phần quan trọng nhất của một BRD (dự án giả định: xây dựng hệ thống đặt lịch khám bệnh online cho phòng khám):
Executive Summary (ví dụ):
Dự án nhằm xây dựng hệ thống đặt lịch khám bệnh trực tuyến, giúp giảm thời gian chờ đợi tại quầy lễ tân và tăng tỷ lệ lấp đầy lịch khám của bác sĩ. Hệ thống dự kiến triển khai trong 3 tháng, phục vụ trung bình 500 lượt đặt lịch/ngày.
Project Scope (ví dụ):
In-scope: Đặt lịch khám online, nhắc lịch qua SMS, quản lý lịch bác sĩ.
Out-of-scope: Thanh toán online, hồ sơ bệnh án điện tử (sẽ triển khai ở giai đoạn 2).
Việc viết ví dụ cụ thể như trên giúp stakeholder hình dung rõ ràng thay vì chỉ đọc lý thuyết chung chung — đây cũng là điều giúp BRD của bạn thực sự "dùng được" chứ không chỉ là thủ tục giấy tờ.
Những lỗi thường gặp khi viết BRD
Yêu cầu mơ hồ, không đo lường được — ví dụ viết "hệ thống cần nhanh" thay vì "thời gian phản hồi dưới 2 giây".
Không xác định rõ phạm vi, dẫn đến scope creep khi dự án đã chạy được nửa chừng.
Thiếu sự tham gia và xác nhận của stakeholder — BRD do một mình BA "tự viết tự hiểu" rất dễ sai lệch so với kỳ vọng thực tế.
Lẫn lộn giữa yêu cầu kinh doanh và giải pháp kỹ thuật — BRD nên tập trung vào "cái gì" và "tại sao", để phần "làm thế nào" cho SRS/FRS. Nếu chưa nắm rõ ranh giới giữa các loại tài liệu này, hãy xem lại phân biệt BRD, SRS, FRS và các tài liệu BA khác.
Không kiểm soát phiên bản tài liệu, khiến các bên làm việc trên những bản BRD không đồng nhất.
Công cụ hỗ trợ viết tài liệu BRD
Confluence, Notion — soạn thảo và lưu trữ tài liệu tập trung, dễ chia sẻ và theo dõi lịch sử chỉnh sửa.
Google Docs / Microsoft Word — phù hợp khi cần gửi bản chính thức để sign-off.
Miro, Draw.io — hỗ trợ brainstorm và vẽ sơ đồ quy trình nghiệp vụ minh họa trong BRD.
Jira — liên kết các yêu cầu trong BRD với backlog để truy vết xuyên suốt dự án.
Câu hỏi thường gặp (FAQ)
BRD nên dài bao nhiêu trang? Không có con số cố định — độ dài phụ thuộc vào quy mô dự án. Với dự án nhỏ, BRD có thể chỉ 3-5 trang; dự án lớn, phức tạp có thể lên đến vài chục trang. Nguyên tắc quan trọng hơn độ dài là: đủ rõ ràng để mọi bên hiểu đúng yêu cầu, không thừa thông tin không cần thiết.
Ai là người chịu trách nhiệm viết BRD trong dự án? Business Analyst thường là người chủ trì soạn thảo BRD, nhưng cần phối hợp chặt chẽ với Project Manager (về phạm vi, tiến độ) và các stakeholder nghiệp vụ để đảm bảo nội dung phản ánh đúng yêu cầu thực tế trước khi trình ký. Đây cũng là một trong những kỹ năng tài liệu cốt lõi nằm trong lộ trình trở thành Business Analyst thực chiến.
BRD viết trước hay sau khi có SRS? BRD luôn được viết trước. BRD xác định "tại sao" và "cái gì" ở mức tổng quan, làm nền tảng để đội kỹ thuật triển khai SRS/FRS mô tả chi tiết "làm thế nào" ở bước tiếp theo.
Có cần BRD trong dự án Agile không? Có, nhưng thường ở dạng gọn nhẹ hơn so với mô hình Waterfall truyền thống. Nhiều đội Agile vẫn duy trì một bản BRD rút gọn (lightweight BRD) để thống nhất mục tiêu kinh doanh tổng thể, trước khi chi tiết hóa thành User Story cho từng sprint.
Làm sao biết một BRD đã đạt chuẩn, đủ tốt? Một BRD tốt cần đáp ứng các tiêu chí: yêu cầu rõ ràng và đo lường được, không mâu thuẫn nội bộ, được các stakeholder chính xác nhận (sign-off), và đủ chi tiết để đội kỹ thuật có thể dựa vào đó xây dựng SRS mà không cần hỏi lại những thông tin cơ bản.
Kết luận
Viết một tài liệu BRD chuẩn không chỉ là điền vào các mục có sẵn trong template, mà là quá trình lắng nghe, phân tích và chuyển hóa yêu cầu kinh doanh thành một tài liệu rõ ràng, đo lường được và có sự đồng thuận của tất cả các bên liên quan. Ba yếu tố cốt lõi cần nhớ:
Thu thập yêu cầu kỹ lưỡng trước khi đặt bút viết — chất lượng input quyết định chất lượng BRD.
Bám sát cấu trúc chuẩn nhưng linh hoạt điều chỉnh theo quy mô và bối cảnh dự án.
Luôn có bước rà soát và sign-off — đây là "lưới an toàn" giúp giảm thiểu rủi ro hiểu sai yêu cầu trong suốt vòng đời dự án.
Nắm vững cách viết BRD là bước khởi đầu quan trọng trước khi bạn tiến tới các tài liệu BA chuyên sâu hơn như SRS, FRS hay Use Case Document — những mảnh ghép tiếp theo trong bộ hồ sơ yêu cầu của một Business Analyst chuyên nghiệp. Nếu bạn muốn học bài bản từ cách viết BRD, SRS chuẩn doanh nghiệp đến thực hành dự án thực tế, có thể tham khảo thêm khóa học IT Business Analyst tại Cole.
.png)
