Mở đầu — vì sao bài này quan trọng
Có một câu hỏi mà gần như 100% BA fresher đều bị "vấp" trong buổi phỏng vấn hoặc trong tuần làm việc đầu tiên: "Em phân biệt giúp anh BRD, SRS và FRS khác nhau chỗ nào?". Nghe qua tưởng dễ, nhưng nếu bạn trả lời kiểu "đều là tài liệu ghi lại yêu cầu" thì người phỏng vấn sẽ biết ngay bạn chưa từng đọc một bộ tài liệu thật nào.
Ba loại tài liệu này giống như ba tầng của một tòa nhà: cùng phục vụ một dự án, nhưng ở độ cao khác nhau, phục vụ người khác nhau, và trả lời câu hỏi khác nhau. Nếu bạn nhầm tầng, bạn sẽ viết một tài liệu mà sếp business đọc không hiểu (vì quá kỹ thuật), hoặc dev đọc xong vẫn không biết code gì (vì quá chung chung). Cả hai trường hợp đều khiến bạn mất uy tín rất nhanh.
Điều thú vị là trong thực tế ở Việt Nam, ranh giới giữa ba loại tài liệu này thường bị "trộn" vào nhau, mỗi công ty gọi một kiểu. Có nơi chỉ dùng đúng một tài liệu SRS cho tất cả, có nơi tách rời rạch ròi. Nếu bạn hiểu bản chất từng loại, bạn sẽ đọc được mọi biến thể và biết mình đang thiếu thông tin gì. Đó chính là mục tiêu của bài này: không phải học thuộc định nghĩa, mà hiểu được "tầng thông tin" để dùng đúng công cụ cho đúng việc.
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 xương sống: mọi yêu cầu đều đi từ trừu tượng → cụ thể, từ tại sao → cái gì → như thế nào. Ba tài liệu này chính là ba chặng trên hành trình đó.
BRD — Business Requirements Document
BRD trả lời câu hỏi "Doanh nghiệp cần làm gì và tại sao?". Đây là tài liệu ở tầng cao nhất, viết bằng ngôn ngữ business, dành cho các sponsor, quản lý cấp cao, và những người ra quyết định rót ngân sách.
BRD tập trung vào:
- Mục tiêu kinh doanh (business objectives): ví dụ "tăng tỷ lệ khách hàng hoàn tất thanh toán online lên 15%".
- Phạm vi dự án (scope): cái gì nằm trong, cái gì nằm ngoài.
- Các bên liên quan (stakeholders) và nhu cầu của họ.
- Yêu cầu ở mức cao (high-level requirements): "hệ thống phải cho phép thanh toán bằng ví điện tử", chứ không đi sâu vào ví nào, luồng ra sao.
- Lý do đầu tư (business case), lợi ích kỳ vọng, rủi ro.
FRS — Functional Requirements Specification
FRS trả lời câu hỏi "Hệ thống phải làm được những chức năng gì để đáp ứng nhu cầu business đó?". Nếu BRD nói "cho phép thanh toán bằng ví điện tử", thì FRS sẽ nói rõ: hệ thống hiển thị danh sách ví (MoMo, ZaloPay, VNPay), người dùng chọn ví, hệ thống gọi cổng thanh toán, xử lý phản hồi thành công/thất bại, cập nhật trạng thái đơn hàng.
FRS tập trung vào:
- Các chức năng cụ thể (functional requirements): input, xử lý, output.
- Luồng nghiệp vụ (process flow), các bước người dùng và hệ thống tương tác.
- Quy tắc nghiệp vụ (business rules) ở mức chức năng: "nếu số dư ví không đủ, hiển thị thông báo lỗi và giữ nguyên đơn hàng".
- Các trường hợp ngoại lệ (exception handling).
SRS — Software Requirements Specification
SRS là tài liệu toàn diện và kỹ thuật nhất, mô tả đầy đủ hệ thống phần mềm cần xây dựng. Nó bao trùm cả chức năng (functional) lẫn phi chức năng (non-functional như hiệu năng, bảo mật, khả năng mở rộng), cùng các ràng buộc kỹ thuật, giao diện tích hợp, mô hình dữ liệu ở mức cao.
Điểm dễ nhầm nhất là: SRS thường bao gồm cả nội dung của FRS bên trong nó. Nói cách khác, phần "functional requirements" trong một bộ SRS chính là FRS. Đây là lý do nhiều công ty không tách riêng FRS mà gộp luôn vào SRS.
Một cách dễ nhớ về mối quan hệ ba tài liệu:
- BRD = tầng doanh nghiệp — tại sao làm và làm cái gì ở mức nhu cầu.
- FRS = tầng chức năng — hệ thống làm gì để đáp ứng nhu cầu đó.
- SRS = tầng phần mềm — toàn bộ mô tả hệ thống (functional + non-functional + ràng buộc), thường "chứa" FRS bên trong.
Bảng so sánh nhanh
| Tiêu chí | BRD | FRS | SRS |
|---|---|---|---|
| Câu hỏi trả lời | Tại sao & cần gì (business) | Hệ thống làm chức năng gì | Toàn bộ phần mềm cần gì |
| Người viết | BA / Business Analyst | BA | BA / System Analyst |
| Người đọc chính | Sponsor, quản lý | Dev, tester, PO | Dev, tester, architect |
| Ngôn ngữ | Business, ít kỹ thuật | Bán kỹ thuật | Kỹ thuật, chi tiết |
| Chứa non-functional? | Rất ít | Ít | Có, đầy đủ |
| Mức độ chi tiết | Cao (khái quát) | Trung bình | Thấp nhất (chi tiết nhất) |
Tình huống thực tế
Ví dụ 1 — Dự án ví điện tử của một ngân hàng số tại TP.HCM
Một ngân hàng số (giả định tên Timo-style) muốn thêm tính năng "chia hóa đơn" (split bill) cho ứng dụng của họ. Bối cảnh: nhóm marketing báo cáo rằng nhóm khách hàng Gen Z rời app vì thiếu tính năng xã hội, và mục tiêu là tăng số giao dịch chuyển tiền nội bộ thêm 20% trong quý.
- Trong BRD, chị BA lead viết: "Mục tiêu tăng 20% giao dịch chuyển tiền P2P trong Q3. Cần tính năng cho phép nhóm bạn chia sẻ và thanh toán một hóa đơn chung. Đối tượng: khách hàng 18–28 tuổi. Ngoài phạm vi: chia hóa đơn với người ngoài hệ thống ngân hàng." Sếp đọc xong duyệt ngân sách mà không cần biết màn hình trông ra sao.
- Trong FRS, bạn BA fresher trong team viết chi tiết: người tạo hóa đơn nhập tổng tiền, chọn số người, hệ thống chia đều hoặc chia tùy chỉnh, gửi yêu cầu đến từng thành viên, mỗi thành viên nhận thông báo push, xác nhận thanh toán bằng mã PIN, hệ thống cập nhật trạng thái "đã thanh toán/chờ" theo thời gian thực. Kèm quy tắc: "nếu một thành viên từ chối, người tạo được thông báo và có thể chia lại phần còn thiếu."
- Trong SRS, ngoài toàn bộ chức năng trên, còn bổ sung: thời gian phản hồi thông báo dưới 2 giây, mã hóa giao dịch theo chuẩn PCI-DSS, hệ thống chịu tải 5.000 yêu cầu chia bill đồng thời, tích hợp với core banking qua API nội bộ.
Ví dụ 2 — Startup thương mại điện tử "gộp tất cả vào một SRS"
Một startup e-commerce nhỏ ở Hà Nội (khoảng 15 người) làm nền tảng bán mỹ phẩm. Họ không có quy trình tài liệu chuẩn. Khi bạn vào làm BA fresher, sếp bảo: "Bên anh chỉ viết một tài liệu SRS thôi, viết hết vào đó."
Ở đây, "SRS" của startup thực chất là một tài liệu lai: có một mục ngắn mô tả mục tiêu kinh doanh (vốn là nội dung BRD), phần lớn là mô tả chức năng (vốn là FRS), và một mục nhỏ về yêu cầu phi chức năng. Điều này hoàn toàn bình thường và hợp lý với quy mô nhỏ — tách ba tài liệu riêng cho một startup 15 người là lãng phí.
Bài học rút ra: đừng cứng nhắc. Số lượng và tên gọi tài liệu phụ thuộc vào quy mô, mức độ phức tạp và văn hóa công ty. Kỹ năng của BA giỏi không phải là "phải có đủ ba tài liệu" mà là "đảm bảo đủ ba tầng thông tin — tại sao, làm gì, như thế nào — dù nằm trong một hay ba file."
Ví dụ 3 — Dự án outsourcing cho khách hàng Nhật
Một công ty outsourcing tại Đà Nẵng nhận dự án bảo hiểm cho khách hàng Nhật. Khách hàng gửi sang một BRD bằng tiếng Anh mô tả nhu cầu: hệ thống quản lý hợp đồng bảo hiểm nhân thọ. Nhiệm vụ của team BA Việt Nam là dựa vào BRD đó để viết SRS chi tiết gửi ngược lại cho khách duyệt trước khi dev bắt đầu.
Vấn đề nảy sinh: BRD của khách viết "hệ thống phải hỗ trợ tính phí bảo hiểm linh hoạt". Câu này ở tầng business là đủ, nhưng khi viết SRS, BA phải làm rõ: linh hoạt theo tuổi? theo gói? theo tần suất đóng? Team đã tổ chức buổi làm rõ yêu cầu (clarification), đưa từng công thức tính phí vào SRS, và nhờ đó tránh được việc dev hiểu sai — thứ có thể gây thiệt hại hàng chục triệu đồng chi phí làm lại.
Bài học rút ra: BRD và SRS bổ sung cho nhau. BRD nêu nhu cầu ở mức khái quát (đúng vai trò của nó), còn SRS mới là nơi mọi mơ hồ phải được "đóng đinh". Khi nhận BRD từ khách, đừng giả định — mỗi từ mơ hồ như "linh hoạt", "nhanh", "thân thiện" đều là một câu hỏi bạn phải làm rõ trước khi đưa vào SRS.
Hướng dẫn từng bước
Khi bạn được giao nhiệm vụ liên quan đến ba loại tài liệu này, hãy làm theo trình tự sau:
- Xác định bạn đang ở tầng nào. Hỏi bản thân: mình đang cần chốt tại sao làm (BRD), làm chức năng gì (FRS), hay toàn bộ hệ thống ra sao (SRS)? Xác định sai tầng dẫn đến viết sai độ chi tiết.
- Đọc ngược từ trên xuống. Nếu đã có BRD, đọc kỹ để nắm mục tiêu và phạm vi. Mọi thứ bạn viết trong FRS/SRS phải truy vết ngược được về một mục tiêu trong BRD (đây gọi là traceability — khả năng truy vết).
- Với BRD, viết theo cấu trúc: bối cảnh & vấn đề → mục tiêu kinh doanh đo lường được → phạm vi (in/out) → stakeholders → yêu cầu mức cao → business case & rủi ro. Giữ ngôn ngữ đơn giản, tránh thuật ngữ kỹ thuật.
- Với FRS, viết theo cấu trúc: danh sách chức năng → với mỗi chức năng mô tả input, xử lý, output → luồng nghiệp vụ (dùng sơ đồ nếu cần) → business rules → exception handling. Mỗi chức năng nên có mã định danh (VD: FR-01) để dễ tham chiếu.
- Với SRS, viết theo cấu trúc: giới thiệu & phạm vi → yêu cầu chức năng (chính là phần FRS) → yêu cầu phi chức năng (hiệu năng, bảo mật, khả dụng...) → ràng buộc kỹ thuật → giao diện bên ngoài & tích hợp → mô hình dữ liệu mức cao.
- Đối chiếu ngược lên. Sau khi viết xong, kiểm tra: mọi mục tiêu trong BRD đã được chức năng nào đó trong FRS/SRS phục vụ chưa? Có chức năng nào bị "mồ côi" — không phục vụ mục tiêu nào không? Nếu có, đó là dấu hiệu scope đang phình ra.
- Lấy chữ ký duyệt (sign-off) đúng người. BRD được sponsor/business duyệt; SRS/FRS được PO và tech lead duyệt. Đúng người duyệt đúng tầng.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhồi chi tiết kỹ thuật vào BRD. Fresher hay hào hứng viết cả tên bảng database vào BRD. Sếp business đọc không hiểu và mất niềm tin. Mẹo: nếu một câu trong BRD chỉ dev mới hiểu, hãy chuyển nó xuống FRS/SRS.
Lỗi 2 — Viết FRS quá chung chung. Câu như "hệ thống phải xử lý thanh toán" không phải là yêu cầu chức năng, mà là mong muốn. Yêu cầu chức năng phải cụ thể tới mức tester viết được test case từ nó. Mẹo: đọc lại mỗi dòng và tự hỏi "tester có kiểm thử được câu này không?".
Lỗi 3 — Bỏ quên yêu cầu phi chức năng trong SRS. Đây là lỗi kinh điển (sẽ được đào sâu ở bài về non-functional requirement). SRS mà chỉ có chức năng thì hệ thống chạy được nhưng có thể chậm, không bảo mật, không mở rộng nổi.
Lỗi 4 — Lẫn lộn tên gọi giữa các công ty. Có nơi gọi FRS là "SDD", có nơi gọi BRD là "Business Case". Mẹo: đừng bám vào tên, hãy hỏi "tài liệu này trả lời câu hỏi nào — tại sao, làm gì, hay như thế nào?" để định vị bản chất.
Lỗi 5 — Không giữ traceability. Khi dự án thay đổi, không biết sửa BRD thì phần nào trong SRS bị ảnh hưởng. Mẹo: lập một bảng traceability matrix đơn giản, ánh xạ mỗi mục tiêu BRD tới các FR tương ứng.
Mẹo vàng cho fresher: trong buổi đầu tiên nhận dự án, hãy xin đọc tài liệu của một dự án cũ đã hoàn thành. Đọc cách công ty thực sự viết BRD/SRS/FRS quan trọng hơn mọi lý thuyết, vì bạn sẽ biết template, mức chi tiết và văn hóa tài liệu nơi mình làm.
Bài tập thực hành
Hãy chọn một tính năng đơn giản mà bạn dùng hằng ngày — ví dụ chức năng "đặt lại mật khẩu" (forgot password) của một app.
- Viết một đoạn BRD ngắn (3–5 câu): tại sao doanh nghiệp cần chức năng này (giảm số ticket hỗ trợ, tăng tỷ lệ đăng nhập lại thành công), mục tiêu đo lường được, và phạm vi.
- Viết phần FRS cho chức năng đó: liệt kê ít nhất 5 yêu cầu chức năng có mã (FR-01 đến FR-05), mỗi cái mô tả input–xử lý–output. Đừng quên các trường hợp ngoại lệ: email không tồn tại, link hết hạn, mật khẩu mới không đủ mạnh.
- Bổ sung 3 yêu cầu phi chức năng để biến nó thành một mẩu SRS: ví dụ link đặt lại mật khẩu hết hạn sau 15 phút, mật khẩu được mã hóa bằng bcrypt, thời gian gửi email dưới 30 giây.
- Tự kiểm tra traceability: kẻ một bảng nhỏ, cột trái là mục tiêu trong BRD, cột phải là các FR phục vụ mục tiêu đó. Có FR nào không phục vụ mục tiêu nào không?
Tóm tắt
Ba tài liệu BA nền tảng khác nhau ở tầng thông tin chúng phục vụ, không phải ở việc cái nào "xịn" hơn:
- BRD trả lời tại sao và cần gì ở góc nhìn doanh nghiệp — dành cho người ra quyết định.
- FRS trả lời hệ thống làm chức năng gì — cầu nối giữa business và dev.
- SRS là mô tả toàn bộ phần mềm, bao gồm cả chức năng lẫn phi chức năng, và thường "chứa" FRS bên trong.