Mở đầu — vì sao bài này quan trọng
Khi bạn còn làm Marketing, mọi yêu cầu thường đến với bạn dưới một dạng duy nhất: "Tăng doanh số quý này lên 20%." Sếp nói một câu, và bạn tự mình suy ra phải chạy chiến dịch gì, viết content nào, đặt ngân sách bao nhiêu. Mọi tầng nhu cầu — từ mục tiêu kinh doanh đến hành động cụ thể — đều nằm gọn trong đầu bạn, vì bạn vừa là người nghĩ vừa là người làm.
Khi chuyển sang BA, đây chính là thói quen đầu tiên bạn phải gỡ bỏ. Vì trong một dự án phần mềm, "yêu cầu" không phải một khối thống nhất. Nó là một chuỗi nhiều tầng, mỗi tầng do một nhóm người khác nhau quan tâm, được viết ra với mức độ chi tiết khác nhau, và phục vụ một mục đích quản trị khác nhau. Một BA giỏi không phải người viết được nhiều yêu cầu, mà là người biết yêu cầu nào thuộc tầng nào — và không bao giờ trộn lẫn chúng.
BABOK v3 (Business Analysis Body of Knowledge — bộ kiến thức chuẩn của nghề BA mà chúng ta đã làm quen ở Bài 12) định nghĩa rõ bốn loại requirements. Hiểu sai cấu trúc này là nguyên nhân số một khiến tài liệu BA của người mới bị Dev và Stakeholder "trả về". Bài này sẽ giúp bạn nắm chắc cách phân loại để mọi yêu cầu bạn viết ra đều đặt đúng chỗ, đúng tầng, đúng người chịu trách nhiệm.
Khái niệm cốt lõi
BABOK v3 phân requirements thành bốn loại, sắp xếp theo một trục từ trừu tượng (cấp tổ chức) xuống cụ thể (cấp giải pháp). Hãy hình dung nó như một cái phễu ngược: bắt đầu rộng ở mục tiêu kinh doanh, thu hẹp dần xuống thành những gì hệ thống thực sự phải làm.
1. Business Requirements — Yêu cầu nghiệp vụ (cấp tổ chức)
Đây là tầng cao nhất: mục tiêu, lý do tồn tại của dự án ở cấp tổ chức. Nó trả lời câu hỏi "Vì sao chúng ta làm dự án này, và thành công nghĩa là gì?"
Business Requirement không nói về tính năng. Nó nói về giá trị kinh doanh, thường gắn với một con số đo lường được.
Ví dụ điển hình từ dàn ý gốc: "Giảm thời gian onboard khách hàng mới từ 5 ngày xuống còn 1 ngày." Hoặc: "Giảm tỷ lệ khách hàng bỏ giỏ hàng từ 70% xuống 55% trong 6 tháng." Lưu ý: ở tầng này chưa hề có chữ "màn hình", "nút bấm", "API" nào cả. Nó thuần túy là tham vọng kinh doanh.
Người quan tâm: Ban lãnh đạo, Project Sponsor, C-level. Đây là nhóm cấp ngân sách và sẽ hỏi "ROI đâu?" khi dự án xong.
2. Stakeholder Requirements — Yêu cầu của các bên liên quan
Tầng này là cầu nối. Nó mô tả nhu cầu của từng nhóm stakeholder cụ thể — họ cần làm được gì để Business Requirement ở trên thành hiện thực. Đây là góc nhìn của người sử dụng và người vận hành, diễn đạt bằng ngôn ngữ nghiệp vụ của họ, chưa phải ngôn ngữ kỹ thuật.
Nếu Business Requirement là "giảm thời gian onboard xuống 1 ngày", thì Stakeholder Requirements sẽ là:
- Nhân viên tín dụng cần xem được toàn bộ hồ sơ khách hàng trên một màn hình thay vì mở 4 hệ thống.
- Bộ phận pháp lý cần được tự động cảnh báo khi hồ sơ thiếu giấy tờ bắt buộc.
- Khách hàng cần nộp được giấy tờ qua điện thoại thay vì đến quầy.
3. Solution Requirements — Yêu cầu giải pháp
Đây là tầng "giải pháp phải làm gì để đáp ứng các Stakeholder Requirements ở trên". Đây là tầng dày nhất, chi tiết nhất, và là nơi BA dành phần lớn thời gian. BABOK chia Solution Requirements thành hai nhánh:
a. Functional Requirements (yêu cầu chức năng) — Hệ thống phải làm gì. Hành vi cụ thể, có thể kiểm thử được. Ví dụ: "Hệ thống phải cho phép upload tối đa 5 file ảnh giấy tờ, mỗi file dưới 10MB, định dạng JPG/PNG/PDF." Đây là nơi User Stories và Use Cases (Bài 19, Bài 21) sống.
b. Non-Functional Requirements (yêu cầu phi chức năng) — Hệ thống phải làm tốt đến mức nào. Tốc độ, bảo mật, khả năng chịu tải, tính khả dụng. Ví dụ: "Màn hình tổng hợp hồ sơ phải load dưới 2 giây với 95% request." Chúng ta sẽ đào sâu nhánh này ở Bài 40.
4. Transition Requirements — Yêu cầu chuyển đổi
Đây là loại requirement đặc biệt và hay bị bỏ quên nhất. Nó mô tả những gì cần có để chuyển từ trạng thái hiện tại sang trạng thái mới — và chỉ tồn tại tạm thời, sau khi go-live thì biến mất. Bao gồm: di chuyển dữ liệu cũ (data migration), đào tạo người dùng, chạy song song hệ thống cũ và mới trong giai đoạn chuyển tiếp.
Ví dụ: "Cần migrate 50.000 hồ sơ khách hàng từ hệ thống cũ sang hệ thống mới trước ngày go-live, đối soát đủ 100% trường bắt buộc." Transition Requirement không thể viết được cho đến khi bạn đã hiểu cả trạng thái cũ lẫn trạng thái mới (liên quan đến Gap Analysis — Bài 26).
Mối quan hệ giữa các tầng — quy tắc truy vết (traceability)
Điểm mấu chốt: mọi requirement ở tầng dưới phải truy vết ngược lên được một requirement ở tầng trên. Nếu bạn viết một Functional Requirement mà không chỉ ra được nó phục vụ Stakeholder Requirement nào, và cuối cùng phục vụ Business Requirement nào — thì đó là dấu hiệu "gold-plating" (làm thừa). Ngược lại, nếu một Business Requirement không có Solution Requirement nào đỡ phía dưới, nghĩa là mục tiêu đó chưa được giải quyết.
Tình huống thực tế
Ví dụ 1: Ngân hàng số tại VN — dự án rút ngắn thời gian mở thẻ tín dụng
Một ngân hàng tầm trung tại TP.HCM (gọi là Ngân hàng V) muốn cạnh tranh với các ngân hàng số. Thời gian phê duyệt thẻ tín dụng hiện tại là 7 ngày, đối thủ làm trong 2 ngày.
Một BA mới từ Marketing chuyển sang đã viết tài liệu yêu cầu như thế này (sai): "Làm app cho khách hàng chụp CMND, hệ thống tự đọc OCR, gửi qua bộ phận thẩm định, có dashboard cho manager." Vấn đề: toàn bộ là tính năng (Solution level), không hề có tầng Business và Stakeholder. Khi sếp hỏi "tại sao phải có dashboard cho manager?", BA không trả lời được vì không truy vết được mục tiêu.
Cách làm đúng, phân tầng rõ:
- Business Requirement: Giảm thời gian phê duyệt thẻ từ 7 ngày xuống 2 ngày, nâng tỷ lệ chuyển đổi từ đăng ký sang phát hành thẻ từ 40% lên 60% trong 9 tháng.
- Stakeholder Requirements: Nhân viên thẩm định cần nhận hồ sơ số hóa thay vì bản giấy; Trưởng phòng cần theo dõi hồ sơ nào đang quá hạn xử lý; Khách hàng cần biết trạng thái hồ sơ của mình mà không phải gọi tổng đài.
- Solution Requirements (Functional): OCR đọc tự động CMND/CCCD; gửi thông báo trạng thái qua app; dashboard cảnh báo hồ sơ tồn quá 24h.
- Solution Requirements (Non-Functional): OCR đạt độ chính xác tối thiểu 95%; dữ liệu khách hàng mã hóa theo chuẩn ngân hàng.
- Transition Requirements: Đào tạo 30 nhân viên thẩm định; chạy song song quy trình giấy và quy trình số trong 1 tháng đầu.
Ví dụ 2: Sàn thương mại điện tử — yêu cầu bị "nhảy tầng"
Một sàn TMĐT (giả định, kiểu Tiki) nhận yêu cầu từ Giám đốc vận hành: "Tôi muốn có nút 'Mua lại' ở trang lịch sử đơn hàng." Đây là một câu nói ở tầng Solution (rất cụ thể, đã chỉ ra tính năng).
BA giỏi không vội viết user story cho cái nút này. Anh ấy "leo ngược lên" để tìm tầng gốc bằng cách hỏi: "Anh kỳ vọng nút này mang lại điều gì?" Câu trả lời: "Để khách mua lại đồ tiêu dùng nhanh hơn, tăng đơn hàng lặp lại."
Giờ phân tầng được:
- Business Requirement: Tăng tỷ lệ đơn hàng lặp lại (repeat purchase) của nhóm hàng tiêu dùng nhanh từ 25% lên 35% trong quý.
- Stakeholder Requirement: Khách hàng cần đặt lại đúng những món đã mua mà không phải tìm lại từng sản phẩm.
- Solution Requirement: Nút "Mua lại" thêm toàn bộ sản phẩm của đơn cũ vào giỏ; nếu sản phẩm hết hàng thì báo và bỏ qua món đó.
Ví dụ 3: Ví điện tử — Transition Requirement bị quên gây vỡ kế hoạch
Một ví điện tử (giả định kiểu MoMo) nâng cấp hệ thống định danh khách hàng (eKYC). Đội BA viết rất đầy đủ Business, Stakeholder, Solution Requirements. Tính năng mới chạy ngon trên môi trường test. Nhưng đến ngày go-live thì vỡ trận: 2 triệu khách hàng cũ chưa có dữ liệu định danh theo chuẩn mới, hệ thống mới không nhận diện được họ, tổng đài cháy máy.
Nguyên nhân: đội BA quên hẳn tầng Transition Requirements. Họ chỉ nghĩ đến trạng thái "TO-BE" (hệ thống mới) mà không xử lý việc đưa 2 triệu khách hàng từ "AS-IS" sang.
Đáng lẽ phải có: "Migrate dữ liệu định danh của khách hàng hiện hữu sang định dạng mới; với khách thiếu dữ liệu, hiển thị luồng bổ sung định danh nhẹ nhàng trong 30 ngày thay vì khóa tài khoản ngay."
Bài học: Bốn loại requirement không phải để học thuộc cho đẹp. Bỏ sót một loại — đặc biệt là Transition — có thể làm hỏng cả một dự án đã làm đúng ba loại còn lại.
Hướng dẫn từng bước
Đây là quy trình thực hành để phân loại requirements cho một dự án mới:
Bước 1 — Xác định Business Requirements trước tiên. Gặp Sponsor/lãnh đạo, hỏi: "Dự án thành công thì con số nào thay đổi?" Viết ra 1–3 mục tiêu, mỗi mục tiêu phải có chỉ số đo được và mốc thời gian. Nếu không có con số, hãy hỏi tiếp cho đến khi có.
Bước 2 — Lập danh sách stakeholder rồi khai thác Stakeholder Requirements. Với mỗi nhóm (người dùng cuối, người vận hành, bộ phận hỗ trợ, pháp lý...), hỏi: "Để đạt mục tiêu trên, anh/chị cần làm được gì mà hiện giờ chưa làm được?" Ghi theo ngôn ngữ của họ, chưa cần kỹ thuật.
Bước 3 — Chuyển hóa thành Solution Requirements. Với mỗi Stakeholder Requirement, hỏi: "Hệ thống cần làm gì để đáp ứng?" Tách rõ Functional (làm gì) và Non-Functional (làm tốt đến mức nào).
Bước 4 — Rà soát Transition Requirements. Tự hỏi: "Để bật hệ thống mới lên, cần xử lý gì cho dữ liệu cũ, người dùng cũ, quy trình cũ?" Thường gồm migration, đào tạo, chạy song song.
Bước 5 — Vẽ ma trận truy vết (Requirements Traceability Matrix). Một bảng đơn giản: mỗi dòng là một Solution Requirement, các cột chỉ ra nó truy vết lên Stakeholder Requirement nào và Business Requirement nào. Dòng nào "mồ côi" (không gắn lên đâu) là dấu hiệu làm thừa; mục tiêu nào không có dòng đỡ phía dưới là lỗ hổng cần bổ sung.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhảy thẳng vào Solution. Đây là bệnh kinh điển của người mới, nhất là dân Marketing quen "nghĩ giải pháp" trước. Mẹo: mỗi khi bạn viết một tính năng, tự hỏi "leo lên" hai lần — "phục vụ stakeholder nào?", "phục vụ mục tiêu kinh doanh nào?". Nếu trả lời không trôi chảy, bạn đang nhảy tầng.
Lỗi 2 — Trộn Functional và Non-Functional. Câu "hệ thống cho phép thanh toán nhanh chóng và an toàn" trộn ba thứ. Tách ra: chức năng thanh toán (Functional), tốc độ phản hồi dưới 3 giây (NFR), mã hóa giao dịch (NFR).
Lỗi 3 — Business Requirement không đo được. "Cải thiện trải nghiệm khách hàng" không phải Business Requirement — nó là khẩu hiệu. Phải có con số: tăng NPS từ 30 lên 45, giảm thời gian xử lý từ X xuống Y.
Lỗi 4 — Quên Transition Requirements. Như ví dụ ví điện tử. Mẹo: cuối mỗi buổi phân tích, dành riêng 10 phút chỉ để hỏi "ngày go-live cần chuẩn bị gì cho cái cũ?".
Mẹo tận dụng nền Marketing: Tư duy phân tầng này rất giống mô hình funnel bạn đã quen. Business Requirement giống mục tiêu top-funnel (awareness/doanh số), Stakeholder Requirement giống hành vi của từng phân khúc khách, Solution Requirement giống các điểm chạm cụ thể (landing page, CTA). Bạn đã có sẵn phản xạ tư duy theo tầng — chỉ cần đổi tên gọi.
Bài tập thực hành
Chọn một trong hai đề (hoặc làm cả hai):
Đề A — Phòng gym muốn số hóa. Một chuỗi phòng gym tại Hà Nội muốn giảm tỷ lệ hội viên bỏ tập giữa chừng. Hãy viết ra đầy đủ bốn tầng requirements: 1 Business Requirement (có con số), 3 Stakeholder Requirements (cho hội viên, huấn luyện viên, lễ tân), 4 Solution Requirements (ghi rõ Functional hay Non-Functional), và 1 Transition Requirement.
Đề B — Phân loại ngược. Lấy 6 câu yêu cầu sau và gán mỗi câu vào đúng loại (Business / Stakeholder / Functional / Non-Functional / Transition):
- "Tăng doanh thu từ khách hàng cũ thêm 15% trong năm."
- "Hệ thống phải gửi email xác nhận trong vòng 1 phút sau khi đặt hàng."
- "Nhân viên kho cần in được phiếu xuất hàng theo lô."
- "Toàn bộ dữ liệu đơn hàng 2 năm gần nhất phải được chuyển sang hệ thống mới trước go-live."
- "Hệ thống chịu được 10.000 người dùng đồng thời mà không quá 3 giây phản hồi."
- "Đào tạo 50 nhân viên bán hàng sử dụng app mới."
Tóm tắt
BABOK v3 phân requirements thành bốn loại theo trục từ trừu tượng đến cụ thể: Business (mục tiêu tổ chức, có con số), Stakeholder (nhu cầu của từng nhóm, ngôn ngữ nghiệp vụ), Solution (chia thành Functional — làm gì, và Non-Functional — làm tốt đến đâu), và Transition (chuyển đổi tạm thời từ cũ sang mới). Nguyên tắc xương sống là truy vết: mọi tầng dưới phải gắn lên được tầng trên, không có yêu cầu mồ côi, không có mục tiêu bị bỏ trống. Sai lầm lớn nhất của người mới từ Marketing là nhảy thẳng vào giải pháp mà bỏ qua hai tầng gốc — hãy tập thói quen "leo ngược lên" mỗi khi viết một tính năng. Khi bạn đặt được mọi yêu cầu đúng tầng của nó, tài liệu BA của bạn sẽ thuyết phục được cả Dev lẫn lãnh đạo, và đó là khác biệt giữa người ghi chép yêu cầu với người thực sự phân tích nghiệp vụ.