Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa nhận yêu cầu từ sếp: "Làm cho website bán hàng nhanh hơn." Câu này nghe có vẻ rõ ràng, nhưng thực ra nó đang trộn lẫn ít nhất ba tầng yêu cầu khác nhau: kinh doanh muốn giữ chân khách (giảm tỷ lệ rời trang), người dùng muốn trang load dưới 2 giây, và đội kỹ thuật cần biết phải tối ưu database query hay CDN. Nếu bạn — với vai trò BA — không tách bạch được ba tầng này, bạn sẽ viết tài liệu mơ hồ, dev hiểu sai, và dự án trễ hạn.
Đây chính là lý do bài học hôm nay quan trọng. Phân loại requirements không phải là chuyện học thuật để thi chứng chỉ. Nó là bộ lọc tư duy giúp bạn biết: yêu cầu này thuộc về ai, ai chịu trách nhiệm trả lời, viết nó ở đâu, và đo lường thành công bằng cách nào. Theo chuẩn BABOK (Business Analysis Body of Knowledge — cuốn "kinh thánh" của nghề BA do IIBA xuất bản), có một hệ thống phân loại rõ ràng. Khi bạn nắm vững nó, mọi cuộc trao đổi với stakeholder sẽ mạch lạc hơn, và tài liệu của bạn sẽ trở thành thứ mà cả business lẫn dev đều tin tưởng.
Ở bài trước, chúng ta đã hiểu Business Analysis là gì. Bài này sẽ trả lời câu hỏi tiếp theo: BA thu thập và quản lý cái gì? Câu trả lời là requirements — và chúng có nhiều loại.
Khái niệm cốt lõi
Theo BABOK, requirements được chia thành bốn loại chính, sắp xếp theo một trục từ "trừu tượng, cấp cao" đến "cụ thể, kỹ thuật". Ngoài ra còn có một nhóm đặc biệt là Transition Requirements. Hãy đi qua từng loại.
1. Business Requirements (BR) — Yêu cầu nghiệp vụ
Đây là tầng cao nhất, mô tả mục tiêu, mục đích và kết quả kinh doanh mà tổ chức muốn đạt được. Business Requirements trả lời câu hỏi "Tại sao chúng ta làm dự án này?" Chúng không nói về tính năng cụ thể, mà nói về giá trị.
- Ví dụ: "Tăng doanh thu thương mại điện tử thêm 20% trong Q3", "Giảm chi phí vận hành kho 15% trong năm tài chính 2026", "Mở rộng thị phần sang phân khúc khách hàng dưới 25 tuổi".
- Ai viết/sở hữu: BA cùng với Project Sponsor, ban lãnh đạo (PM, giám đốc khối). Đây là cấp ra quyết định chiến lược.
- Đặc điểm: ít về số lượng, ổn định theo thời gian, và là "ngọn hải đăng" để mọi yêu cầu cấp dưới phải truy ngược về được.
2. Stakeholder Requirements (SR) — Yêu cầu của các bên liên quan
Tầng này mô tả nhu cầu của một nhóm stakeholder cụ thể và những gì họ cần để tương tác với giải pháp. Nó là cầu nối giữa mục tiêu kinh doanh trừu tượng và yêu cầu giải pháp cụ thể.
- Ví dụ: "Nhân viên chăm sóc khách hàng cần xem được toàn bộ lịch sử đơn hàng của một khách trong vòng 3 giây", "Quản lý kho cần nhận cảnh báo khi tồn kho một SKU xuống dưới ngưỡng an toàn".
- Ai viết/sở hữu: BA, dựa trên elicitation (phỏng vấn, workshop) với từng nhóm stakeholder.
- Đặc điểm: gắn với góc nhìn của một vai trò người dùng. Một Business Requirement thường sinh ra nhiều Stakeholder Requirements.
3. Solution Requirements (SOR) — Yêu cầu giải pháp
Đây là tầng mà dev và tester quan tâm nhất, vì nó mô tả đặc tính cụ thể của giải pháp cần được xây dựng. Solution Requirements được chia tiếp thành hai nhánh, và đây là phần mà rất nhiều BA mới hay nhầm lẫn:
a. Functional Requirements (FR) — Yêu cầu chức năng: mô tả hệ thống làm gì — hành vi, chức năng, xử lý dữ liệu. Trả lời câu hỏi "Hệ thống phải thực hiện hành động nào?"
- Ví dụ: "Hệ thống cho phép khách hàng thanh toán bằng ví MoMo, ZaloPay và thẻ Visa/Mastercard", "Khi đơn hàng được tạo, hệ thống gửi email xác nhận trong vòng 60 giây".
- Ví dụ: "Trang sản phẩm phải load dưới 2 giây với 95% request (p95)", "Hệ thống chịu được 10.000 người dùng đồng thời vào ngày sale", "Mật khẩu phải được mã hóa bằng bcrypt", "Hệ thống đạt uptime 99,9%".
4. Transition Requirements (TR) — Yêu cầu chuyển tiếp
Đây là nhóm đặc biệt và thường bị lãng quên nhất. Transition Requirements mô tả những gì cần để chuyển từ trạng thái hiện tại sang trạng thái mới — và chúng chỉ tồn tại tạm thời trong giai đoạn triển khai, sau đó biến mất.
- Ví dụ: "Cần migrate 2 triệu bản ghi khách hàng từ hệ thống cũ sang CRM mới", "Cần đào tạo 50 nhân viên call center sử dụng giao diện mới trong 2 tuần trước go-live", "Cần chạy song song hệ thống cũ và mới trong 1 tháng".
- Đặc điểm: có "tuổi thọ" ngắn, không phải là một phần của giải pháp cuối cùng, nhưng nếu bỏ qua thì go-live sẽ hỗn loạn.
Mối quan hệ phân tầng và Traceability
Bốn loại này không độc lập — chúng tạo thành một chuỗi truy vết (traceability). Business Requirement nằm trên cùng, đẻ ra Stakeholder Requirements, rồi đến Solution Requirements (Functional + Non-functional). Mỗi yêu cầu cấp dưới phải truy ngược lên được một yêu cầu cấp trên. Nếu một Functional Requirement không phục vụ bất kỳ Business Requirement nào, thì có thể nó là tính năng thừa — dấu hiệu của "gold-plating" (mạ vàng, làm thừa). Ngược lại, nếu một Business Requirement không có Functional Requirement nào hỗ trợ, thì mục tiêu kinh doanh đó đang bị bỏ rơi.
Tình huống thực tế
Tình huống 1 — Sàn TMĐT Việt Nam muốn "thanh toán nhanh hơn"
Một công ty thương mại điện tử giả định tên ChợViệt (mô hình tương tự Tiki, Shopee) gặp vấn đề: 68% khách bỏ giỏ hàng ở bước thanh toán. CEO ra yêu cầu cho team BA: "Phải làm thanh toán nhanh hơn."
BA bắt tay phân loại:
- Business Requirement: "Giảm tỷ lệ bỏ giỏ hàng ở bước thanh toán từ 68% xuống dưới 45% trong Q3, qua đó tăng doanh thu chuyển đổi 18%."
- Stakeholder Requirement: "Khách hàng đã đăng nhập cần hoàn tất thanh toán mà không phải nhập lại địa chỉ và phương thức thanh toán đã lưu."
- Functional Requirement: "Hệ thống tự động điền địa chỉ giao hàng mặc định và hiển thị nút thanh toán 1-chạm cho khách đã lưu ví MoMo."
- Non-functional Requirement: "Toàn bộ luồng thanh toán hoàn tất trong tối đa 3 bước và trang xác nhận load dưới 1,5 giây ở p95."
- Transition Requirement: "Migrate dữ liệu phương thức thanh toán đã lưu của 500.000 khách hiện hữu sang cấu trúc token mới trước go-live."
Tình huống 2 — Ngân hàng số bỏ quên Non-functional Requirements
Một ngân hàng tại TP.HCM (gọi là NganHangSo) ra mắt app chuyển tiền mới. Team BA viết rất kỹ các Functional Requirements: chuyển tiền nội bộ, chuyển liên ngân hàng qua Napas, quét QR VietQR, lịch sử giao dịch. Demo nội bộ chạy mượt, mọi người hài lòng.
Đến ngày ra mắt trùng dịp lương cuối tháng, 40.000 người dùng đổ vào cùng lúc. App treo, giao dịch timeout, một số khách bị trừ tiền hai lần. Nguyên nhân: BA không viết Non-functional Requirement về tải đồng thời và tính nhất quán giao dịch (idempotency). Không ai test "chịu tải 40.000 user" vì yêu cầu đó chưa từng tồn tại trên giấy.
Bài học: Functional Requirements trả lời "hệ thống làm được gì", nhưng chính Non-functional Requirements mới quyết định "hệ thống có sống sót ngoài thực địa không". NFR phải có con số cụ thể (số user đồng thời, thời gian phản hồi, ngưỡng uptime) thì mới test được. "Hệ thống phải nhanh" là một NFR vô dụng; "p95 dưới 2 giây với 10.000 user đồng thời" mới là một NFR đúng nghĩa.
Tình huống 3 — Dự án ERP và Transition Requirements bị lãng quên
Một nhà sản xuất đồ gỗ xuất khẩu ở Bình Dương triển khai hệ thống ERP mới thay cho phần mềm kế toán cũ. Functional và Non-functional Requirements được làm rất bài bản trong 4 tháng. Nhưng vào tuần go-live, công ty rơi vào khủng hoảng: dữ liệu tồn kho và công nợ của 8 năm trong hệ thống cũ không khớp định dạng mới, và 30 nhân viên kế toán chưa từng được đào tạo, không biết nhập liệu ở đâu.
Lý do: BA đã bỏ qua hoàn toàn Transition Requirements — không lên kế hoạch migrate dữ liệu, không có yêu cầu đào tạo, không có giai đoạn chạy song song. Kết quả: go-live bị hoãn 6 tuần, công ty phải làm thủ công bằng Excel trong thời gian đó.
Bài học: Transition Requirements là loại "tạm thời" nên dễ bị xem nhẹ, nhưng bỏ qua chúng đồng nghĩa với việc giải pháp dù hoàn hảo cũng không thể đưa vào vận hành. Hãy luôn hỏi: "Để đi từ hệ thống cũ sang hệ thống mới, chúng ta cần migrate gì, đào tạo ai, và chuyển đổi như thế nào?"
Hướng dẫn từng bước
Khi đứng trước một mớ yêu cầu hỗn độn từ stakeholder, hãy phân loại theo quy trình sau:
- Gom toàn bộ yêu cầu thô. Ghi lại mọi câu nói, mong muốn, phàn nàn từ các buổi elicitation mà chưa vội đánh giá.
- Hỏi "Tại sao?" để tìm Business Requirement. Với mỗi yêu cầu, truy ngược: nó phục vụ mục tiêu kinh doanh nào? Nếu không truy được, đánh dấu nghi vấn — có thể là tính năng thừa.
- Hỏi "Ai cần và để làm gì?" để xác định Stakeholder Requirement. Gắn yêu cầu với một vai trò người dùng cụ thể.
- Tách Functional và Non-functional. Đặt câu hỏi: "Đây là hệ thống làm gì (động từ → FR) hay hệ thống làm tốt cỡ nào (tính chất → NFR)?" Với mỗi FR quan trọng, chủ động hỏi thêm về hiệu năng, bảo mật, tải để moi ra NFR ẩn.
- Định lượng mọi NFR. Không chấp nhận "nhanh", "an toàn", "ổn định". Ép stakeholder cho con số: bao nhiêu giây, bao nhiêu user, bao nhiêu phần trăm uptime.
- Đừng quên hỏi về chuyển tiếp. Trước mỗi go-live, hỏi: "Cần migrate dữ liệu gì? Cần đào tạo ai? Có cần chạy song song không?" → đó là Transition Requirements.
- Lập bảng traceability đơn giản. Một bảng nối BR → SR → FR/NFR. Bảng này sẽ là vũ khí giúp bạn phát hiện yêu cầu thừa và yêu cầu thiếu.
Lỗi thường gặp & mẹo
- Lỗi: Trộn lẫn Business Requirement với Solution Requirement. Viết "Hệ thống cần nút thanh toán MoMo" làm mục tiêu kinh doanh là sai — đó là giải pháp, không phải mục tiêu. Mục tiêu là "tăng tỷ lệ chuyển đổi". Mẹo: Business Requirement không bao giờ nhắc đến tính năng cụ thể.
- Lỗi: Bỏ quên Non-functional Requirements. Đây là lỗi nguy hiểm nhất (xem Tình huống 2). Mẹo: với mỗi tính năng quan trọng, luôn chủ động hỏi bốn câu — Nhanh cỡ nào? An toàn ra sao? Chịu được bao nhiêu user? Uptime bao nhiêu?
- Lỗi: Viết NFR mơ hồ không đo được. "Hệ thống phải thân thiện" là vô nghĩa với QA. Mẹo: mọi NFR phải có con số và phương pháp đo. Áp dụng tiêu chí SMART.
- Lỗi: Quên Transition Requirements cho đến phút chót. Mẹo: đưa câu hỏi migrate dữ liệu và đào tạo vào checklist ngay từ giai đoạn đầu, đừng để sát go-live.
- Lỗi: Phân loại theo cảm tính, không có traceability. Mẹo: luôn truy ngược mỗi yêu cầu lên một Business Requirement. Cái nào không truy được thì hoặc là thừa, hoặc là bạn đang thiếu một Business Requirement chưa được nói ra.
- Mẹo phân biệt FR/NFR nhanh: thử viết câu "Hệ thống [động từ] [tân ngữ]" → nếu khớp tự nhiên thì là FR. Còn nếu yêu cầu trả lời câu hỏi "tốt như thế nào / nhanh ra sao / an toàn cỡ nào" thì là NFR.
Bài tập thực hành
Một chuỗi cửa hàng cà phê (giả định tên CàPhêViệt, 80 chi nhánh) muốn xây app đặt món và tích điểm. Dưới đây là các yêu cầu thô thu thập được. Hãy phân loại từng yêu cầu vào đúng nhóm: Business Requirement (BR), Stakeholder Requirement (SR), Functional Requirement (FR), Non-functional Requirement (NFR), hoặc Transition Requirement (TR).
- "Tăng số khách quay lại trong vòng 30 ngày thêm 25% trong năm 2026."
- "Khách hàng cần đặt món trước và đến lấy không phải xếp hàng."
- "App cho phép thanh toán bằng MoMo và tích điểm tự động sau mỗi đơn."
- "App phải mở lên và sẵn sàng nhận đơn trong vòng 2 giây trên điện thoại tầm trung."
- "Cần chuyển dữ liệu 120.000 thành viên thẻ tích điểm giấy hiện tại sang app."
- "Nhân viên quầy cần xem danh sách đơn đặt trước theo thời gian để chuẩn bị."
- "Hệ thống phải đạt uptime 99,5% trong giờ cao điểm 7h–9h sáng."
- "Cần đào tạo nhân viên 80 chi nhánh dùng màn hình nhận đơn mới trước khi ra mắt."
Tóm tắt
Phân loại requirements là kỹ năng nền tảng giúp BA biến những câu nói mơ hồ thành tài liệu có thể giao việc và đo lường. Hãy ghi nhớ năm loại theo chuẩn BABOK:
- Business Requirements — mục tiêu kinh doanh cấp cao, trả lời "Tại sao?". Do BA và lãnh đạo sở hữu.
- Stakeholder Requirements — nhu cầu của từng nhóm người dùng cụ thể, cầu nối giữa mục tiêu và giải pháp.
- Solution Requirements — gồm Functional (hệ thống làm gì, động từ) và Non-functional (hệ thống làm tốt cỡ nào, tính chất, phải có con số).
- Transition Requirements — những gì cần để chuyển từ cũ sang mới (migrate, đào tạo, chạy song song); tạm thời nhưng sống còn.