D-Bài 20 — Document hierarchy — BRD FRD SRS

Mở đầu — vì sao bài này quan trọng

Khi còn là developer, bạn quen với một loại tài liệu duy nhất: technical doc. Một file README, một trang Confluence mô tả API, vài comment trong code — vậy là đủ để cả team hiểu nhau. Mọi người đọc cùng một thứ tiếng: HTTP method, endpoint, payload, status code.

Nhưng khi bước sang vai trò BA, bạn sẽ sốc khi nhận ra rằng một dự án không chỉ có một loại tài liệu, mà có cả một hệ thống phân tầng tài liệu (document hierarchy) — và mỗi tầng phục vụ một nhóm người đọc hoàn toàn khác nhau. Giám đốc tài chính không quan tâm bạn dùng REST hay GraphQL. Anh ấy muốn biết dự án này tiêu tốn bao nhiêu tiền và mang lại bao nhiêu doanh thu. Ngược lại, anh dev backend không cần biết ROI là gì, anh ấy cần biết field customer_id có bắt buộc không và validate ra sao.

Đây chính là điểm vấp ngã kinh điển của dev-turned-BA. Tôi từng thấy nhiều bạn viết một tài liệu "requirements" dài 40 trang, nhồi nhét cả mục tiêu kinh doanh lẫn cấu trúc database vào cùng một chỗ. Kết quả: sếp đọc 2 trang đầu rồi bỏ vì quá kỹ thuật, còn dev đọc đến trang 15 vẫn không tìm thấy thông tin mình cần. Tài liệu đó về mặt kỹ thuật là "đúng", nhưng về mặt giao tiếp là một thất bại.

Bài học hôm nay sẽ giúp bạn hiểu rõ ba tầng tài liệu nền tảng — BRD, FRD, SRS — biết tầng nào dành cho ai, chứa gì, và quan trọng nhất là biết cách "truyền" thông tin xuyên suốt từ tầng cao xuống tầng thấp mà không để mất mát hay mâu thuẫn. Đây là kỹ năng tổ chức tư duy, không chỉ là kỹ năng viết.

Khái niệm cốt lõi

Hãy hình dung document hierarchy như một cái phễu. Đầu phễu rộng, chứa ý tưởng kinh doanh mơ hồ. Càng xuống dưới, thông tin càng cụ thể, chi tiết, và "đóng đinh" hơn. Ba tầng chính là BRD → FRD → SRS.

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ó mang lại điều gì cho doanh nghiệp?"

• Người đọc (audience): Sponsor (người bỏ tiền), ban giám đốc, các trưởng phòng ban liên quan. Đây là những người ra quyết định đầu tư, không phải người implement.
• Nội dung chính:

- Business goal — mục tiêu kinh doanh. Ví dụ: "Giảm tỷ lệ khách hàng rời bỏ (churn) từ 8% xuống 5% trong 12 tháng." - Scope — phạm vi: cái gì nằm trong dự án, cái gì nằm ngoài (in-scope / out-of-scope). - KPI / success metrics — các chỉ số đo lường thành công. - ROI và cost-benefit — lợi tức đầu tư, ước tính chi phí và lợi ích. - High-level requirements — yêu cầu ở mức cao, dạng "hệ thống phải cho phép khách hàng tự đặt lịch", chứ KHÔNG mô tả màn hình hay logic. - Stakeholders, assumptions, constraints, timeline tổng thể.

Điểm mấu chốt: BRD nói về vấn đề và giá trị kinh doanh, tuyệt đối không nói về giải pháp kỹ thuật. Một câu trong BRD đúng chuẩn nghe như lời của một giám đốc, không phải lời của một kỹ sư.

FRD — Functional Requirements Document

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 đó?"

• Người đọc: BA, Product Owner, dev lead, QA, designer. Đây là tầng cầu nối giữa kinh doanh và kỹ thuật.
• Nội dung chính:

- Functional requirements — mô tả hành vi của hệ thống: "Khi khách hàng nhấn 'Đặt lịch', hệ thống hiển thị các khung giờ trống trong 14 ngày tới." - Use cases / user flows — luồng nghiệp vụ chi tiết. - Business rules — quy tắc nghiệp vụ: "Không cho đặt lịch trong vòng dưới 2 giờ so với hiện tại." - Input/output, các trạng thái, xử lý ngoại lệ (error handling) ở mức nghiệp vụ. - Wireframe hoặc mô tả giao diện ở mức logic (không phải design hoàn chỉnh).

