Mở đầu — vì sao bài này quan trọng
Khi bạn còn làm QA/Tester, "requirement" với bạn thường là một dòng trong test case: "Hệ thống phải cho phép đăng nhập bằng email và mật khẩu". Bạn nhận requirement đó, viết test, chạy test, báo bug nếu nó sai. Bạn là người tiêu thụ requirement.
Khi chuyển sang BA, bạn trở thành người sản xuất requirement. Và đây là chỗ rất nhiều QA-turned-BA vấp ngã trong 3 tháng đầu: họ viết requirement như viết test case — chỉ tập trung vào "hệ thống làm gì", mà quên mất một nửa bức tranh: "hệ thống phải làm điều đó tốt đến mức nào", "vì sao tổ chức cần điều đó", và "ai thực sự cần nó". Đó chính là sự khác biệt giữa Functional và Non-Functional requirements, và rộng hơn là 4 tầng requirement theo BABOK.
Nắm vững taxonomy (phân loại) requirement là kỹ năng nền tảng. Nó giúp bạn không bỏ sót yêu cầu, biết requirement nào đặt ở tài liệu nào, và quan trọng nhất với người từ QA: nó cho bạn một "checklist tư duy" để biến điểm mạnh edge-case của mình thành requirement đầy đủ. Bài này tập trung đúng vào việc phân loại requirement — không đi sâu vào cách viết User Story (Bài 18) hay cách phân tách BRD/FRD/SRS (Bài 20), mà giúp bạn hiểu bản chất các loại yêu cầu để biết mình đang đứng ở đâu.
Khái niệm cốt lõi
Requirement là gì — và taxonomy nghĩa là gì?
Requirement (yêu cầu) là một điều kiện hoặc khả năng mà một bên liên quan (stakeholder) cần để giải quyết một vấn đề hoặc đạt một mục tiêu. Taxonomy requirement là cách phân loại các yêu cầu đó theo "tầng" và theo "loại", để chúng ta quản lý chúng có hệ thống thay vì ném tất cả vào một danh sách lộn xộn.
BABOK v3 (Business Analysis Body of Knowledge — khung kiến thức chuẩn của nghề BA) chia requirement thành 4 tầng. Hãy hình dung như một kim tự tháp, đi từ "vì sao" trừu tượng xuống "làm gì" cụ thể.
Tầng 1 — Business Requirements (Yêu cầu nghiệp vụ)
Đây là 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 công ty bỏ tiền làm việc này?"
Ví dụ: "Giảm 30% tỷ lệ khách hàng bỏ giỏ hàng (cart abandonment) trong 6 tháng tới." Lưu ý: business requirement không nói gì về tính năng cụ thể. Nó là kết quả kinh doanh mong muốn. Một QA mới chuyển sang BA thường nhảy thẳng vào "làm nút gì, màn hình gì" — bỏ qua tầng này. Nhưng nếu bạn không hiểu business requirement, bạn không thể đánh giá một tính năng có đáng làm hay không.
Tầng 2 — Stakeholder Requirements (Yêu cầu các bên liên quan)
Đây là nhu cầu của một nhóm người dùng hoặc bên liên quan cụ thể, đóng vai trò cầu nối giữa mục tiêu tổ chức và giải pháp. Nó trả lời: "Nhóm này cần gì để góp phần đạt mục tiêu chung?"
Ví dụ, với mục tiêu giảm cart abandonment ở trên:
- Nhóm khách hàng: "Tôi cần thanh toán nhanh mà không phải tạo tài khoản."
- Nhóm vận hành kho: "Tôi cần biết đơn hàng được xác nhận ngay để chuẩn bị hàng."
- Nhóm marketing: "Tôi cần gửi email nhắc nhở cho khách bỏ giỏ."
Tầng 3 — Solution Requirements (Yêu cầu giải pháp)
Đây là tầng cụ thể nhất, mô tả khả năng và đặc tính của giải pháp đáp ứng các stakeholder requirement. Đây cũng là tầng mà QA-turned-BA cảm thấy quen thuộc nhất, vì nó gần với những gì bạn từng test. Solution requirement chia làm 2 loại, và đây là phần trung tâm của bài học hôm nay:
a) Functional Requirements (Yêu cầu chức năng) — hệ thống LÀM GÌ
Mô tả hành vi, chức năng cụ thể mà hệ thống phải thực hiện. Đây là những "động từ" của hệ thống.
- "Hệ thống cho phép thanh toán bằng thẻ Visa, MasterCard, và ví Momo."
- "Khi khách bỏ giỏ hàng quá 1 giờ, hệ thống tự động gửi email nhắc nhở."
- "Hệ thống tính phí ship dựa trên trọng lượng và khoảng cách."
b) Non-Functional Requirements — NFR (Yêu cầu phi chức năng) — hệ thống làm điều đó TỐT ĐẾN MỨC NÀO
Mô tả chất lượng, ràng buộc, đặc tính của hệ thống — không phải nó làm gì, mà nó làm như thế nào. Đây là điểm mù lớn nhất của người mới và là nơi tạo ra những sự cố production tệ nhất. Các nhóm NFR phổ biến (có thể nhớ bằng cụm "PRASUM"):
- Performance (Hiệu năng): "Trang thanh toán phải tải xong trong dưới 2 giây với 1.000 người dùng đồng thời."
- Reliability/Availability (Độ tin cậy/Sẵn sàng): "Hệ thống đạt uptime 99,9% (downtime tối đa ~8,76 giờ/năm)."
- Security (Bảo mật): "Dữ liệu thẻ phải tuân thủ chuẩn PCI-DSS; mật khẩu mã hóa bằng bcrypt."
- Usability (Khả dụng): "Người dùng hoàn tất thanh toán trong tối đa 3 bước."
- Scalability (Khả năng mở rộng): "Hệ thống chịu được lưu lượng tăng gấp 10 lần trong dịp sale 12.12."
- Maintainability/Compatibility (Bảo trì/Tương thích): "Chạy được trên Chrome, Safari, và trình duyệt mặc định Android 10+."
Tầng 4 — Transition Requirements (Yêu cầu chuyển tiếp)
Đây là tầng dễ bị quên nhất và rất thú vị: nó mô tả những khả năng cần thiết để chuyển từ trạng thái hiện tại sang trạng thái mới, và nó chỉ tồn tại tạm thời — khi đã chuyển xong, nó biến mất.
Ví dụ: "Di chuyển (migrate) 500.000 hồ sơ khách hàng từ hệ thống cũ sang hệ thống mới, đảm bảo không mất dữ liệu." Hoặc: "Đào tạo 200 nhân viên call center sử dụng giao diện mới trước ngày go-live." Hay: "Chạy song song (parallel run) hệ thống cũ và mới trong 2 tuần để đối chiếu."
Transition requirement không phải đặc tính của sản phẩm cuối — nó là cây cầu để đi tới đó. QA thường không tiếp xúc nhiều với tầng này, nên đây là vùng kiến thức mới bạn cần chủ động học.
Tình huống thực tế
Tình huống 1 — Sàn TMĐT "ShopViet" và cú sập ngày 11.11
ShopViet (giả định) là một sàn thương mại điện tử tầm trung. BA mới của họ — anh Tuấn, vừa chuyển từ vị trí QA Lead — nhận yêu cầu xây tính năng "Flash Sale". Anh viết requirement rất kỹ về mặt functional: hệ thống hiển thị bộ đếm ngược, giới hạn số lượng, áp giá khuyến mãi, chặn mua quá số lượng tồn kho. Mọi test case anh thiết kế đều pass. Đội dev triển khai đúng.
Đến 0h ngày 11.11, 80.000 người dùng đổ vào cùng lúc. Hệ thống sập trong 4 phút. Lý do: không ai viết NFR về performance và scalability. Functional thì hoàn hảo, nhưng "hệ thống phải chịu được bao nhiêu người dùng đồng thời" thì không có trong tài liệu, nên đội infrastructure không chuẩn bị server.
Bài học: Functional đúng nhưng thiếu NFR thì sản phẩm vẫn thất bại — và thất bại theo cách thảm khốc nhất, đúng vào lúc đông khách nhất. Là người từ QA, bạn quen test "tính năng có chạy không", giờ phải tập thói quen hỏi thêm: "chạy được với bao nhiêu tải, nhanh đến mức nào, an toàn ra sao?". Mỗi functional requirement nên có một câu hỏi NFR đi kèm.
Tình huống 2 — Ngân hàng số và 4 tầng requirement bị nhầm lẫn
Một ngân hàng tại TP.HCM triển khai tính năng "mở tài khoản online bằng eKYC" (xác thực danh tính điện tử). Chị Hà — BA từ nền QA banking — được giao viết tài liệu. Ban đầu chị viết tất cả thành một danh sách phẳng 60 dòng "hệ thống phải...". Trưởng nhóm yêu cầu chị phân tầng lại theo BABOK:
- Business: "Tăng 25% lượng tài khoản mở mới trong năm, giảm chi phí mở tài khoản tại quầy."
- Stakeholder: Khách hàng cần "mở tài khoản trong 5 phút không cần đến chi nhánh"; bộ phận compliance cần "lưu bằng chứng định danh đủ pháp lý theo quy định NHNN".
- Solution — Functional: "Hệ thống chụp ảnh CCCD, đối chiếu khuôn mặt với ảnh trên giấy tờ, kiểm tra tính hợp lệ của CCCD."
- Solution — NFR: "Quá trình eKYC hoàn tất dưới 30 giây; dữ liệu sinh trắc học được mã hóa AES-256; đạt độ chính xác nhận diện khuôn mặt ≥ 99%."
- Transition: "Di chuyển dữ liệu định danh của 1,2 triệu khách hàng hiện hữu sang định dạng mới; đào tạo nhân viên xử lý hồ sơ bị từ chối tự động."
Bài học: Phân tầng không phải bài tập hình thức — nó là công cụ phát hiện lỗ hổng. Khi mỗi business requirement không truy vết được xuống stakeholder → solution, bạn biết có thứ gì đó đang thiếu. Đây gọi là traceability (khả năng truy vết) — một khái niệm QA vốn rất quen qua traceability matrix giữa requirement và test case.
Tình huống 3 — Startup edtech bỏ quên transition requirement
Một startup edtech ở Đà Nẵng chuyển từ nền tảng học cũ (tự xây) sang một LMS mới. BA tập trung toàn bộ vào functional và NFR của nền tảng mới: bài giảng video, quiz, theo dõi tiến độ, tải nhanh, bảo mật tốt. Ngày go-live, hệ thống mới chạy mượt — nhưng 12.000 học viên đang học dở các khóa cũ bị mất toàn bộ tiến độ học tập, vì không ai viết transition requirement về việc migrate dữ liệu tiến độ học.
Kết quả: làn sóng phàn nàn, một số học viên đòi hoàn tiền. Đội phải gấp rút viết script đối chiếu dữ liệu trong 2 ngày căng thẳng.
Bài học: Transition requirement là tầng "vô hình" nhất nhưng có thể gây thiệt hại lớn nhất. Khi làm bất kỳ dự án nào thay thế/nâng cấp hệ thống cũ, luôn tự hỏi: "Dữ liệu cũ đi đâu? Người dùng cũ chuyển sang thế nào? Có cần chạy song song không?".
Hướng dẫn từng bước
Đây là quy trình thực hành để phân loại requirement cho một tính năng bất kỳ:
Bước 1 — Bắt đầu từ business requirement. Trước khi viết bất cứ thứ gì về tính năng, hãy hỏi: "Tổ chức muốn đạt được gì? Đo bằng con số nào?". Nếu không trả lời được, hãy quay lại hỏi stakeholder. Đây là điều QA hiếm khi phải làm nhưng BA bắt buộc.
Bước 2 — Xác định các nhóm stakeholder và nhu cầu của họ. Liệt kê mọi nhóm bị ảnh hưởng (người dùng cuối, vận hành, compliance, support, marketing...). Với mỗi nhóm, viết nhu cầu dưới góc nhìn của họ. Tận dụng tư duy "ai sẽ dùng cái này theo cách khác thường" của QA.
Bước 3 — Dịch nhu cầu thành functional requirement. Với mỗi nhu cầu, hỏi "hệ thống phải làm gì để đáp ứng?". Viết bằng động từ rõ ràng, có thể kiểm chứng (testable) — kỹ năng cốt lõi bạn mang từ QA sang.
Bước 4 — Với MỖI functional requirement, hỏi 6 câu NFR. Đây là thói quen quan trọng nhất cần xây dựng. Với mỗi chức năng, tự hỏi: Nhanh đến mức nào (performance)? Bao nhiêu người dùng đồng thời (scalability)? Cần sẵn sàng bao nhiêu phần trăm thời gian (availability)? Bảo mật ra sao (security)? Người dùng có dễ dùng không (usability)? Chạy trên nền tảng/trình duyệt nào (compatibility)?
Bước 5 — Rà soát transition requirement. Hỏi: dự án này có thay thế cái gì cũ không? Có dữ liệu cần migrate? Người dùng/nhân viên có cần đào tạo? Có cần go-live theo từng giai đoạn?
Bước 6 — Kiểm tra traceability. Vẽ một bảng đơn giản: mỗi business requirement liên kết tới stakeholder requirement nào, mỗi stakeholder requirement liên kết tới solution requirement nào. Nếu có dòng nào "đứt", bạn đã tìm thấy một lỗ hổng.
Lỗi thường gặp & mẹo
Lỗi 1 — Chỉ viết functional, quên NFR. Đây là lỗi số 1 của QA-turned-BA. Mẹo: dán một sticky note "PRASUM" (Performance, Reliability, Availability, Security, Usability, Maintainability) lên màn hình, kiểm mỗi tính năng qua 6 lăng kính này.
Lỗi 2 — Viết NFR mơ hồ, không đo được. "Hệ thống phải nhanh" là vô dụng. Phải là "tải dưới 2 giây với 1.000 user đồng thời". Một NFR không có con số thì không thể test, không thể nghiệm thu. May mắn là tư duy "phải verify được" của QA giúp bạn tránh lỗi này tự nhiên.
Lỗi 3 — Nhầm lẫn functional và NFR. "Hệ thống mã hóa mật khẩu" — đây là functional hay NFR? Mẹo: bản thân việc "mã hóa khi lưu" là functional (một hành vi); nhưng "mã hóa bằng chuẩn bcrypt cost 12" là NFR (đặc tính chất lượng). Đừng quá ám ảnh ranh giới — quan trọng là đừng bỏ sót cả hai mặt.
Lỗi 4 — Trộn lẫn các tầng vào một danh sách phẳng. Business goal nằm chung với chi tiết nút bấm khiến tài liệu rối và khó truy vết. Luôn gắn nhãn tầng cho mỗi requirement.
Lỗi 5 — Bỏ quên transition requirement hoàn toàn. Như tình huống 3. Mẹo: với mọi dự án "thay thế/nâng cấp", mặc định thêm một mục "Migration & Transition" vào tài liệu.
Mẹo vàng cho người từ QA: Điểm mạnh edge-case của bạn chính là vũ khí phát hiện NFR. Khi bạn từng nghĩ "điều gì xảy ra nếu 10.000 người bấm cùng lúc?", "nếu mạng chậm thì sao?", "nếu nhập sai 100 lần thì sao?" — đó chính xác là tư duy sinh ra NFR. Hãy biến phản xạ test thành phản xạ viết requirement.
Bài tập thực hành
Chọn một tính năng quen thuộc: "Đặt xe trên ứng dụng gọi xe (như Grab/Be)". Hãy hoàn thành bài tập sau:
- Viết 1 business requirement (có con số đo lường) cho việc cải thiện tính năng đặt xe.
- Liệt kê 3 nhóm stakeholder và nhu cầu của mỗi nhóm (gợi ý: khách hàng, tài xế, đội vận hành).
- Viết 4 functional requirement cho tính năng đặt xe.
- Với mỗi functional requirement ở bước 3, viết ít nhất 1 NFR có con số cụ thể (tổng cộng ≥ 4 NFR, phủ ít nhất 3 nhóm PRASUM khác nhau).
- Viết 2 transition requirement giả định công ty đang chuyển từ app cũ sang app mới.
- Vẽ một bảng traceability nhỏ nối business → stakeholder → solution requirement, và chỉ ra liệu có dòng nào "đứt mạch" không.
Tóm tắt
- Requirement được phân theo 4 tầng BABOK: Business (mục tiêu tổ chức) → Stakeholder (nhu cầu nhóm) → Solution (Functional + Non-Functional) → Transition (chuyển tiếp tạm thời).
- Functional = hệ thống làm gì; Non-Functional (NFR) = hệ thống làm điều đó tốt đến mức nào (PRASUM: Performance, Reliability/Availability, Security, Usability, Scalability, Maintainability).
- Lỗi chí mạng của QA-turned-BA là chỉ viết functional và quên NFR — đúng phần gây sập production như tình huống ShopViet.
- Transition requirement là tầng dễ quên nhất nhưng thiệt hại lớn nhất khi thay thế hệ thống cũ (migrate dữ liệu, đào tạo, chạy song song).
- NFR phải đo được bằng con số, nếu không thì vô dụng — và đây là nơi tư duy "verify được" của QA phát huy.
- Traceability giữa các tầng là công cụ phát hiện lỗ hổng: mỗi business requirement phải truy vết xuống được tới solution.
- Vũ khí lớn nhất của bạn khi chuyển nghề: biến phản xạ tìm edge-case của QA thành phản xạ viết NFR đầy đủ cho mỗi chức năng.