Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa nhận một dự án mới. Sếp bảo: "Em viết cho anh cái tài liệu yêu cầu nhé." Bạn ngồi xuống, mở Word, gõ tiêu đề... rồi khựng lại. Tài liệu này dành cho ai? Cho ban giám đốc đọc để duyệt ngân sách, hay cho đội developer đọc để code? Nó nên nói "vì sao chúng ta làm dự án này" hay "hệ thống phải làm chính xác những gì"? Nó là BRD, FRD, SRS hay PRD?
Đây là một trong những điểm khiến rất nhiều BA mới — kể cả BA đã đi làm vài năm — bối rối nhất. Bốn cái tên viết tắt nghe na ná nhau, ranh giới giữa chúng mờ nhạt, và mỗi công ty lại dùng một kiểu. Có nơi gọi mọi thứ là "BRD", có nơi chỉ làm "SRS", có nơi theo Agile thì xài "PRD" và User Stories. Nếu bạn không phân biệt được, bạn sẽ rơi vào hai cái bẫy kinh điển: viết tài liệu sai đối tượng (sếp đọc không hiểu, dev đọc thiếu thông tin), hoặc viết trùng lặp thông tin ở nhiều tài liệu khiến việc bảo trì thành cơn ác mộng.
Bài học này không phải để bạn học thuộc lòng định nghĩa. Mục tiêu thực sự là: khi đứng trước một dự án, bạn biết cần loại tài liệu nào, viết cái gì vào đó, và ai sẽ đọc. Đó là khác biệt giữa một BA "biết viết tài liệu" và một BA "biết chọn đúng công cụ giao tiếp cho đúng đối tượng".
Khái niệm cốt lõi
Trước khi đi vào từng loại, hãy nắm một nguyên tắc xuyên suốt: các tài liệu yêu cầu khác nhau ở mức độ trừu tượng (level of abstraction). Chúng đi từ "tại sao" và "cái gì ở mức kinh doanh" xuống dần đến "hệ thống phải hành xử chính xác ra sao". Hãy hình dung một cái phễu: trên cùng rộng nhất là mục tiêu kinh doanh, càng xuống dưới càng chi tiết và kỹ thuật.
BRD — Business Requirements Document
BRD trả lời câu hỏi "Tại sao chúng ta làm dự án này, và nó cần đạt được điều gì về mặt kinh doanh?". Đây là tài liệu ở tầng cao nhất.
- Đối tượng đọc: Sponsor (nhà tài trợ dự án), ban lãnh đạo, các trưởng phòng nghiệp vụ — những người duyệt ngân sách và quyết định có làm hay không.
- Tập trung vào: Mục tiêu kinh doanh (business goals), phạm vi (scope), các bên liên quan, lợi ích kỳ vọng, ràng buộc, giả định, và đôi khi là phân tích chi phí — lợi ích.
- Đặc điểm: Viết bằng ngôn ngữ kinh doanh, ít hoặc không có thuật ngữ kỹ thuật. Nói "cái gì" và "tại sao", tuyệt đối không nói "làm thế nào".
FRD — Functional Requirements Document
FRD trả lời câu hỏi "Hệ thống phải làm những chức năng gì để đạt được mục tiêu kinh doanh đó?". Nó là cầu nối giữa nhu cầu kinh doanh (BRD) và thiết kế kỹ thuật.
- Đối tượng đọc: Đội phát triển, kiểm thử (QA), trưởng nhóm kỹ thuật, đôi khi cả phía nghiệp vụ để xác nhận.
- Tập trung vào: Các chức năng cụ thể (functional requirements) — hệ thống làm gì khi người dùng thực hiện hành động nào, các quy tắc nghiệp vụ (business rules), luồng xử lý, dữ liệu đầu vào/đầu ra.
- Đặc điểm: Chi tiết hơn BRD nhiều, tập trung vào hành vi của hệ thống, nhưng vẫn chưa đi sâu vào kiến trúc kỹ thuật hay công nghệ.
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 (functional) lẫn yêu cầu phi chức năng (non-functional — hiệu năng, bảo mật, khả năng mở rộng...). Đây là tài liệu chuẩn theo IEEE 830, rất phổ biến trong các dự án theo mô hình Waterfall, đặc biệt ở lĩnh vực có yêu cầu pháp lý chặt như ngân hàng, y tế, hàng không.
- Đối tượng đọc: Kiến trúc sư phần mềm, developer, QA, đôi khi cả auditor (kiểm toán) trong dự án regulatory.
- Tập trung vào: Mô tả đầy đủ hệ thống — chức năng, phi chức năng, giao diện, ràng buộc thiết kế, mô hình dữ liệu. Nó là "hợp đồng kỹ thuật" giữa bên nghiệp vụ và bên xây dựng.
- Đặc điểm: Rất chi tiết, có cấu trúc chuẩn, mỗi yêu cầu được đánh mã (ID) để truy vết. Trên thực tế, nhiều công ty xem SRS như phiên bản "đầy đủ" gộp nội dung của FRD cộng thêm phần phi chức năng.
PRD — Product Requirements Document
PRD là "đứa con của thế giới sản phẩm và Agile". Nó tập trung vào sản phẩm — đặc biệt là sản phẩm số (app, web, SaaS) — chứ không chỉ một dự án có điểm bắt đầu và kết thúc rõ ràng.
- Đối tượng đọc: Đội sản phẩm (Product Owner, Product Manager), designer, developer.
- Tập trung vào: Sản phẩm giải quyết vấn đề gì cho người dùng, các tính năng (features), trải nghiệm người dùng, tiêu chí thành công (success metrics). Thường đi kèm user stories, wireframe, và được cập nhật liên tục.
- Đặc điểm: Linh hoạt, sống động, gắn với product roadmap. Trong nhiều team Agile, PRD thay thế cho cả BRD lẫn FRD ở mức nhẹ nhàng hơn.
Bảng so sánh nhanh
| Tài liệu | Đối tượng chính | Trả lời câu hỏi | Mức độ | Khi nào dùng |
|---|---|---|---|---|
| BRD | Sponsor, lãnh đạo, nghiệp vụ | Tại sao? Cần đạt gì? (What ở mức kinh doanh) | Cao (chiến lược) | Đầu dự án, để duyệt và định hướng |
| FRD | Dev, QA, tech lead | Hệ thống làm chức năng gì? | Trung bình | Sau BRD, để đặc tả hành vi hệ thống |
| SRS | Architect, dev, QA, auditor | Hệ thống làm gì + đáp ứng phi chức năng ra sao? (How chi tiết) | Thấp (kỹ thuật) | Dự án Waterfall, regulatory, cần đặc tả đầy đủ |
| PRD | Product team, designer, dev | Sản phẩm giải quyết vấn đề gì cho user? | Linh hoạt | Dự án sản phẩm số, môi trường Agile |
Tình huống thực tế
Ví dụ 1 — Ngân hàng số: chuỗi BRD → FRD → SRS
Một ngân hàng thương mại tại TP.HCM, tạm gọi là VietBank, muốn triển khai tính năng mở tài khoản online bằng eKYC. Đây là dự án có yếu tố pháp lý nặng (tuân thủ quy định của Ngân hàng Nhà nước về định danh khách hàng), nên họ làm đầy đủ cả ba lớp tài liệu.
Diễn giải: Giám đốc Khối Bán lẻ là sponsor. BA viết BRD trước, nêu rõ: mục tiêu giảm thời gian mở tài khoản từ 2 ngày xuống 30 phút, kỳ vọng thu hút thêm 50.000 khách hàng mới trong năm đầu, ngân sách 8 tỷ đồng, ràng buộc phải tuân thủ Thông tư của NHNN. Ban giám đốc đọc BRD này, duyệt ngân sách trong cuộc họp đầu tư.
Sau khi duyệt, BA viết FRD cho đội kỹ thuật: mô tả luồng người dùng chụp CCCD, hệ thống gọi API xác thực với Cơ sở dữ liệu quốc gia về dân cư, quy tắc khi xác thực thất bại, luồng so khớp khuôn mặt (liveness check). Cuối cùng, vì là dự án ngân hàng cần audit, đội kiến trúc bổ sung thành SRS đầy đủ, thêm các yêu cầu phi chức năng: hệ thống chịu tải 1.000 hồ sơ đồng thời, mã hóa dữ liệu CCCD theo chuẩn AES-256, thời gian phản hồi dưới 10 giây, lưu log đầy đủ để phục vụ kiểm toán.
Bài học: Trong dự án nghiêm túc và có yếu tố pháp lý, ba tài liệu không loại trừ nhau mà nối tiếp nhau theo "cái phễu". Mỗi tài liệu phục vụ một nhóm độc giả khác nhau, và việc tách lớp giúp mỗi nhóm chỉ đọc đúng phần họ cần.
Ví dụ 2 — Startup E-commerce: chỉ cần PRD
Một startup thương mại điện tử ở Hà Nội, tạm gọi ShopFast, đang xây tính năng "giỏ hàng chia sẻ" cho phép nhiều người cùng thêm sản phẩm vào một giỏ rồi thanh toán chung. Team gồm 1 Product Owner, 2 developer, 1 designer, chạy Scrum 2 tuần một sprint.
Diễn giải: Ở đây, nếu BA khăng khăng đòi viết đủ BRD + FRD + SRS thì dự án sẽ chết vì giấy tờ trước khi ra mắt. Thay vào đó, BA (đóng vai trò gần với Product Owner) viết một PRD gọn: nêu vấn đề người dùng (nhóm bạn mua chung hay phải gom đơn thủ công), mô tả tính năng, kèm wireframe của Figma, và một danh sách user stories như "Là một người dùng, tôi muốn mời bạn vào giỏ hàng qua link để cùng thêm sản phẩm." PRD này được đặt trên Confluence, cập nhật liên tục mỗi sprint, gắn link tới các ticket trong Jira.
Bài học: Mức độ tài liệu phải tương xứng với mức độ rủi ro và quy mô dự án. Startup nhỏ, sản phẩm thay đổi nhanh → một PRD linh hoạt là đủ. Đổ giấy tờ nặng nề vào đây là phản tác dụng. Đây chính là tinh thần "vừa đủ tài liệu" (just enough documentation) trong Agile.
Ví dụ 3 — Cái bẫy "gọi mọi thứ là BRD"
Một công ty outsourcing phần mềm tại Đà Nẵng có thói quen: mọi tài liệu đều gọi là "BRD". Khi nhận một dự án logistics cho khách hàng Singapore, BA giao "BRD" cho đội dev. Đội dev mở ra đọc thì thấy toàn mục tiêu kinh doanh chung chung kiểu "tối ưu hóa chuỗi cung ứng", "nâng cao trải nghiệm tài xế" — không có một quy tắc nghiệp vụ cụ thể nào để code. Kết quả: dev hỏi đi hỏi lại, mỗi người hiểu một kiểu, một tính năng tính cước vận chuyển bị code sai logic, phải làm lại, trễ tiến độ 3 tuần.
Diễn giải: Vấn đề không nằm ở cái tên "BRD", mà ở chỗ tài liệu dừng ở tầng kinh doanh nhưng lại được dùng như tài liệu kỹ thuật. Nội dung tầng FRD/SRS (quy tắc tính cước, điều kiện biên, xử lý lỗi) bị thiếu hoàn toàn.
Bài học: Cái tên không quan trọng bằng nội dung và độc giả. Nếu công ty bạn chỉ dùng một loại tài liệu, hãy đảm bảo nó chứa đủ các lớp thông tin mà từng nhóm độc giả cần — hoặc tách thành các phần rõ ràng bên trong cùng một tài liệu. Đừng để developer phải "đoán" yêu cầu từ những câu mục tiêu chiến lược.
Hướng dẫn từng bước
Khi bắt đầu một dự án và phải quyết định viết tài liệu gì, hãy đi theo các bước sau:
- Xác định độc giả chính. Hỏi: ai sẽ ra quyết định dựa trên tài liệu này, và ai sẽ thực thi nó? Nếu là lãnh đạo duyệt ngân sách → bạn cần lớp BRD. Nếu là developer cần code → bạn cần lớp FRD/SRS. Nếu là product team lặp nhanh → PRD.
- Đánh giá mô hình và mức độ rủi ro của dự án. Dự án Waterfall, regulatory (ngân hàng, bảo hiểm, y tế) → nghiêng về BRD + FRD/SRS đầy đủ, có truy vết. Dự án Agile, sản phẩm số, rủi ro thấp → nghiêng về PRD + user stories, viết "vừa đủ".
- Hỏi rõ chuẩn của tổ chức. Mỗi công ty có quy ước riêng. Trước khi viết, hãy xem template có sẵn và hỏi đồng nghiệp: "Ở đây mình gọi tài liệu yêu cầu chức năng là gì?" Đừng áp định nghĩa sách vở một cách cứng nhắc.
- Bắt đầu từ tầng cao, đi xuống tầng thấp. Luôn làm rõ "tại sao" và "mục tiêu kinh doanh" trước (dù chỉ là một đoạn ngắn), rồi mới chi tiết hóa thành chức năng. Đừng nhảy thẳng vào chi tiết kỹ thuật khi chưa rõ mục tiêu.
- Tránh trùng lặp — dùng nguyên tắc một nguồn sự thật. Nếu viết nhiều tài liệu, hãy để mỗi thông tin chỉ xuất hiện ở một nơi và liên kết (link/reference) thay vì sao chép. Ví dụ: FRD tham chiếu tới mã mục tiêu trong BRD, chứ không chép lại nguyên đoạn mục tiêu.
- Gắn truy vết (traceability). Đánh mã ID cho từng yêu cầu để có thể truy vết từ mục tiêu kinh doanh (BRD) → chức năng (FRD/SRS) → test case. (Chủ đề Requirements Traceability Matrix sẽ được học sâu ở bài riêng.)
- Rà soát với đúng người. Đưa BRD cho sponsor xác nhận, đưa FRD/SRS cho tech lead và QA review. Một tài liệu chỉ có giá trị khi đúng độc giả đọc và đồng thuận.
Lỗi thường gặp & mẹo
- Lỗi: Trộn lẫn "what" và "how". BRD lẽ ra chỉ nói mục tiêu kinh doanh, nhưng BA lại nhét vào đó chi tiết giao diện, tên bảng dữ liệu. Hệ quả: sponsor đọc không hiểu, và khi giải pháp kỹ thuật thay đổi thì BRD lỗi thời. Mẹo: Tự hỏi "câu này có ràng buộc giải pháp không?" Nếu có, nó thuộc về FRD/SRS, không phải BRD.
- Lỗi: Coi tên viết tắt là chân lý. Tranh cãi "cái này là FRD hay SRS" thường vô nghĩa. Mẹo: Tập trung vào hai câu hỏi — "Ai đọc?" và "Họ cần biết gì để hành động?". Tên gọi chỉ là nhãn.
- Lỗi: Quên yêu cầu phi chức năng. Nhiều người viết FRD/SRS rất kỹ phần chức năng nhưng bỏ quên hiệu năng, bảo mật, khả năng mở rộng — những thứ thường gây sự cố lớn nhất khi vận hành. Mẹo: SRS bắt buộc phải có mục NFR riêng. (Chi tiết cách viết NFR đúng có ở bài riêng.)
- Lỗi: Tài liệu quá nặng so với dự án. Bắt một startup 4 người viết SRS 80 trang là giết chết tốc độ. Mẹo: Cân mức tài liệu theo rủi ro và quy mô, không theo "cho oai".
- Lỗi: Sao chép thông tin giữa các tài liệu. Khi mục tiêu thay đổi, bạn phải sửa ở 3 nơi và chắc chắn sẽ quên một nơi. Mẹo: Một nguồn sự thật, liên kết thay vì chép.
- Mẹo vàng: Dù dùng tài liệu gì, hãy luôn có một đoạn ngắn ở đầu nêu rõ "Tài liệu này dành cho ai và trả lời câu hỏi gì". Một câu này giúp người đọc định vị ngay và tránh hiểu nhầm.
Bài tập thực hành
- Phân loại nhanh. Cho 6 phát biểu sau, hãy gắn nhãn mỗi câu thuộc BRD, FRD, SRS (phần NFR) hay PRD:
- Chọn loại tài liệu. Với mỗi bối cảnh dưới đây, bạn sẽ chọn (các) loại tài liệu nào và vì sao?
- Viết thử. Lấy một tính năng quen thuộc (ví dụ: đặt lại mật khẩu). Viết 2 phiên bản: một câu mục tiêu theo phong cách BRD, và 3 dòng đặc tả chức năng theo phong cách FRD. So sánh sự khác biệt về ngôn ngữ và mức chi tiết.
Tóm tắt
- Bốn loại tài liệu yêu cầu khác nhau chủ yếu ở mức độ trừu tượng và đối tượng đọc, theo mô hình cái phễu từ kinh doanh xuống kỹ thuật.
- BRD nói tại sao và cần đạt gì (cho sponsor, lãnh đạo). FRD nói hệ thống làm chức năng gì (cho dev, QA). SRS là đặc tả kỹ thuật toàn diện gồm cả chức năng lẫn phi chức năng (cho architect, dev, auditor). PRD xoay quanh sản phẩm và người dùng (cho product team, môi trường Agile).
- Tên gọi không quan trọng bằng việc tài liệu đúng độc giả và chứa đủ thông tin để người đọc hành động.
- Cân mức độ tài liệu theo rủi ro và quy mô dự án: regulatory thì đầy đủ và truy vết, startup Agile thì "vừa đủ".
- Tránh trộn "what" và "how", tránh sao chép trùng lặp, và luôn có một dòng đầu nêu rõ tài liệu dành cho ai.