FRD là nơi BA "tiêu hóa" mục tiêu kinh doanh từ BRD thành các chức năng cụ thể mà ai cũng kiểm chứng được. Đây thường là tài liệu mà dev-turned-BA viết tốt nhất, vì nó gần với tư duy logic của lập trình.

SRS — Software/System Requirements Specification

SRS trả lời câu hỏi "Hệ thống được xây dựng CHÍNH XÁC như thế nào về mặt kỹ thuật?"

• Người đọc: Dev, architect, QA engineer, technical lead.
• Nội dung chính:

- Functional requirements ở mức kỹ thuật — chi tiết tới từng field, validation, data type. - Non-functional requirements (NFR) — hiệu năng, bảo mật, khả năng mở rộng: "API đặt lịch phải phản hồi dưới 300ms với 1000 request đồng thời." - Data model, API contract, integration points — sơ đồ ERD, đặc tả endpoint, format dữ liệu. - Ràng buộc kỹ thuật, môi trường, dependency với hệ thống bên thứ ba.

Có một lưu ý quan trọng về thuật ngữ: trong thực tế, ranh giới giữa FRD và SRS không phải lúc nào cũng rạch ròi. Nhiều công ty gộp FRD và SRS làm một (thường gọi chung là SRS theo chuẩn IEEE 830). Một số nơi lại tách rất rõ. Là BA, bạn cần hỏi ngay khi onboard: "Ở công ty mình, document hierarchy gồm những tầng nào?" — đừng máy móc áp dụng lý thuyết.

Nguyên tắc xuyên suốt: Traceability

Sợi chỉ đỏ nối ba tầng lại là traceability (khả năng truy vết). Mỗi functional requirement trong FRD phải truy ngược lên được một business requirement trong BRD. Mỗi đặc tả kỹ thuật trong SRS phải truy ngược lên được một functional requirement trong FRD. Nếu một dòng trong SRS không truy ngược về đâu được, đó là dấu hiệu của "gold-plating" — làm thừa thứ không ai cần.

Tình huống thực tế

Ví dụ 1 — Tiki và dự án "Đổi trả hàng tự động"

Giả sử Tiki muốn giảm chi phí vận hành tổng đài bằng cách cho phép khách tự khởi tạo yêu cầu đổi trả qua app thay vì gọi điện. Hãy xem ba tầng tài liệu phân chia thế nào.

• BRD (cho ban giám đốc): "Hiện 35% cuộc gọi tổng đài liên quan đến đổi trả, tốn ~2 tỷ đồng/năm chi phí nhân sự. Mục tiêu: chuyển 60% yêu cầu đổi trả sang self-service trong 9 tháng, tiết kiệm ~1,2 tỷ đồng/năm. KPI: tỷ lệ đổi trả self-service, thời gian xử lý trung bình, CSAT."
• FRD (cho team sản phẩm): "Khách hàng có thể chọn đơn hàng trong vòng 7 ngày kể từ ngày giao thành công để tạo yêu cầu đổi trả. Hệ thống yêu cầu khách chọn lý do từ danh sách định sẵn và upload tối đa 5 ảnh minh chứng. Nếu giá trị đơn dưới 200.000đ, tự động duyệt; nếu cao hơn, chuyển sang hàng đợi kiểm duyệt."
• SRS (cho dev): "Endpoint POST /returns nhận order_id, reason_code, images[]. Validate: order_id phải tồn tại và có delivered_at không quá 7 ngày. Ảnh tối đa 5MB/file, định dạng JPEG/PNG. Auto-approve khi order.total < 200000. Thời gian phản hồi p95 < 400ms."

Bài học: Cùng một tính năng, ba cách diễn đạt cho ba khán giả. Giám đốc đọc BRD đủ để gật đầu duyệt ngân sách. Dev đọc SRS đủ để code mà không cần hỏi lại. Nếu bạn đưa SRS cho giám đốc, ông ấy sẽ bối rối; nếu đưa BRD cho dev, anh ấy sẽ phải đoán mò.

Ví dụ 2 — Ngân hàng số và cái bẫy "gộp tầng"

Một fintech tại TP.HCM (gọi là công ty F) thuê một bạn dev mới lên BA viết tài liệu cho tính năng chuyển tiền liên ngân hàng. Bạn ấy, theo thói quen kỹ thuật, viết thẳng một tài liệu duy nhất bắt đầu bằng sơ đồ sequence diagram và đặc tả API NAPAS.

