Mở đầu — vì sao bài này quan trọng
Khi còn làm QA/Tester, bạn đọc tài liệu nhiều hơn viết. Bạn nhận được một SRS dày cộp, một bản FRD do BA chuyển xuống, rồi dựa vào đó để viết test case. Bạn quen với việc tiêu thụ tài liệu, chứ chưa quen sản xuất tài liệu. Và một sai lầm cực kỳ phổ biến của QA mới chuyển sang BA là: gom hết mọi thứ vào một file Word khổng lồ, đặt tên là "Tài liệu yêu cầu", rồi gửi cho cả sponsor lẫn dev lẫn tester đọc chung.
Kết quả? Sếp (sponsor) mở ra thấy 60 trang đặc kín thuật ngữ kỹ thuật, đóng lại ngay. Dev thì cằn nhằn vì phải lội qua mấy chục trang nói về ROI mà họ không quan tâm. Tester thì không tìm thấy chi tiết đủ rõ để viết test. Một tài liệu phục vụ tất cả mọi người thực ra không phục vụ ai cả.
Bài này dạy bạn một thứ tưởng đơn giản nhưng là nền tảng nghề BA: phân cấp tài liệu yêu cầu — BRD, FRD, SRS. Mỗi loại có đối tượng đọc riêng, mức độ chi tiết riêng, và mục đích riêng. Hiểu được cây phân cấp này, bạn sẽ biết viết cái gì cho ai, ở mức nào, và quan trọng nhất — biết một yêu cầu kinh doanh "chảy" xuống thành yêu cầu chức năng rồi thành đặc tả kỹ thuật như thế nào. Đây chính là tư duy truy vết yêu cầu (traceability) mà QA vốn đã có sẵn — chỉ là giờ bạn dùng nó để xây, chứ không phải để kiểm.
Khái niệm cốt lõi
Hãy hình dung ba tài liệu này như ba tầng của một kim tự tháp. Càng lên cao càng trừu tượng và ít chi tiết; càng xuống thấp càng cụ thể và nhiều chi tiết. Mỗi tầng trả lời một câu hỏi khác nhau.
BRD — Business Requirements Document (Tài liệu yêu cầu kinh doanh)
BRD trả lời câu hỏi "TẠI SAO chúng ta làm dự án này, và làm để đạt được điều gì?"
- Đối tượng đọc: Sponsor dự án, ban giám đốc (executive), phòng tài chính, các trưởng bộ phận. Đây là những người ký duyệt ngân sách, không phải người code.
- Nội dung: Mục tiêu kinh doanh (business goal), bối cảnh và lý do (business case), phạm vi dự án ở mức cao (scope — cái gì trong, cái gì ngoài), các chỉ số thành công (KPI), ước tính lợi ích đầu tư (ROI), các bên liên quan chính, ràng buộc và giả định ở mức kinh doanh.
- Ngôn ngữ: Hoàn toàn ngôn ngữ kinh doanh. Tuyệt đối không có "API", "database table", "endpoint". Thay vào đó là "tăng tỷ lệ chuyển đổi", "giảm chi phí vận hành", "rút ngắn thời gian xử lý đơn".
- Độ dài: Thường 10–30 trang. Ngắn gọn, đi thẳng vào giá trị.
- Người viết: BA cấp cao hoặc BA phối hợp cùng Product Owner/sponsor.
FRD — Functional Requirements Document (Tài liệu yêu cầu chức năng)
FRD trả lời câu hỏi "Hệ thống PHẢI LÀM được những gì để đạt mục tiêu kinh doanh đó?"
- Đối tượng đọc: BA, Product Owner, đội phát triển (dev lead), QA/Tester, đôi khi cả designer.
- Nội dung: Mô tả chi tiết các chức năng hệ thống — từng tính năng làm gì, luồng nghiệp vụ (process flow), quy tắc nghiệp vụ (business rules), các vai trò người dùng và quyền hạn, đầu vào/đầu ra của mỗi chức năng, điều kiện chấp nhận (acceptance criteria). FRD là cầu nối giữa "tại sao" của BRD và "làm thế nào" của SRS.
- Ngôn ngữ: Ngôn ngữ chức năng — mô tả hành vi hệ thống nhìn từ góc độ người dùng và nghiệp vụ, chưa đi vào kỹ thuật triển khai.
- Độ dài: Thường 30–100 trang tùy quy mô, hoặc được chia nhỏ theo module.
- Người viết: Đây là tài liệu "trái tim" của BA. Bạn sẽ dành phần lớn thời gian ở đây.
SRS — Software Requirements Specification (Đặc tả yêu cầu phần mềm)
SRS trả lời câu hỏi "Hệ thống sẽ được XÂY DỰNG ra sao về mặt kỹ thuật?"
- Đối tượng đọc: Đội phát triển, kiến trúc sư hệ thống, QA viết test kỹ thuật, đội DevOps.
- Nội dung: Yêu cầu chức năng và phi chức năng (non-functional) ở mức kỹ thuật — đặc tả giao diện, cấu trúc dữ liệu, ràng buộc kỹ thuật, hiệu năng (thời gian phản hồi, số người dùng đồng thời), bảo mật, khả năng tương thích, tích hợp API, sơ đồ dữ liệu. Đây là tài liệu theo chuẩn (ví dụ IEEE 830).
- Ngôn ngữ: Kỹ thuật, chính xác, không nhập nhằng. Mỗi yêu cầu phải đo lường và kiểm thử được.
- Độ dài: Rất biến thiên, có thể vài chục đến vài trăm trang.
- Người viết: BA kỹ thuật (technical BA), system analyst, hoặc phối hợp với kiến trúc sư.
POST /api/v1/cart/apply-voucher nhận voucher_code (string, tối đa 20 ký tự). Phản hồi trong vòng 300ms ở mức tải 500 request đồng thời. Mã không hợp lệ trả về HTTP 422 với body {error_code: 'INVALID_VOUCHER'}."Mối quan hệ truy vết (traceability) — phần QA sẽ thấy quen
Điểm mấu chốt: ba tài liệu này không độc lập, chúng truy vết xuống nhau. Một dòng KPI trong BRD ("giảm bỏ giỏ xuống dưới 10%") phải dẫn tới một hoặc nhiều yêu cầu chức năng trong FRD ("đơn giản hóa luồng thanh toán còn 2 bước"), và mỗi yêu cầu chức năng đó lại dẫn tới các đặc tả kỹ thuật trong SRS.
Là QA, bạn đã quen với requirement traceability matrix — ma trận ánh xạ yêu cầu sang test case để đảm bảo không bỏ sót. Giờ đây bạn dùng đúng tư duy đó, nhưng ánh xạ ngược lên: từ BRD xuống FRD xuống SRS. Đây là một lợi thế cực lớn của người từ QA — bạn vốn đã quen với việc "mọi thứ phải nối được với nhau".
Một lưu ý thực tế: không phải dự án nào cũng cần đủ cả ba. Dự án Agile nhỏ thường gộp BRD + FRD thành một product brief + backlog, và SRS gần như tan vào trong các user story và acceptance criteria. Dự án lớn theo mô hình waterfall (ngân hàng, chính phủ, outsource cho khách Nhật/Mỹ) thì tách rạch ròi cả ba. Hiểu bản chất ba tầng quan trọng hơn là cứng nhắc tạo đủ ba file.
Tình huống thực tế
Ví dụ 1 — Một file Word cho tất cả: thảm họa ở startup fintech TP.HCM
Mai, một QA có 4 năm kinh nghiệm, vừa chuyển sang vai trò BA tại một startup ví điện tử ở Quận 1. Dự án đầu tiên: tính năng "chia hóa đơn" (split bill). Quen tay viết test case chi tiết, Mai gom tất cả vào một tài liệu 45 trang: mở đầu là phân tích thị trường và doanh thu kỳ vọng, giữa là mô tả chức năng, cuối là cả cấu trúc bảng database mà cô tự nghĩ ra.
Khi gửi cho CEO duyệt ngân sách, ông phản hồi sau 2 ngày: "Anh không hiểu tài liệu này nói dự án mang lại bao nhiêu tiền. Toàn thấy bảng biểu kỹ thuật." Trong khi đó, dev lead lại than: "Phần đầu dài quá, em đọc mãi mới tới chỗ cần."
Bài học: Mai đã trộn ba tầng vào một. Sau đó cô tách ra: một BRD 8 trang cho CEO (chỉ nói về lượng giao dịch tăng, tỷ lệ giữ chân người dùng), một FRD mô tả luồng chia bill và quy tắc nghiệp vụ cho team, và để phần kỹ thuật cho dev tự đặc tả với sự hỗ trợ của cô. Lần này CEO duyệt trong nửa ngày. Đúng tài liệu, đúng người, đúng mức chi tiết.
Ví dụ 2 — Dự án outsource cho khách Nhật: thiếu tầng giữa
Công ty FPT-style outsource (gọi là công ty X) nhận dự án xây hệ thống quản lý kho cho một khách hàng Nhật. Khách gửi sang một "要件定義書" (tài liệu định nghĩa yêu cầu) tương đương BRD + một phần FRD, rất sạch về mục tiêu kinh doanh. Đội BA Việt Nam, gồm nhiều bạn từ QA chuyển sang, nhảy thẳng vào viết đặc tả kỹ thuật (SRS) để dev code cho nhanh.
Vấn đề nảy sinh: khi nghiệm thu, khách hỏi "Quy tắc tính tồn kho an toàn (safety stock) các bạn xử lý thế nào khi hàng cận date?" — và không ai trả lời rõ được, vì quy tắc nghiệp vụ này chưa từng được viết ra ở tầng FRD. Nó nằm rải rác trong đầu vài bạn dev, mỗi người hiểu một kiểu. Hậu quả: 3 tuần làm lại, trễ milestone.
Bài học: Bỏ qua tầng FRD là cái bẫy kinh điển của người vội code. BRD nói "quản lý tồn kho hiệu quả" — quá trừu tượng để code. SRS nói cấu trúc bảng — quá chi tiết để khách kinh doanh xác nhận quy tắc. Chính tầng FRD ở giữa là nơi quy tắc nghiệp vụ được chốt và được khách duyệt. Thiếu nó, mọi tranh cãi nghiệm thu đều vô căn cứ vì không có "nguồn sự thật".
Ví dụ 3 — Đội Agile ở Shopee-style: ba tầng "ẩn" trong backlog
Một sàn thương mại điện tử khu vực Đông Nam Á chạy Agile thuần. Họ không có file BRD, FRD, SRS riêng — nhưng ba tầng vẫn tồn tại dưới dạng khác. BRD chính là Epic description và OKR của quý ("tăng GMV danh mục thời trang 15%"). FRD chính là các user story kèm acceptance criteria trong Jira. SRS chính là technical design doc (TDD) mà dev viết trên Confluence trước khi code.
Một BA mới từ QA chuyển sang, ban đầu hoang mang vì "không có tài liệu chuẩn nào cả". Nhưng khi anh nhận ra mỗi tầng chỉ đổi hình thức chứ không mất đi, anh biết ngay khi viết user story thì cần liên kết nó với Epic nào (truy vết lên BRD), và cần để dev viết TDD nào (truy vết xuống SRS).
Bài học: Đừng bị ám ảnh bởi tên file. Tư duy phân tầng — tại sao / làm gì / làm thế nào — là bất biến dù bạn ở waterfall hay Agile. Người hiểu bản chất sẽ thích nghi được mọi quy trình.
Hướng dẫn từng bước
Khi bắt đầu một yêu cầu mới, hãy đi theo trình tự từ trên xuống:
- Xác định "tại sao" trước (tầng BRD). Hỏi sponsor: dự án này giải quyết vấn đề kinh doanh gì? Đo thành công bằng chỉ số nào? Đừng viết một dòng chức năng nào trước khi trả lời được câu này. Nếu không có sponsor rõ ràng, ít nhất hãy viết một đoạn "business context" ngắn.
- Chốt phạm vi ở mức cao. Liệt kê rõ cái gì trong phạm vi và cái gì ngoài. Một câu "ngoài phạm vi" giá trị bằng mười câu giải thích sau này khi có tranh cãi.
- Phân rã xuống chức năng (tầng FRD). Với mỗi mục tiêu kinh doanh, hỏi: "Hệ thống phải làm được gì để đạt điều này?" Viết ra các chức năng, luồng nghiệp vụ, và đặc biệt là quy tắc nghiệp vụ — đây là nơi kinh nghiệm soi edge case của QA tỏa sáng.
- Gắn acceptance criteria cho từng chức năng. Mỗi yêu cầu chức năng phải có điều kiện chấp nhận đo lường được. Người từ QA làm bước này rất tự nhiên vì nó giống hệt việc nghĩ "điều kiện pass/fail".
- Để phần kỹ thuật xuống tầng SRS. Phối hợp với dev/kiến trúc sư để đặc tả API, dữ liệu, hiệu năng. BA mới không cần tự viết hết SRS — nhưng phải đảm bảo mỗi mục SRS truy vết được lên một yêu cầu FRD.
- Lập ma trận truy vết. Một bảng đơn giản: cột BRD-ID, cột FRD-ID, cột SRS-ID, cột Test-case-ID. Đảm bảo không có yêu cầu nào "mồ côi" (không truy vết lên trên) và không mục tiêu nào "bị bỏ rơi" (không có chức năng nào thực hiện).
- Gửi đúng tầng cho đúng người để duyệt. Sponsor duyệt BRD. Team kỹ thuật + nghiệp vụ duyệt FRD. Dev/kiến trúc sư chốt SRS.
Lỗi thường gặp & mẹo
- Lỗi: Trộn ba tầng vào một file. Như ví dụ của Mai. Mẹo: trước khi viết một câu, tự hỏi "câu này dành cho ai đọc?". Nếu sponsor đọc thì để BRD, nếu dev đọc thì để SRS.
- Lỗi: Đưa chi tiết kỹ thuật vào BRD. Viết "dùng PostgreSQL" trong BRD là sai — sponsor không quan tâm, và bạn đang khóa cứng giải pháp quá sớm. Mẹo: BRD nói vấn đề và mục tiêu, không nói giải pháp công nghệ.
- Lỗi: Bỏ qua tầng FRD vì "Agile rồi, viết story là đủ". User story rất tốt nhưng dễ thiếu quy tắc nghiệp vụ và luồng tổng thể. Mẹo: dù Agile, vẫn cần một nơi chốt business rules và process flow — đó chính là vai trò FRD đang ẩn mình.
- Lỗi: Viết yêu cầu không thể kiểm thử. "Hệ thống phải nhanh" là vô nghĩa. Mẹo: tận dụng phản xạ QA — mỗi yêu cầu phải trả lời được "làm sao tôi kiểm chứng câu này?". "Phản hồi dưới 2 giây ở 1000 user đồng thời" mới đo được.
- Lỗi: Tài liệu không truy vết. Khi sponsor hỏi "chức năng X phục vụ mục tiêu nào?", bạn ú ớ. Mẹo: luôn duy trì ID và ma trận truy vết ngay từ đầu, đừng để cuối dự án mới ghép.
- Mẹo vàng cho người từ QA: Bạn đã quen đọc tài liệu để tìm lỗ hổng. Hãy dùng chính kỹ năng đó để review tài liệu của chính mình trước khi gửi — đọc như một tester đang cố tìm chỗ nhập nhằng, mâu thuẫn, thiếu sót.
Bài tập thực hành
Chọn một tính năng quen thuộc — ví dụ "đặt lại mật khẩu qua email" của một ứng dụng bất kỳ. Hãy viết ba đoạn ngắn, mỗi đoạn 3–5 câu, tương ứng ba tầng:
- Đoạn BRD: Viết lý do kinh doanh và một KPI cho tính năng này (gợi ý: giảm số ticket gọi tổng đài hỗ trợ quên mật khẩu, giảm chi phí chăm sóc khách hàng). Tuyệt đối không dùng từ kỹ thuật nào.
- Đoạn FRD: Mô tả luồng chức năng và ít nhất 2 quy tắc nghiệp vụ (ví dụ: link reset hết hạn sau 15 phút; tối đa 3 lần gửi yêu cầu trong 1 giờ). Kèm 2 acceptance criteria.
- Đoạn SRS: Đặc tả kỹ thuật cho 1 phần — ví dụ endpoint API, định dạng token, yêu cầu bảo mật (token chỉ dùng một lần, mã hóa thế nào).
Tóm tắt
- Ba tầng tài liệu trả lời ba câu hỏi: BRD = TẠI SAO (mục tiêu kinh doanh, KPI, ROI, cho sponsor, 10–30 trang), FRD = LÀM GÌ (chức năng, luồng, quy tắc nghiệp vụ, acceptance criteria, cho team), SRS = LÀM THẾ NÀO (đặc tả kỹ thuật, API, dữ liệu, phi chức năng, cho dev).
- Càng lên cao càng trừu tượng và ngắn; càng xuống thấp càng chi tiết và kỹ thuật.
- Sai lầm chết người: trộn ba tầng vào một file, hoặc bỏ qua tầng FRD ở giữa khiến quy tắc nghiệp vụ không có "nguồn sự thật".
- Trong Agile, ba tầng không biến mất mà đổi hình thức: Epic/OKR → user story + AC → technical design doc.
- Lợi thế của người từ QA: tư duy truy vết (traceability) và phản xạ "yêu cầu phải kiểm thử được" giúp bạn viết và soát tài liệu chặt chẽ ngay từ đầu. Hãy biến điểm mạnh kiểm thử thành điểm mạnh phân tích.