Mở đầu — vì sao bài này quan trọng
Nếu bạn từng làm Sales hay Business Development, bạn đã viết tài liệu thuyết phục mỗi ngày mà có thể không gọi tên nó là "documentation". Một bản proposal gửi khách hàng, một email follow-up sau cuộc gặp, một quotation báo giá, một case study khoe thành công của khách hàng cũ — tất cả đều là văn bản nghiệp vụ. Đây là một tin cực kỳ tốt cho hành trình chuyển sang BA của bạn: bạn KHÔNG bắt đầu từ con số không. Bạn đã có phản xạ viết để người đọc hành động, biết cách cấu trúc lập luận, biết cách trình bày con số để thuyết phục.
Vấn đề là: tài liệu Sales và tài liệu BA phục vụ hai mục đích trái ngược nhau. Proposal viết để thuyết phục một người ra quyết định mua. BRD/SRS viết để một đội kỹ thuật xây đúng thứ cần xây, không hiểu sai, không tranh cãi về phạm vi. Một bên tô hồng để bán, một bên trung lập tuyệt đối để thực thi. Nếu bạn bê nguyên giọng văn Sales vào tài liệu BA, dev sẽ build sai, tester không biết test cái gì, và bạn mất uy tín ngay tài liệu đầu tiên.
Bài 16 này tập trung duy nhất vào một việc: chuyển hóa năng lực viết của Sales thành năng lực viết BRD (Business Requirements Document) và SRS (Software Requirements Specification) — hai loại tài liệu xương sống của nghề BA. Bạn sẽ hiểu cấu trúc, sự khác biệt, và quan trọng nhất là cách "dịch" thói quen viết cũ sang chuẩn mới.
Khái niệm cốt lõi
Proposal và BRD/SRS khác nhau ở đâu?
Hãy nhìn vào bốn trục so sánh để thấy rõ khoảng cách bạn cần vượt qua:
| Trục | Proposal (Sales) | BRD/SRS (BA) |
|---|---|---|
| Mục đích | Thuyết phục khách ký hợp đồng | Để dev/QA/PM thực thi chính xác |
| Giọng văn | Tô hồng, cảm xúc, lợi ích | Trung lập, kiểm chứng được, không hứa hẹn |
| Độ chính xác | "Tiết kiệm tới 40% chi phí" (ước lượng bán hàng) | "Hệ thống phải xử lý 500 giao dịch/giây" (đo được) |
| Người đọc | 1 người quyết định (sếp khách hàng) | Nhiều vai: dev, QA, PM, sponsor, vận hành |
BRD là gì?
BRD — Business Requirements Document trả lời câu hỏi "TẠI SAO" và "CÁI GÌ" ở tầng nghiệp vụ. Nó nói về nhu cầu kinh doanh, không nói về kỹ thuật. Đối tượng đọc chính là sponsor (người duyệt ngân sách), lãnh đạo phòng ban, và để cả đội thống nhất phạm vi trước khi đụng vào kỹ thuật.
Một BRD điển hình gồm:
- Business objectives — mục tiêu kinh doanh, gắn với con số (ví dụ: giảm thời gian xử lý hồ sơ vay từ 5 ngày xuống 2 ngày).
- Scope (in-scope / out-of-scope) — cái gì làm, cái gì KHÔNG làm. Phần out-of-scope quan trọng ngang phần in-scope vì nó chặn "scope creep".
- Stakeholders — ai liên quan, vai trò gì.
- High-level requirements — yêu cầu nghiệp vụ ở mức cao, đánh số (BR-01, BR-02...).
- Business rules — quy tắc nghiệp vụ (ví dụ: khách hàng dưới 18 tuổi không được mở tài khoản tín dụng).
- Assumptions & constraints — giả định và ràng buộc (ngân sách, thời gian, công nghệ bắt buộc).
- Success metrics — đo bằng gì để biết dự án thành công.
SRS là gì?
SRS — Software Requirements Specification đi xuống một tầng sâu hơn, trả lời câu hỏi "HỆ THỐNG PHẢI LÀM GÌ một cách cụ thể". Đối tượng đọc là dev và QA. Đây là nơi giọng văn Sales của bạn phải bị "tẩy" sạch nhất.
SRS thường gồm:
- Functional requirements — chức năng cụ thể: hệ thống phải cho phép, phải hiển thị, phải tính toán... Mỗi yêu cầu một dòng, đánh số, kiểm chứng được.
- Non-functional requirements (NFR) — yêu cầu phi chức năng: hiệu năng, bảo mật, khả năng mở rộng, tính khả dụng. Ví dụ: "Trang chủ phải tải xong dưới 2 giây với 95% request."
- Data requirements — dữ liệu nào lưu, định dạng, ràng buộc.
- Interface requirements — giao tiếp với hệ thống khác (cổng thanh toán, CRM, core banking...).
- Acceptance criteria — điều kiện để coi yêu cầu là hoàn thành.
Nguyên tắc vàng: mỗi yêu cầu phải SMART và testable
Một câu yêu cầu tốt phải khiến hai người đọc khác nhau hiểu y hệt nhau. Hãy nhớ công thức: dùng từ "phải/shall", một yêu cầu một ý, có thể kiểm chứng.
- Sales viết: "Hệ thống sẽ giúp khách hàng thanh toán nhanh và tiện lợi." → Không kiểm chứng được. "Nhanh" là bao nhiêu? "Tiện lợi" đo bằng gì?
- BA viết: "Hệ thống phải cho phép khách hàng hoàn tất thanh toán qua VNPay trong tối đa 3 bước thao tác, và phản hồi kết quả trong vòng 5 giây."
Tình huống thực tế
Ví dụ 1 — Anh Tuấn và cái proposal bị dev "trả lại"
Anh Tuấn từng là BD Manager tại một công ty SaaS quản lý kho ở TP.HCM, vừa chuyển sang vai trò BA. Dự án đầu tiên: xây tính năng cảnh báo tồn kho cho khách hàng là chuỗi cửa hàng tiện lợi.
Quen tay, anh viết tài liệu yêu cầu theo phong cách proposal: "Tính năng cảnh báo tồn kho thông minh sẽ giúp chủ cửa hàng không bao giờ lo hết hàng, tối ưu doanh thu, mang lại trải nghiệm vượt trội." Cả trang toàn lợi ích, không một con số.
Đội dev họp xong gửi lại đúng ba câu hỏi: "Cảnh báo khi tồn kho còn bao nhiêu? Cảnh báo qua kênh nào — email, SMS, hay in-app? Ngưỡng cảnh báo cố định hay cho khách tự cấu hình?" Anh Tuấn không trả lời được, phải quay lại hỏi khách thêm một tuần.
Sau đó anh viết lại theo chuẩn SRS:
- FR-01: Hệ thống phải cho phép người quản lý cửa hàng đặt ngưỡng cảnh báo tồn kho tối thiểu cho từng SKU (mặc định 10 đơn vị).
- FR-02: Khi số lượng tồn của một SKU chạm hoặc xuống dưới ngưỡng, hệ thống phải gửi thông báo qua in-app notification và email trong vòng 5 phút.
- FR-03: Hệ thống phải cho phép tắt cảnh báo theo từng SKU.
Ví dụ 2 — Tách BRD và SRS tại một fintech cho vay tiêu dùng
Một công ty fintech cho vay tiêu dùng ở Hà Nội triển khai tính năng "duyệt hồ sơ vay tự động". Chị Hương, BA của dự án (xuất thân Sales bảo hiểm), ban đầu nhồi tất cả vào một tài liệu duy nhất dài 40 trang. Kết quả: sponsor không đọc nổi vì quá kỹ thuật, còn dev thì khó tìm yêu cầu vì lẫn quá nhiều ngôn ngữ kinh doanh.
Chị tách làm hai tầng:
BRD (cho ban lãnh đạo duyệt):
- Business objective: giảm thời gian duyệt hồ sơ từ trung bình 8 giờ xuống dưới 10 phút cho 70% hồ sơ đủ điều kiện.
- Success metric: tỷ lệ hồ sơ duyệt tự động đạt ≥ 70% sau 3 tháng; tỷ lệ nợ xấu không tăng quá 0,5 điểm phần trăm.
- Out-of-scope: hồ sơ vay doanh nghiệp (chỉ làm vay tiêu dùng cá nhân).
- FR: Hệ thống phải tự động từ chối hồ sơ nếu điểm tín dụng CIC dưới 400.
- Business rule BR-07: hồ sơ có thu nhập khai báo dưới 8 triệu/tháng phải chuyển sang duyệt thủ công.
- NFR: hệ thống phải trả kết quả chấm điểm trong vòng 30 giây/hồ sơ ở thời điểm cao tải (1.000 hồ sơ/giờ).
Ví dụ 3 — Khi "ngôn ngữ bán hàng" làm hỏng phần Non-functional requirements
Một bạn BA mới chuyển từ Sales tại một startup giao đồ ăn viết NFR thế này: "Ứng dụng phải chạy mượt mà và ổn định kể cả giờ cao điểm." Câu này nghe rất hay trong một pitch deck, nhưng với QA thì vô nghĩa — "mượt" là bao nhiêu FPS, "ổn định" là tỷ lệ lỗi nào, "cao điểm" là bao nhiêu người dùng đồng thời?
Sau khi được mentor góp ý, bạn viết lại: "Ứng dụng phải duy trì thời gian phản hồi API dưới 1,5 giây với 95% request, khi có tối đa 5.000 người dùng đồng thời trong khung 11h–13h và 18h–20h. Tỷ lệ lỗi hệ thống (5xx) không vượt quá 0,1%."
Bài học: NFR là nơi tử huyệt của ex-Sales. Bản năng dùng tính từ cảm xúc rất mạnh, nhưng NFR đòi hỏi con số tuyệt đối. Mỗi khi viết NFR, hãy tự hỏi: "Tester sẽ đo cái này bằng cách nào?" Nếu không trả lời được, câu đó chưa đạt.
Hướng dẫn từng bước
Đây là quy trình thực dụng để bạn chuyển từ tư duy proposal sang BRD/SRS:
Bước 1 — Xác định bạn đang viết tài liệu nào. Hỏi: người đọc chính là ai? Nếu là sponsor/lãnh đạo duyệt ngân sách và phạm vi → viết BRD. Nếu là dev/QA cần build và test → viết SRS. Đừng bao giờ trộn hai mục đích vào một đoạn văn.
Bước 2 — Bắt đầu từ mục tiêu kinh doanh (tận dụng cơ bắp Sales của bạn). Viết Business objective gắn con số đo được. Đây là phần bạn mạnh nhất, hãy làm thật sắc: bài toán hiện tại tốn kém ở đâu, giải pháp tiết kiệm/tăng trưởng được bao nhiêu.
Bước 3 — Khóa phạm vi bằng in-scope và out-of-scope. Liệt kê rõ cái KHÔNG làm. Đây là tấm khiên chống scope creep mạnh nhất, và là thứ phân biệt BA chuyên nghiệp với người viết yêu cầu nghiệp dư.
Bước 4 — Liệt kê stakeholders và business rules. Vẽ bản đồ ai liên quan (kỹ năng Sales), rồi gom các quy tắc nghiệp vụ thành danh mục đánh số.
Bước 5 — Khi xuống SRS, viết từng functional requirement theo công thức "Hệ thống phải...". Một câu một yêu cầu, đánh số FR-xx, kiểm chứng được. Đọc lại từng câu và gạch bỏ mọi tính từ tô hồng (mượt, tuyệt vời, thông minh, dễ dàng).
Bước 6 — Viết non-functional requirements bằng con số. Hiệu năng, bảo mật, tải, thời gian phản hồi — tất cả phải có ngưỡng đo được.
Bước 7 — Chạy "bài test người lạ". Đưa tài liệu cho một người không dự họp đọc thử. Nếu họ hiểu đúng và không phải hỏi lại "ý là sao", tài liệu đạt. Nếu họ hỏi lại, đó chính là chỗ mơ hồ cần sửa.
Lỗi thường gặp & mẹo
Lỗi 1 — Dùng tính từ bán hàng thay cho con số. "Nhanh", "mượt", "thông minh", "vượt trội" không có chỗ trong SRS. Mẹo: lập một "blacklist" những từ này và Ctrl+F tìm chúng trước khi nộp tài liệu.
Lỗi 2 — Trộn BRD và SRS làm một. Sponsor ngợp vì quá kỹ thuật, dev khó tìm yêu cầu vì lẫn ngôn ngữ kinh doanh. Mẹo: tách hai file, hoặc tối thiểu tách hai chương rõ ràng với ghi chú "phần này dành cho ai".
Lỗi 3 — Quên phần out-of-scope. Không ghi cái KHÔNG làm thì sau này khách đòi thêm, bạn không có cơ sở từ chối. Mẹo: out-of-scope luôn là một mục bắt buộc trong template của bạn.
Lỗi 4 — Một câu chứa nhiều yêu cầu. "Hệ thống phải cho phép đăng nhập, đặt hàng và thanh toán" thực ra là ba yêu cầu, không thể test như một. Mẹo: thấy chữ "và" trong câu yêu cầu thì cân nhắc tách.
Lỗi 5 — Hứa hẹn trong tài liệu (di chứng nghề Sales). "Hệ thống sẽ làm khách hàng hài lòng" không phải yêu cầu, là lời hứa bán hàng. Mẹo: mỗi câu phải bắt đầu bằng chủ thể "Hệ thống phải..." và mô tả hành vi quan sát được.
Mẹo tận dụng nền Sales: dùng kỹ năng kể chuyện của bạn ở phần "Background/Problem statement" đầu BRD để sponsor đọc là gật đầu ngay. Đó là chỗ duy nhất giọng văn thuyết phục được phép tỏa sáng — phần còn lại phải trung lập.
Bài tập thực hành
- Dịch lại proposal cũ. Lấy một câu trong proposal/quotation bạn từng viết, ví dụ "Giải pháp giúp tiết kiệm chi phí vận hành đáng kể". Viết lại thành một functional requirement và một non-functional requirement có con số kiểm chứng được.
- Viết khung BRD một trang. Chọn một tính năng đơn giản (ví dụ: tính năng đặt lịch hẹn online cho một spa). Viết BRD gồm: Business objective (có con số), in-scope, out-of-scope, 3 stakeholders, 2 business rules, 1 success metric.
- Viết 5 functional requirements + 3 NFR cho tính năng đó theo công thức "Hệ thống phải...". Sau đó tự gạch bỏ mọi tính từ tô hồng còn sót lại.
- Bài test người lạ. Đưa tài liệu bài 2 và 3 cho một người bạn không cùng ngành đọc. Ghi lại mọi câu hỏi họ đặt ra — mỗi câu hỏi là một điểm mơ hồ bạn cần sửa.
Tóm tắt
- Ex-Sales đã có sẵn cơ bắp viết tài liệu nghiệp vụ: proposal, quotation, email, case study. Đây là lợi thế, không phải con số không.
- Nhưng proposal viết để thuyết phục mua, còn BRD/SRS viết để đội kỹ thuật thực thi chính xác — hai mục đích đối lập.
- BRD trả lời "tại sao" và "cái gì" ở tầng nghiệp vụ, dành cho sponsor: business objective, scope, stakeholders, business rules, success metrics.
- SRS trả lời "hệ thống phải làm gì" ở tầng chi tiết, dành cho dev/QA: functional requirements, non-functional requirements (con số!), data và interface requirements.
- Nguyên tắc vàng: mỗi yêu cầu phải bắt đầu bằng "Hệ thống phải...", một câu một ý, và kiểm chứng được. Tử huyệt của ex-Sales là tính từ tô hồng — hãy đổi mọi "nhanh/mượt/thông minh" thành con số.
- Tách BRD và SRS theo người đọc, đừng nhồi một file. Luôn có mục out-of-scope. Và dùng "bài test người lạ" để bắt mọi điểm mơ hồ trước khi nộp.