Khi tài liệu này được gửi lên cho Giám đốc Khối Vận hành để xin phê duyệt, ông không hiểu gì cả — vì không có phần nào nói rõ "tính năng này phục vụ phân khúc khách hàng nào, kỳ vọng tăng bao nhiêu giao dịch, rủi ro tuân thủ ra sao". Phê duyệt bị treo 3 tuần. Trong khi đó, đội Compliance lại không thấy phần nào đề cập tới giới hạn hạn mức theo quy định của Ngân hàng Nhà nước, nên suýt nữa tính năng đi vào dev với một lỗ hổng pháp lý.

Sau sự cố, BA mới tách lại thành: BRD (1,5 trang — mục tiêu, phân khúc, ROI, rủi ro tuân thủ) cho ban giám đốc; FRD (mô tả luồng chuyển tiền, hạn mức, business rule) cho team; SRS (đặc tả tích hợp NAPAS) cho dev. Phê duyệt qua trong 2 ngày.

Bài học: Gộp tầng không sai về mặt nội dung, nhưng sai về mặt giao tiếp. Mỗi nhóm người đọc cần "lát cắt" thông tin phù hợp với họ. Document hierarchy không phải hình thức quan liêu — nó là công cụ để mỗi người ra quyết định nhanh hơn.

Ví dụ 3 — Startup edtech và sự linh hoạt của hierarchy

Một startup edtech 15 người ở Hà Nội làm theo Agile, sprint 2 tuần. Họ không viết BRD-FRD-SRS đầy đủ kiểu waterfall. Thay vào đó: mục tiêu kinh doanh được ghi gọn trong một "Product Brief" 1 trang (vai trò BRD thu nhỏ), chức năng được mô tả bằng các user story trên Jira kèm acceptance criteria (vai trò FRD), và chi tiết kỹ thuật nằm trong các comment kỹ thuật + tech design doc gắn vào từng epic (vai trò SRS).

Bài học: Hierarchy là vai trò của tài liệu, không phải tên file cứng nhắc. Dù bạn ở công ty waterfall nặng tài liệu hay startup Agile tinh gọn, ba "vai trò" Why–What–How vẫn luôn tồn tại. BA giỏi nhận ra ba vai trò này dù chúng được gọi bằng tên gì.

Hướng dẫn từng bước

Khi bạn được giao chuẩn bị bộ tài liệu cho một dự án, hãy đi theo trình tự sau:

• Xác định các nhóm người đọc trước khi viết. Hỏi: ai sẽ duyệt ngân sách? Ai sẽ thiết kế giải pháp? Ai sẽ code? Mỗi nhóm là một tầng tài liệu tiềm năng.

• Bắt đầu từ BRD — viết "Why" trước. Ngồi với sponsor, làm rõ mục tiêu kinh doanh, KPI, ngân sách, phạm vi. Chốt được scope ở tầng này sẽ tránh được 80% tranh cãi về sau. Giữ BRD ngắn — lý tưởng 3–8 trang.

• Triển khai BRD thành FRD — viết "What". Với mỗi business requirement, 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. Gắn ID cho từng requirement (ví dụ FR-012) để phục vụ traceability.

• Chi tiết hóa FRD thành SRS — viết "How". Với phần kỹ thuật, bổ sung data model, API contract, validation rule, và đặc biệt là non-functional requirements. Lúc này nền tảng dev của bạn phát huy tác dụng mạnh nhất.

• Lập traceability matrix. Một bảng đơn giản: cột business requirement, cột functional requirement, cột technical spec. Bất kỳ ô nào trống đều là tín hiệu cần kiểm tra — hoặc bạn làm thừa, hoặc bạn bỏ sót.

• Review ngược từ dưới lên. Đọc SRS và tự hỏi "dòng này phục vụ business goal nào?". Nếu không trả lời được, cân nhắc cắt bỏ.

• Chọn mức độ chính thức phù hợp với văn hóa công ty. Waterfall: tài liệu đầy đủ, ký duyệt. Agile: hierarchy thu gọn thành brief + user story + tech doc. Đừng áp template một cách máy móc.

Lỗi thường gặp & mẹo

