Mở đầu — vì sao bài này quan trọng
Khi bạn còn làm Marketing, "tài liệu" thường là một bản brief chiến dịch, một content calendar, hay một báo cáo performance gửi sếp. Ai đọc cũng hiểu, ngôn ngữ thoải mái, và nếu thiếu chi tiết thì... hỏi lại nhau qua Slack là xong. Bước sang nghề BA, tài liệu trở thành "hợp đồng" giữa nhiều bên: business muốn một đằng, developer hiểu một nẻo, tester thì dựa vào tài liệu để biết phải kiểm thử cái gì. Một câu mô tả mơ hồ trong tài liệu BA có thể khiến cả đội dev xây sai trong hai tuần, tốn vài chục triệu đồng công sức, và bạn là người chịu trách nhiệm.
Đây chính là lý do ba loại tài liệu BRD, FRD và SRS tồn tại. Chúng không phải thủ tục giấy tờ rườm rà mà là cách ngành phần mềm chia thông tin theo "tầng" — mỗi tầng nói chuyện với một nhóm người, ở một độ chi tiết khác nhau. Hiểu sai ranh giới giữa chúng là lỗi kinh điển của BA mới vào nghề, đặc biệt với người từ Marketing vốn quen viết "một tài liệu cho tất cả mọi người".
Trong bài này, tôi sẽ giúp bạn phân biệt rạch ròi ba loại tài liệu: ai đọc, viết gì, chi tiết đến đâu, và quan trọng nhất là khi nào dùng cái nào. Đây là kiến thức nền tảng mà mọi nhà tuyển dụng BA tại Việt Nam đều mặc định bạn phải nắm.
Khái niệm cốt lõi
Hãy hình dung một dự án phần mềm như việc xây nhà. BRD là bản thỏa thuận với chủ nhà về việc "tôi muốn một căn nhà 3 phòng ngủ cho gia đình 5 người, ngân sách 2 tỷ, hoàn thành trước Tết". FRD là bản vẽ kiến trúc chi tiết: phòng khách rộng bao nhiêu mét, cửa mở hướng nào, hệ thống điện chạy ra sao. SRS là tài liệu kỹ thuật đầy đủ cho cả thợ xây lẫn kỹ sư: vật liệu gì, chịu tải bao nhiêu, tiêu chuẩn an toàn nào.
BRD — Business Requirements Document
BRD trả lời câu hỏi "Tại sao" và "Cái gì ở tầm kinh doanh".
- Người đọc: sponsor (người chi tiền cho dự án), ban giám đốc, trưởng các bộ phận nghiệp vụ. Đây là những người không quan tâm nút bấm màu gì, họ quan tâm dự án này mang lại bao nhiêu doanh thu.
- Nội dung chính: mục tiêu kinh doanh (business objectives), phạm vi dự án (scope — cái gì làm, cái gì KHÔNG làm), các bên liên quan, success metrics (chỉ số đo lường thành công), giả định và ràng buộc, đánh giá rủi ro và lợi ích sơ bộ.
- Ngôn ngữ: ngôn ngữ kinh doanh, không có thuật ngữ kỹ thuật. Một giám đốc tài chính đọc phải hiểu ngay.
- Độ dài tiêu biểu: 5–15 trang.
FRD — Functional Requirements Document
FRD trả lời câu hỏi "Hệ thống PHẢI LÀM GÌ" để đạt được mục tiêu kinh doanh đã nêu trong BRD.
- Người đọc: team phát triển (developer, tester), Product Owner, BA khác, đôi khi cả khách hàng đầu mối.
- Nội dung chính: mô tả từng chức năng (functional requirement) cụ thể của hệ thống — input, xử lý, output; các luồng nghiệp vụ; quy tắc nghiệp vụ (business rules); các trường hợp ngoại lệ (exception flows).
- Ngôn ngữ: chi tiết, rõ ràng, mỗi yêu cầu đánh số để truy vết được (ví dụ FR-012).
- Độ dài tiêu biểu: 20–60 trang tùy quy mô.
SRS — Software Requirements Specification
SRS là tài liệu toàn diện và kỹ thuật nhất, thường gộp cả yêu cầu chức năng VÀ yêu cầu phi chức năng (non-functional requirements) cùng các ràng buộc kỹ thuật.
- Người đọc: chủ yếu là đội kỹ thuật — developer, kiến trúc sư hệ thống (solution architect), QA, DevOps.
- Nội dung chính: tất cả yêu cầu chức năng (như FRD) + yêu cầu phi chức năng (hiệu năng, bảo mật, khả năng mở rộng, độ sẵn sàng) + giao diện hệ thống (system interfaces, API) + ràng buộc công nghệ + tiêu chí chấp nhận.
- Chuẩn tham chiếu: SRS thường tuân theo chuẩn quốc tế IEEE 830 (hoặc bản kế thừa ISO/IEC/IEEE 29148).
- Độ dài: có thể lên đến hàng trăm trang ở các dự án lớn như ngân hàng lõi.
Mối quan hệ giữa ba tài liệu
Điều quan trọng nhất cần khắc cốt ghi tâm: ba tài liệu này không phải ba lựa chọn thay thế nhau, mà là ba tầng chi tiết dần. BRD đẻ ra FRD, FRD là một phần của SRS. Một yêu cầu kinh doanh trong BRD sẽ "nở" thành nhiều yêu cầu chức năng trong FRD, và mỗi yêu cầu chức năng đó còn kèm theo các ràng buộc kỹ thuật trong SRS.
Trong thực tế ở Việt Nam, không phải dự án nào cũng dùng đủ cả ba. Nhiều công ty product (Tiki, MoMo, VNG) làm Agile nên thay FRD/SRS bằng User Story + Acceptance Criteria trên Jira. Nhưng các công ty outsourcing làm cho khách Nhật, khách Mỹ (FPT Software, CMC) hay dự án ngân hàng thì vẫn dùng tài liệu chuẩn rất nghiêm ngặt. Là BA, bạn phải đọc được "không khí" của tổ chức để biết dùng tài liệu nào.
Tình huống thực tế
Tình huống 1: Sàn TMĐT giả định "ShopViet" — khi gộp ba tài liệu làm một
ShopViet, một sàn thương mại điện tử quy mô vừa tại TP.HCM, muốn xây tính năng "mua trước trả sau" (Buy Now Pay Later). Một BA mới chuyển từ Marketing sang viết một tài liệu duy nhất dài 40 trang, trộn lẫn mục tiêu kinh doanh, mô tả chức năng và cả yêu cầu hiệu năng vào nhau.
Kết quả: khi gửi cho ban giám đốc duyệt ngân sách, họ bị "ngợp" giữa các đoạn nói về "API gọi tới đối tác tín dụng phải dùng OAuth 2.0" — thứ họ không hiểu và cũng không cần biết. Cuộc họp phê duyệt bị hoãn hai tuần vì sếp không nắm được bức tranh kinh doanh. Cùng lúc đó, team dev lại phàn nàn rằng business objective chiếm nửa tài liệu nhưng phần spec kỹ thuật thì sơ sài.
Diễn giải: Lỗi ở đây không phải BA viết dở, mà là không tách tầng. Đáng lẽ phải có một BRD 8 trang gửi ban giám đốc (mục tiêu: tăng giá trị đơn hàng trung bình 25%, mở rộng tệp khách hàng trẻ), và một FRD riêng cho team kỹ thuật.
Bài học: Một tài liệu phục vụ nhiều đối tượng cùng lúc thường phục vụ kém tất cả. Hãy hỏi "ai sẽ ký vào tài liệu này?" trước khi đặt bút.
Tình huống 2: Dự án ngân hàng tại FPT Software — SRS cứu cả dự án
Một team tại FPT Software làm dự án cho một ngân hàng ở Singapore, xây module mở tài khoản tiết kiệm online. Khách hàng yêu cầu tài liệu SRS theo chuẩn IEEE 830. BA ban đầu thấy "phiền phức" vì phải viết cả phần non-functional requirements rất chi tiết.
Đến giai đoạn kiểm thử, phía ngân hàng khiếu nại rằng hệ thống mở tài khoản chậm khi nhiều người dùng. Nhờ trong SRS đã ghi rõ NFR: "Hệ thống xử lý tối đa 200 yêu cầu mở tài khoản mỗi phút, thời gian phản hồi dưới 3 giây ở mức 90 phần trăm" — team chứng minh được rằng hệ thống đang chạy đúng cam kết (180 yêu cầu/phút), còn ngân hàng đang kỳ vọng 500 yêu cầu/phút mà chưa từng ghi vào yêu cầu nào. Tranh chấp được giải quyết trong một buổi họp, không ai phải đền hợp đồng.
Diễn giải: Yêu cầu phi chức năng — thứ mà người mới hay bỏ qua vì "vô hình" — chính là tấm khiên pháp lý và kỹ thuật cho dự án.
Bài học: SRS không chỉ để xây đúng, mà còn để bảo vệ team khi có tranh chấp. Cái gì không được viết ra coi như không tồn tại.
Tình huống 3: Startup edtech làm Agile — bỏ FRD nhưng giữ "tinh thần" FRD
Một startup edtech tại Hà Nội (khoảng 30 người) làm sản phẩm học tiếng Anh, chạy Scrum 2 tuần một sprint. Họ không viết FRD hay SRS chính thức — thay vào đó dùng User Story trên Jira. Tuy nhiên, BA của họ vẫn duy trì một tài liệu BRD nhẹ (4 trang) mỗi khi mở một epic lớn như "tính năng luyện thi IELTS", để founder và nhà đầu tư hiểu mục tiêu và ngân sách.
Có lần một developer xây tính năng chấm điểm phát âm mà không rõ "đạt chuẩn" là bao nhiêu điểm. Hóa ra business rule (điểm tối thiểu để pass) chưa được ghi rõ ở đâu cả. Sau sự cố, team thêm một mục "Business Rules" cố định vào mỗi User Story — chính là "tinh thần" của FRD được nhúng vào Agile.
Diễn giải: Agile không có nghĩa là không có tài liệu, mà là tài liệu vừa đủ, đúng lúc.
Bài học: Dù công ty không dùng FRD/SRS chính thức, bản chất thông tin (chức năng, business rule, tiêu chí chấp nhận) vẫn phải tồn tại ở đâu đó. Là BA, bạn chịu trách nhiệm đảm bảo thông tin đó không biến mất.
Hướng dẫn từng bước
Đây là quy trình thực tế để bạn quyết định và soạn tài liệu cho một yêu cầu mới:
- Xác định đối tượng đọc. Hỏi: ai cần ra quyết định dựa trên tài liệu này? Nếu là sếp/sponsor để duyệt tiền → BRD. Nếu là team dev để xây → FRD. Nếu cần cả ràng buộc kỹ thuật cho kiến trúc sư → SRS.
- Bắt đầu từ BRD trước. Luôn làm rõ "tại sao" trước khi xuống "cái gì" và "như thế nào". Viết mục tiêu kinh doanh, phạm vi, và success metrics. Đây là phần người từ Marketing làm rất tốt vì bạn quen tư duy mục tiêu và chỉ số.
- "Nở" mỗi yêu cầu kinh doanh thành các yêu cầu chức năng. Lấy từng dòng trong scope của BRD, hỏi "để đạt được điều này, hệ thống phải làm những gì?". Mỗi câu trả lời là một functional requirement, đánh số FR-xxx.
- Bổ sung yêu cầu phi chức năng. Với mỗi chức năng, hỏi tiếp: nhanh đến đâu? bảo mật ra sao? chịu được bao nhiêu người dùng? Nếu dự án cần chuẩn kỹ thuật cao, gộp tất cả vào SRS.
- Đảm bảo truy vết (traceability). Mỗi FR phải nối được về một mục tiêu trong BRD. Nếu một chức năng không phục vụ mục tiêu nào, hãy nghi ngờ — có thể đó là gold-plating (làm thừa).
- Lấy chữ ký phê duyệt (sign-off). BRD do business/sponsor duyệt. FRD/SRS do Product Owner và tech lead duyệt. Đây là bước biến tài liệu thành "hợp đồng" chính thức.
Lỗi thường gặp & mẹo
Lỗi 1 — Trộn lẫn ba tầng vào một tài liệu. Như tình huống ShopViet. Mẹo: trước khi viết mỗi đoạn, tự hỏi "đoạn này thuộc tầng tại sao, cái gì, hay như thế nào?".
Lỗi 2 — Viết yêu cầu mơ hồ. "Hệ thống phải nhanh" là vô nghĩa. Mẹo: mọi yêu cầu phải đo lường được. "Nhanh" phải thành "phản hồi dưới 2 giây".
Lỗi 3 — Bỏ quên non-functional requirements. Người mới chỉ tập trung chức năng nhìn thấy được, quên hiệu năng và bảo mật. Mẹo: dùng checklist NFR (hiệu năng, bảo mật, khả năng mở rộng, độ tin cậy, khả năng sử dụng) cho mọi tính năng quan trọng.
Lỗi 4 — Coi BRD/FRD/SRS là bắt buộc cứng nhắc. Trong môi trường Agile, ép viết SRS 200 trang là phản tác dụng. Mẹo: hiểu bản chất thông tin cần truyền đạt, rồi chọn hình thức phù hợp văn hóa công ty.
Lỗi 5 — Quên đánh số và truy vết. Khi yêu cầu thay đổi, không biết nó ảnh hưởng đến đâu. Mẹo: luôn đánh mã (BR-01, FR-12, NFR-03) và lập ma trận truy vết (traceability matrix).
Mẹo tận dụng nền Marketing: Phần success metrics trong BRD chính là sân nhà của bạn. Kỹ năng đặt KPI, đo conversion, tính ROI từ Marketing chuyển thẳng sang việc viết mục tiêu kinh doanh sắc bén — thứ mà nhiều BA nền kỹ thuật lại viết khá yếu.
Bài tập thực hành
Lấy một tính năng quen thuộc: "thêm tính năng đánh giá sao và bình luận sản phẩm cho một sàn TMĐT". Hãy viết:
- Một đoạn BRD (khoảng 150 từ): nêu mục tiêu kinh doanh, phạm vi, và ít nhất 2 success metrics đo lường được.
- Năm yêu cầu chức năng (FR) có đánh số: mô tả chính xác hệ thống phải làm gì, bao gồm ít nhất một exception flow (ví dụ: khách chưa mua hàng thì có được đánh giá không?).
- Ba yêu cầu phi chức năng (NFR): liên quan đến hiệu năng, bảo mật và khả năng sử dụng, mỗi cái phải có con số đo được.
- Vẽ một ma trận truy vết đơn giản: nối mỗi FR về mục tiêu kinh doanh tương ứng trong BRD. Nếu có FR nào không nối được, hãy giải thích vì sao nên giữ hoặc bỏ.
Tóm tắt
- BRD trả lời "tại sao và cái gì ở tầm kinh doanh", dành cho sponsor và ban giám đốc, ngôn ngữ kinh doanh, tập trung mục tiêu và success metrics.
- FRD trả lời "hệ thống phải làm gì", dành cho team dev và tester, chi tiết từng chức năng có đánh số và truy vết được.
- SRS là tài liệu kỹ thuật toàn diện nhất, gộp cả chức năng lẫn yêu cầu phi chức năng và ràng buộc công nghệ, thường theo chuẩn IEEE 830, dành cho đội kỹ thuật.
- Ba tài liệu là ba tầng chi tiết dần, không thay thế nhau: BRD đẻ ra FRD, FRD nằm trong SRS.
- Trong môi trường Agile Việt Nam, chúng có thể được thay bằng User Story + Acceptance Criteria, nhưng bản chất thông tin vẫn phải tồn tại.
- Nền Marketing cho bạn lợi thế lớn ở phần mục tiêu kinh doanh và chỉ số — hãy khai thác nó, đồng thời rèn thêm kỹ năng viết yêu cầu chức năng và phi chức năng rõ ràng, đo lường được.