Mở đầu — vì sao bài này quan trọng
Hãy bắt đầu bằng một câu chuyện mà mình tin chắc bạn sẽ thấy quen. Một bạn kế toán tổng hợp chuyển sang làm BA tại một công ty fintech ở TP.HCM, được giao viết tài liệu cho dự án "tự động hóa đối soát thanh toán". Bạn ấy hồ hởi viết ngay: "Hệ thống phải có nút Export ra Excel, màn hình có 12 cột, đối soát chạy lúc 23h hằng đêm". Tài liệu dài 8 trang, rất chi tiết. Nhưng khi đưa cho stakeholder duyệt, Giám đốc Vận hành đọc xong cau mày hỏi: "Em ơi, rốt cuộc cái này giúp công ty tiết kiệm được gì? Vì sao mình làm nó trước chứ không phải dự án khác?". Bạn BA đứng hình, vì cả 8 trang không có lấy một dòng trả lời được câu hỏi đó.
Đây chính là cái bẫy lớn nhất với người Finance/Kế toán khi mới chuyển sang BA: chúng ta quen làm việc với con số cụ thể, với bút toán, với báo cáo có cấu trúc rõ ràng, nên ta có xu hướng nhảy thẳng xuống chi tiết kỹ thuật mà bỏ qua tầng tư duy phía trên. Trong khi đó, nghề BA đòi hỏi bạn phải biết requirement (yêu cầu) tồn tại ở nhiều cấp độ khác nhau, và mỗi cấp độ trả lời một câu hỏi khác nhau, dành cho một đối tượng người đọc khác nhau.
BABOK (Business Analysis Body of Knowledge — bộ kiến thức chuẩn của nghề BA) phân chia requirement thành các cấp độ rõ ràng. Hiểu được mô hình này, bạn sẽ không bao giờ còn viết "lộn tầng" nữa, biết được tài liệu mình đang viết phục vụ ai, và quan trọng nhất: luôn truy được mỗi dòng yêu cầu kỹ thuật về đúng mục tiêu kinh doanh đã sinh ra nó. Đây là bài học nền tảng — không nắm vững nó thì những bài về SRS, RTM hay prioritization sau này sẽ rất chông chênh.
Khái niệm cốt lõi
BABOK định nghĩa bốn cấp độ requirement (đôi khi tài liệu khác gộp còn ba, nhưng chúng ta nên hiểu đủ bốn). Cách dễ nhớ nhất: hình dung một kim tự tháp lật ngược, đi từ "vì sao" rộng nhất xuống "làm cái gì cụ thể" hẹp nhất.
1. Business Requirements — Yêu cầu kinh doanh (cấp WHY)
Đây là tầng cao nhất, trả lời câu hỏi: Doanh nghiệp muốn đạt được điều gì, và vì sao? Nó là mục tiêu, vấn đề cần giải quyết, cơ hội cần nắm bắt, được phát biểu ở góc độ toàn tổ chức chứ không phải một cá nhân.
Đặc điểm: ngắn gọn, thường gắn với con số đo được (KPI, doanh thu, chi phí, thời gian, rủi ro). Ví dụ: "Giảm 70% thời gian đối soát cuối ngày từ 4 giờ xuống dưới 1 giờ trong quý 3", hoặc "Giảm tỷ lệ sai sót đối soát thủ công từ 3% xuống dưới 0,5%". Người Finance có lợi thế tự nhiên ở đây, vì bạn vốn quen tư duy bằng con số tài chính, ROI, chi phí cơ hội.
2. Stakeholder Requirements — Yêu cầu của các bên liên quan (cấp WHO needs WHAT)
Tầng này trả lời: Từng nhóm người dùng/bên liên quan cần gì để công việc của họ trôi chảy? Cùng một business requirement, mỗi stakeholder lại có nhu cầu khác nhau. Kế toán cần đối soát đúng; trưởng phòng cần báo cáo tổng hợp; bộ phận IT cần hệ thống không sập; bộ phận tuân thủ cần lưu vết audit.
Đây là cầu nối quan trọng. Stakeholder requirement diễn giải mục tiêu kinh doanh thành nhu cầu cụ thể của con người, nhưng vẫn chưa nói hệ thống làm thế nào. Ví dụ: "Nhân viên kế toán cần được hệ thống tự động phát hiện và đánh dấu các giao dịch lệch giữa sao kê ngân hàng và sổ nội bộ".
3. Solution Requirements — Yêu cầu giải pháp (cấp WHAT the system does)
Đây là tầng mà giải pháp/hệ thống phải làm gì để đáp ứng các tầng trên. BABOK chia tầng này thành hai nhánh:
- Functional Requirements (yêu cầu chức năng): hệ thống làm gì. Ví dụ: "Hệ thống cho phép upload file sao kê ngân hàng định dạng .csv và .xlsx", "Hệ thống tự động khớp giao dịch theo số tham chiếu và số tiền", "Hệ thống đánh dấu màu đỏ các dòng lệch quá 1.000 VND".
- Non-functional Requirements (yêu cầu phi chức năng): hệ thống làm tốt đến mức nào — về hiệu năng, bảo mật, độ tin cậy, khả năng mở rộng. Ví dụ: "Quá trình đối soát 100.000 giao dịch phải hoàn tất trong dưới 5 phút", "Hệ thống lưu log mọi thao tác đối soát tối thiểu 7 năm theo quy định kế toán".
4. Transition Requirements — Yêu cầu chuyển đổi (cấp HOW to get there)
Tầng này thường bị bỏ quên nhất, nhưng cực kỳ thực tế. Nó trả lời: Cần gì để chuyển từ trạng thái hiện tại sang trạng thái có giải pháp mới? Đây là những yêu cầu tạm thời, chỉ tồn tại trong giai đoạn triển khai rồi biến mất sau khi hệ thống đi vào ổn định.
Ví dụ: di chuyển dữ liệu đối soát 3 năm cũ từ Excel sang hệ thống mới (data migration), đào tạo 15 nhân viên kế toán sử dụng giao diện mới, chạy song song hệ thống cũ và mới trong 2 tháng để kiểm chứng. Người Finance vốn quen với khái niệm "chuyển số dư đầu kỳ", "kết chuyển cuối năm" — bản chất transition requirement rất giống tư duy đó.
Mối quan hệ truy vết (traceability)
Điểm cốt lõi cần khắc cốt ghi tâm: bốn tầng này phải nối được với nhau. Mỗi solution requirement phải truy ngược lên được một stakeholder requirement, và stakeholder requirement đó phải truy ngược lên được một business requirement. Nếu bạn viết một chức năng mà không truy được nó lên mục tiêu kinh doanh nào, thì rất có thể đó là chức năng thừa — gold-plating. Ngược lại, nếu có business requirement mà không tầng dưới nào phục vụ, thì giải pháp của bạn còn lỗ hổng.
Tình huống thực tế
Ví dụ 1 — Dự án đối soát tại fintech (sửa lại cho đúng tầng)
Quay lại bạn BA ở đầu bài. Sau khi học mô hình bốn tầng, bạn ấy viết lại tài liệu như sau:
- Business: "Giảm thời gian đối soát cuối ngày từ 4 giờ xuống dưới 1 giờ, giảm sai sót thủ công từ 3% xuống dưới 0,5%, để bộ phận kế toán xử lý kịp khối lượng giao dịch tăng 200% sau khi ra mắt ví điện tử."
- Stakeholder: Kế toán viên cần tự động phát hiện giao dịch lệch; Trưởng phòng cần báo cáo tỷ lệ khớp hằng ngày; Bộ phận Compliance cần lưu vết toàn bộ.
- Solution (functional): upload sao kê, tự khớp theo số tham chiếu + số tiền, đánh dấu dòng lệch, xuất báo cáo. (non-functional): xử lý 100.000 giao dịch < 5 phút, lưu log 7 năm.
- Transition: migrate dữ liệu 3 năm cũ, đào tạo 15 nhân viên, chạy song song 2 tháng.
Ví dụ 2 — Khi thiếu tầng Business khiến cả team làm lạc
Một công ty bảo hiểm tại Hà Nội triển khai cổng thanh toán phí online. BA (cũng xuất thân kế toán) viết rất kỹ phần functional: 5 cổng thanh toán, 8 màn hình, lưu lịch sử giao dịch. Team dev làm đúng 4 tháng. Khi nghiệm thu, sếp hỏi: "Mục tiêu là tăng tỷ lệ khách đóng phí đúng hạn lên 85%, sao báo cáo không đo được con số đó?". Hóa ra vì không khai báo business requirement rõ ràng ngay từ đầu, hệ thống không hề ghi nhận chỉ số "đóng phí đúng hạn", và phải làm thêm một sprint nữa chỉ để bổ sung khả năng đo lường.
Bài học: Business requirement không chỉ để "trang trí" đầu tài liệu. Nó định hướng cả những gì hệ thống cần đo và log. Bỏ qua tầng này, bạn sẽ build một thứ chạy được nhưng không chứng minh được giá trị.
Ví dụ 3 — Transition requirement cứu một dự án ERP
Một doanh nghiệp sản xuất ở Bình Dương chuyển từ kế toán trên MISA sang ERP mới. BA viết đủ business, stakeholder, solution rất bài bản. Nhưng đến ngày go-live, kế toán trưởng tá hỏa: số dư công nợ của 400 nhà cung cấp chưa được chuyển sang, và không ai biết quy tắc làm tròn của hệ thống mới có khớp với cách hạch toán cũ không. Dự án trễ 3 tuần.
May là ở lần triển khai sau cho chi nhánh thứ hai, BA đã rút kinh nghiệm, viết hẳn một mục transition requirement: quy tắc migrate số dư đầu kỳ, đối chiếu tổng số dư cũ–mới phải bằng nhau đến từng đồng, kế hoạch đào tạo, và 1 tháng chạy song song. Lần này go-live mượt mà. Bài học: với người Finance, transition requirement là tầng bạn dễ làm tốt nhất nếu nhớ ra nó — vì nó chính là tư duy "kết chuyển, đối chiếu số dư" mà bạn đã làm cả sự nghiệp.
Hướng dẫn từng bước
Khi nhận một yêu cầu mới, hãy đi theo trình tự từ trên xuống — đừng bao giờ bắt đầu từ giữa:
- Hỏi "Vì sao?" trước tiên (Business). Gặp người bảo trợ dự án (sponsor) và hỏi: mục tiêu kinh doanh là gì, đo bằng con số nào, vì sao làm bây giờ. Nếu không có câu trả lời định lượng, hãy ở lại đây cho đến khi có. Người Finance: hãy ép một con số ra, đừng chấp nhận "để cho tiện hơn".
- Lập danh sách stakeholder và phỏng vấn từng nhóm (Stakeholder). Với mỗi nhóm, hỏi: "Để đạt mục tiêu trên, anh/chị cần hệ thống giúp gì cho công việc của mình?". Ghi lại nhu cầu, chưa vội nghĩ tới màn hình hay nút bấm.
- Diễn giải nhu cầu thành chức năng và phi chức năng (Solution). Mỗi stakeholder requirement sẽ đẻ ra một hoặc vài functional requirement. Với mỗi chức năng, tự hỏi thêm: "Nó cần nhanh/an toàn/đáng tin đến mức nào?" để rút ra non-functional.
- Hỏi "Cần gì để chuyển sang trạng thái mới?" (Transition). Liệt kê data migration, đào tạo, chạy song song, dọn dữ liệu rác. Nhớ đánh dấu đây là yêu cầu tạm thời.
- Vẽ bảng truy vết. Kẻ một bảng: cột Business → Stakeholder → Solution. Kiểm tra mỗi dòng solution có đường nối lên tận business không. Dòng nào "mồ côi" thì xem lại — hoặc nó thừa, hoặc bạn thiếu một business requirement.
- Chọn đúng tài liệu cho đúng người đọc. Business + Stakeholder thường nằm trong tài liệu BRD (Business Requirements Document) cho lãnh đạo; Solution nằm trong SRS/FRD cho team kỹ thuật; Transition nằm trong kế hoạch triển khai.
Lỗi thường gặp & mẹo
- Nhảy thẳng xuống Solution. Đây là lỗi số một của ex-Finance vì ta yêu chi tiết cụ thể. Mẹo: trước khi viết bất kỳ chức năng nào, viết xong một dòng business requirement có con số.
- Nhầm Business với Solution. "Cần một dashboard" KHÔNG phải business requirement — nó là giải pháp. Business requirement là "cần ra quyết định nhanh hơn dựa trên dữ liệu thời gian thực". Mẹo: nếu câu của bạn nhắc tới một công cụ/màn hình cụ thể, nó đã tụt xuống tầng Solution rồi.
- Quên hẳn Non-functional. Người Finance hay tập trung vào "đúng số" mà quên "nhanh, an toàn, lưu vết". Mà với hệ thống tài chính, non-functional (bảo mật, audit log, độ chính xác làm tròn) lại thường là thứ làm sập dự án. Mẹo: với mỗi functional, luôn hỏi thêm bốn chữ — nhanh, an toàn, tin cậy, tuân thủ.
- Bỏ quên Transition. Dẫn tới go-live hỗn loạn như ví dụ ERP. Mẹo: liên tưởng tới "kết chuyển số dư cuối kỳ" của nghề cũ.
- Viết Solution mà không truy được lên trên. Đây là gold-plating. Mẹo: nếu không gắn được lên business nào, hỏi stakeholder xem có thực sự cần không, thường là không.
- Viết business requirement chung chung kiểu "tăng hiệu quả". Không đo được thì không kiểm chứng được. Mẹo: ép vào công thức "Giảm/Tăng [chỉ số] từ [X] xuống/lên [Y] trong [thời gian]".
Bài tập thực hành
Lấy một quy trình bạn từng làm thời còn ở Finance/Kế toán — ví dụ "lập báo cáo thuế GTGT hằng tháng" hoặc "đối chiếu công nợ phải thu". Giả định công ty muốn số hóa quy trình này. Hãy viết tài liệu yêu cầu phân theo bốn tầng:
- Business: Viết đúng 1–2 câu, bắt buộc có con số đo lường (giảm thời gian, giảm sai sót, hoặc giảm chi phí — bao nhiêu phần trăm, trong bao lâu).
- Stakeholder: Liệt kê ít nhất 3 nhóm liên quan và nhu cầu của từng nhóm.
- Solution: Viết tối thiểu 5 functional requirement và 3 non-functional requirement.
- Transition: Viết tối thiểu 3 yêu cầu chuyển đổi tạm thời.
- Bảng truy vết: Kẻ bảng nối mỗi functional requirement lên đúng stakeholder và business requirement của nó. Đánh dấu bất kỳ dòng nào không truy ngược được và tự giải thích: nó thừa, hay bạn thiếu một tầng trên?
Tóm tắt
Requirement không phải một khối phẳng — nó có bốn tầng, mỗi tầng trả lời một câu hỏi khác nhau cho một người đọc khác nhau:
- Business (WHY): doanh nghiệp muốn đạt gì, đo bằng con số.
- Stakeholder (WHO needs WHAT): từng nhóm người cần gì để công việc trôi chảy.
- Solution (WHAT system does): chia làm Functional (làm gì) và Non-functional (làm tốt đến mức nào).
- Transition (HOW to get there): những việc tạm thời để chuyển sang trạng thái mới — migrate, đào tạo, chạy song song.