Lỗi 1 — Nhồi giải pháp kỹ thuật vào BRD. Dev-turned-BA hay viết "hệ thống sẽ dùng Redis cache để..." ngay trong BRD. Sponsor không cần và không hiểu. Mẹo: khi viết BRD, tự hỏi "câu này một giám đốc tài chính có đọc được không?". Nếu không, nó thuộc tầng dưới.

Lỗi 2 — Viết FRD mơ hồ như BRD. Câu kiểu "hệ thống phải thân thiện với người dùng" là vô nghĩa ở tầng FRD. Functional requirement phải kiểm chứng được (testable). Mẹo: mỗi requirement nên viết được thành một test case.

Lỗi 3 — Bỏ quên non-functional requirements trong SRS. Dev mới chuyển BA thường tập trung vào chức năng mà quên hiệu năng, bảo mật, khả năng mở rộng. Đây lại chính là phần dễ gây sự cố production nhất. Mẹo: luôn có một mục NFR riêng trong SRS, dù chỉ vài dòng.

Lỗi 4 — Tài liệu "chết" sau khi viết xong. Requirements thay đổi nhưng tài liệu không được cập nhật, dẫn đến code và doc lệch nhau. Mẹo: gắn version, ngày cập nhật, và coi tài liệu là "living document" — cập nhật ngay khi có change request.

Lỗi 5 — Sao chép cứng nhắc template từ internet. Mỗi tổ chức có hierarchy khác nhau. Mẹo: khi mới vào, xin xem 2–3 bộ tài liệu cũ của công ty để học "ngôn ngữ nhà".

Mẹo vàng: Một tài liệu tốt không phải là tài liệu dài nhất, mà là tài liệu giúp người đọc ra quyết định nhanh nhất với ít câu hỏi lại nhất. Hãy đo chất lượng tài liệu bằng số câu hỏi follow-up bạn nhận được — càng ít càng tốt.

Bài tập thực hành

Hãy chọn một tính năng quen thuộc — ví dụ "đăng nhập bằng số điện thoại + OTP" cho một app giao đồ ăn — và thực hiện:

• Viết 3 đoạn cho 3 tầng (mỗi đoạn 3–5 câu):

- BRD: mục tiêu kinh doanh của việc thêm OTP login (ví dụ: tăng tỷ lệ đăng ký, giảm tài khoản giả). Kèm 1 KPI. - FRD: mô tả luồng chức năng (gửi OTP, nhập, retry, hết hạn) ở mức hành vi hệ thống. - SRS: đặc tả kỹ thuật (endpoint, độ dài OTP, thời gian hết hạn, rate limit, NFR về thời gian gửi SMS).

• Lập một traceability matrix mini với ít nhất 3 dòng, nối business requirement → functional requirement → technical spec.

• Tự kiểm tra: đọc lại đoạn BRD và gạch chân mọi từ kỹ thuật. Nếu có, hãy chuyển chúng xuống tầng phù hợp.

• Thử thách nâng cao: viết một câu trong SRS mà bạn KHÔNG truy ngược được lên FRD — rồi giải thích vì sao đó là dấu hiệu nguy hiểm.

Làm xong, hãy đưa cho một người bạn không làm kỹ thuật đọc phần BRD và một bạn dev đọc phần SRS. Nếu cả hai đều hiểu phần của mình mà không cần hỏi, bạn đã nắm được bài này.

Tóm tắt

• Document hierarchy gồm ba tầng cốt lõi: BRD (Why — cho sponsor/exec), FRD (What — cho team), SRS (How — cho dev).
• Mỗi tầng phục vụ một nhóm người đọc khác nhau; sai tầng nghĩa là sai giao tiếp, dù nội dung đúng.
• BRD chứa business goal, scope, KPI, ROI, high-level requirements — tuyệt đối không có chi tiết kỹ thuật.
• FRD biến mục tiêu thành các chức năng cụ thể, kiểm chứng được. SRS biến chức năng thành đặc tả kỹ thuật chính xác kèm non-functional requirements.
• Traceability là sợi chỉ đỏ nối ba tầng: mọi dòng tầng dưới phải truy ngược lên tầng trên.
• Hierarchy là vai trò của tài liệu, không phải tên file cố định — linh hoạt theo văn hóa waterfall hay Agile của công ty.
• Lợi thế của dev-turned-BA: bạn viết FRD và SRS rất tốt nhờ tư duy logic. Thử thách của bạn: học cách "lên tầng" để viết BRD bằng ngôn ngữ kinh doanh thuần túy.