Mở đầu — vì sao bài này quan trọng
Khi bạn còn là developer, mọi yêu cầu đến tay bạn thường đã được "đóng gói" sẵn: một ticket trên Jira, một dòng acceptance criteria, hoặc một câu nói của leader "làm cái nút này gọi API kia". Bạn nhận yêu cầu, không sản xuất yêu cầu. Bước sang vai trò BA, bạn đứng ở đầu nguồn của dòng chảy đó. Và đây là chỗ rất nhiều dev-turned-BA vấp ngã: họ phân loại yêu cầu theo thói quen kỹ thuật — "cái này thuộc backend, cái kia thuộc frontend" — thay vì theo cách mà nghiệp vụ và kiến trúc giải pháp cần.
Phân loại yêu cầu (requirements types) không phải là bài tập hàn lâm để vượt qua phỏng vấn. Nó là bộ khung giúp bạn không bỏ sót. Khi một dự án ngân hàng đổ vỡ ở khâu go-live vì hệ thống "chạy đúng nhưng chậm 8 giây mỗi giao dịch", đó không phải lỗi chức năng — đó là một non-functional requirement bị bỏ quên ngay từ đầu. Một BA giỏi phân loại yêu cầu tốt sẽ phát hiện lỗ hổng này từ workshop đầu tiên, trước khi một dòng code được viết.
Bài này tập trung vào việc trả lời ba câu hỏi: Có những tầng yêu cầu nào theo chuẩn BABOK? Functional và Non-Functional khác nhau ra sao và vì sao dev hay nhầm? Và làm thế nào để bạn — người có nền kỹ thuật — biến lợi thế hiểu hệ thống thành khả năng đặc tả yêu cầu đầy đủ, không thừa không thiếu.
Khái niệm cốt lõi
Bốn tầng yêu cầu theo BABOK
BABOK v3 (Business Analysis Body of Knowledge) tổ chức yêu cầu thành một kim tự tháp bốn tầng. Hiểu được tầng nào là gì giúp bạn biết mình đang nói chuyện với ai và đang giải quyết vấn đề ở cấp độ nào.
Tầng 1 — Business Requirements (Yêu cầu nghiệp vụ). Đây là mục tiêu ở cấp tổ chức, trả lời câu hỏi "Vì sao chúng ta làm dự án này?". Ví dụ: "Giảm thời gian onboard khách hàng mới từ 5 ngày xuống còn 2 ngày" hoặc "Tăng tỷ lệ chuyển đổi giỏ hàng từ 2% lên 3,5% trong quý tới". Lưu ý: ở tầng này tuyệt đối không có chữ "button", "API" hay "database". Nó là ngôn ngữ của ban lãnh đạo, gắn với KPI và doanh thu.
Tầng 2 — Stakeholder Requirements (Yêu cầu của các bên liên quan). Đây là nhu cầu của từng nhóm người dùng/phòng ban cụ thể, là cầu nối giữa mục tiêu tổ chức và giải pháp. Ví dụ: "Nhân viên tín dụng cần xem được lịch sử tín dụng của khách hàng ngay trên một màn hình thay vì mở ba hệ thống". Mỗi stakeholder nhìn vấn đề từ góc của họ, và công việc của BA là tổng hợp, dung hòa các góc nhìn này.
Tầng 3 — Solution Requirements (Yêu cầu giải pháp). Đây là tầng chi tiết nhất, mô tả giải pháp phải làm gì và làm tốt đến mức nào. Chính tầng này được chia làm hai loại: Functional và Non-Functional. Đây là tầng mà bạn — dev-turned-BA — sẽ dành phần lớn thời gian.
Tầng 4 — Transition Requirements (Yêu cầu chuyển đổi). Đây là loại yêu cầu chỉ tồn tại tạm thời trong giai đoạn chuyển từ hệ thống cũ sang mới: di chuyển dữ liệu (data migration), đào tạo người dùng, chạy song song hai hệ thống một tháng. Sau khi go-live ổn định thì chúng biến mất. Dev rất hay quên tầng này vì nó không nằm trong sản phẩm cuối, nhưng nó quyết định dự án có triển khai trơn tru hay không.
Functional Requirements — Hệ thống PHẢI LÀM GÌ
Functional Requirements (FR — yêu cầu chức năng) mô tả hành vi cụ thể: với một đầu vào, hệ thống phải tạo ra đầu ra nào, theo quy tắc nào. Cách dễ nhớ nhất: FR luôn có thể viết được dưới dạng "Khi [điều kiện], hệ thống phải [hành động]".
Ví dụ FR cho tính năng đăng nhập:
- Hệ thống phải cho phép người dùng đăng nhập bằng số điện thoại và mật khẩu.
- Khi người dùng nhập sai mật khẩu 5 lần liên tiếp, hệ thống phải khóa tài khoản trong 15 phút.
- Hệ thống phải gửi mã OTP qua SMS khi người dùng chọn đăng nhập bằng OTP.
Non-Functional Requirements — Hệ thống phải TỐT đến mức nào
Non-Functional Requirements (NFR — yêu cầu phi chức năng) không mô tả hệ thống làm gì, mà mô tả hệ thống làm việc đó tốt đến mức nào — về tốc độ, độ tin cậy, bảo mật, khả năng mở rộng. NFR thường được gọi là "the -ilities": usability, reliability, scalability, maintainability, security, portability.
Một cách phân nhóm NFR thực dụng theo các tiêu chí phổ biến nhất:
- Performance (Hiệu năng): Thời gian phản hồi của API thanh toán phải dưới 2 giây ở 95% số lần gọi (P95).
- Scalability (Khả năng mở rộng): Hệ thống phải xử lý được 10.000 người dùng đồng thời vào giờ cao điểm sale.
- Availability (Độ sẵn sàng): Hệ thống phải đạt uptime 99,9% mỗi tháng (tương đương downtime tối đa khoảng 43 phút).
- Security (Bảo mật): Mọi mật khẩu phải được hash bằng bcrypt; dữ liệu thẻ phải tuân thủ PCI-DSS.
- Usability (Khả dụng): Người dùng mới phải hoàn tất đăng ký trong tối đa 3 màn hình.
- Maintainability (Khả năng bảo trì): Hệ thống phải ghi log mọi giao dịch lỗi để truy vết trong vòng 90 ngày.
Vì sao dev hay nhầm lẫn FR và NFR
Lý do phổ biến nhất: dev quen nghĩ theo "module" chứ không theo "loại yêu cầu". Khi nghe "tính năng tìm kiếm", dev nghĩ ngay tới một chức năng (FR). Nhưng "kết quả tìm kiếm phải trả về trong 1 giây dù có 5 triệu sản phẩm" lại là NFR ẩn bên trong cùng tính năng đó. Cùng một tính năng luôn có cả hai mặt: nó làm gì, và nó làm tốt đến đâu. Bỏ một trong hai là bỏ sót.
Tình huống thực tế
Ví dụ 1 — Sàn TMĐT Việt Nam và cú sập ngày sale 11/11
Một công ty TMĐT giả định tên ShopViet đang xây tính năng "flash sale". BA mới chuyển từ dev viết FR rất tốt: hệ thống hiển thị đồng hồ đếm ngược, người dùng thêm sản phẩm sale vào giỏ, giới hạn mỗi tài khoản mua tối đa 2 sản phẩm, hết số lượng thì khóa nút mua. Tất cả đều đúng và đầy đủ về mặt chức năng.
Đến ngày 11/11, lúc 0 giờ, 50.000 người vào cùng lúc. Hệ thống treo 4 phút, giỏ hàng báo lỗi, có người mua được 5 sản phẩm dù giới hạn là 2 vì race condition khi tải cao. Doanh thu giờ vàng bốc hơi.
Vấn đề ở đâu? Tất cả FR đều đã được kiểm thử và pass — nhưng trong môi trường 100 người dùng test, không phải 50.000 người dùng thật. BA đã quên hoàn toàn lớp NFR: không có yêu cầu nào về "hệ thống phải chịu được 50.000 concurrent user", không có yêu cầu về tính nhất quán dữ liệu tồn kho dưới tải cao (consistency under load).
Bài học: Là dev, bạn thừa biết race condition và concurrency là gì. Đừng để kiến thức đó ngủ quên khi bạn ngồi ghế BA. Mỗi khi viết một FR có yếu tố "giới hạn", "đồng thời", "tồn kho", hãy tự hỏi: NFR đi kèm là gì? Con số tải đỉnh dự kiến là bao nhiêu? Chính câu hỏi này là thứ phân biệt một technical BA với một BA bình thường.
Ví dụ 2 — App ngân hàng số và yêu cầu nghiệp vụ bị nhảy cóc
Tại một ngân hàng số ở TP.HCM, ban lãnh đạo nêu Business Requirement rõ ràng: "Giảm thời gian mở tài khoản từ 30 phút tại quầy xuống dưới 5 phút trên app". BA là một cựu backend dev. Vì quá quen với việc nghĩ giải pháp, anh nhảy thẳng từ business requirement xuống solution requirement, viết một loạt FR về form nhập liệu, OCR chụp CCCD, gọi API định danh.
Anh bỏ qua tầng Stakeholder Requirements. Hậu quả: anh không phỏng vấn bộ phận compliance (tuân thủ). Khi demo, phòng pháp chế phát hiện luồng eKYC thiếu bước xác thực khuôn mặt theo quy định của Ngân hàng Nhà nước, và thiếu lưu trữ bằng chứng định danh theo yêu cầu PDPD. Toàn bộ luồng phải làm lại, trễ ba tuần.
Bài học: Bốn tầng yêu cầu không phải để trang trí. Khi bạn bỏ qua một tầng, bạn đang đánh cược rằng tầng đó không có yêu cầu ẩn nào — một canh bạc rất dễ thua trong domain ngân hàng. Stakeholder Requirements chính là nơi compliance, pháp chế, vận hành "gửi gắm" những ràbuộc mà ban lãnh đạo không bao giờ nói ra ở tầng business. Với dev, cám dỗ "nhảy thẳng tới giải pháp" cực mạnh — bài 32 sẽ nói sâu về cái bẫy này, nhưng ngay từ đây bạn cần kỷ luật đi đủ từng tầng.
Ví dụ 3 — Startup edtech và NFR mơ hồ "phải mượt"
Một startup edtech ở Hà Nội xây tính năng học video tương tác. Founder nói với BA: "Tôi muốn video phải mượt, học sinh không bị giật". BA ghi nguyên văn câu đó vào tài liệu như một yêu cầu.
Đến sprint review, đội dev hỏi: "Mượt là bao nhiêu? Mạng 3G ở vùng quê cũng phải mượt à? Buffer bao lâu thì gọi là giật?". Không ai trả lời được. Tính năng được làm theo phán đoán của dev, test trên wifi văn phòng thì ổn, nhưng học sinh ở tỉnh dùng 4G yếu thì video đứng liên tục.
BA quay lại và viết lại NFR cho đo được: "Video phải bắt đầu phát trong vòng 3 giây trên kết nối 4G tối thiểu 2 Mbps; tự động hạ chất lượng xuống 360p khi băng thông dưới 1 Mbps; thời gian buffer giữa chừng không quá 2 lần trong một video 10 phút". Lúc này dev mới có thứ để xây và để test.
Bài học: NFR không đo được thì vô dụng. Nhiệm vụ của BA là chuyển ngôn ngữ cảm tính của founder ("mượt") thành ngưỡng số đo được. Nền dev giúp bạn biết phải hỏi về băng thông, codec, độ trễ — hãy dùng nó để "thẩm vấn" mọi tính từ mơ hồ cho đến khi nó thành con số.
Hướng dẫn từng bước
Đây là quy trình thực dụng để phân loại và viết yêu cầu đầy đủ cho một tính năng:
- Xác định Business Requirement gốc. Trước mọi thứ, viết một câu trả lời cho "Tính năng này phục vụ mục tiêu kinh doanh nào?". Nếu không trả lời được, bạn chưa đủ thông tin để bắt đầu.
- Liệt kê stakeholders và nhu cầu của họ. Hỏi: ai dùng tính năng này? Ai bị ảnh hưởng? Đặc biệt đừng quên các bên "vô hình" như compliance, bảo mật, vận hành, chăm sóc khách hàng.
- Viết Functional Requirements. Với mỗi nhu cầu stakeholder, mô tả hệ thống phải làm gì theo mẫu "Khi [điều kiện], hệ thống phải [hành động]". Giữ ở mức nghiệp vụ, tránh chi tiết implementation.
- Soi từng FR để rút ra NFR ẩn. Với mỗi FR, chạy qua checklist các "-ilities": tính năng này cần nhanh đến đâu (performance)? chịu tải bao nhiêu (scalability)? cần bảo mật gì (security)? phải sẵn sàng bao nhiêu phần trăm thời gian (availability)? Mỗi câu trả lời phải là một con số.
- Xác định Transition Requirements. Hỏi: để go-live tính năng này, có cần migrate dữ liệu cũ không? cần đào tạo ai không? cần chạy song song không?
- Gắn tiêu chí đo được (measurable) cho mọi NFR. Quét lại tài liệu, gạch chân mọi tính từ mơ hồ: "nhanh", "mượt", "an toàn", "dễ dùng". Mỗi từ đó phải được thay bằng một ngưỡng số. Đây là bước quan trọng nhất.
- Rà soát chéo bằng câu hỏi "còn thiếu loại nào?". Đối chiếu với bốn tầng và hai loại FR/NFR để chắc chắn không bỏ trống ô nào.
Lỗi thường gặp & mẹo
Lỗi 1 — Viết NFR không đo được. "Hệ thống phải nhanh và ổn định" là câu vô giá trị. Mẹo: áp dụng quy tắc "nếu không gắn được con số hoặc đơn vị, đó chưa phải yêu cầu". Mỗi NFR phải có dạng [chỉ số] [toán tử] [ngưỡng] [điều kiện], ví dụ "thời gian phản hồi < 2 giây ở P95 dưới tải 1.000 rps".
Lỗi 2 — Trộn implementation vào FR. Vì là dev, bạn dễ viết "lưu vào bảng X, gọi service Y". Mẹo: tự hỏi "câu này có còn đúng nếu đội dev đổi sang công nghệ khác không?". Nếu đổi DB mà yêu cầu phải viết lại, thì bạn đang viết design chứ không phải requirement.
Lỗi 3 — Bỏ quên NFR hoàn toàn. Đây là lỗi tốn kém nhất, vì NFR thường chỉ lộ ra khi go-live dưới tải thật. Mẹo: với mỗi tính năng, bắt buộc chạy qua checklist "-ilities" trước khi đóng tài liệu, dù bạn nghĩ tính năng "đơn giản".
Lỗi 4 — Nhảy cóc qua các tầng. Dev quen nhảy thẳng tới giải pháp. Mẹo: luôn viết business requirement và stakeholder requirement trước, dù chỉ một dòng, để buộc bản thân dừng lại trước khi lao vào solution.
Lỗi 5 — Coi NFR là việc của ông kiến trúc sư. Nhiều BA đẩy hết NFR cho solution architect. Mẹo: BA chịu trách nhiệm phát hiện và ghi nhận NFR; architect chịu trách nhiệm giải pháp đáp ứng nó. Bạn không cần biết cách đạt 99,99% uptime, nhưng bạn phải là người hỏi "chúng ta cần bao nhiêu nines?".
Bài tập thực hành
Chọn một tính năng quen thuộc: "Đặt lại mật khẩu qua email" cho một app ví điện tử Việt Nam.
- Viết một Business Requirement cho việc đầu tư vào tính năng này (gợi ý: liên quan đến giảm tải tổng đài hoặc tỷ lệ tài khoản bị bỏ rơi).
- Liệt kê ít nhất ba stakeholder và nhu cầu của họ — nhớ bao gồm cả bộ phận bảo mật.
- Viết tối thiểu năm Functional Requirements theo mẫu "Khi... hệ thống phải...".
- Soi từng FR và rút ra ít nhất bốn Non-Functional Requirements, mỗi cái phải có con số đo được (gợi ý: link reset hết hạn sau bao lâu? email phải đến trong bao nhiêu giây? chịu được bao nhiêu request reset mỗi phút để chống tấn công? mã reset phải có độ phức tạp thế nào?).
- Xác định một Transition Requirement nếu có (ví dụ: người dùng cũ đang dùng câu hỏi bảo mật cũ thì xử lý ra sao?).
Tóm tắt
Phân loại yêu cầu là bộ khung chống bỏ sót, không phải lý thuyết suông. BABOK chia yêu cầu thành bốn tầng — Business, Stakeholder, Solution, Transition — và bạn phải đi đủ từng tầng, đừng nhảy cóc tới giải pháp dù cám dỗ rất lớn với nền dev. Trong tầng Solution, yêu cầu chia làm hai: Functional (hệ thống làm gì) và Non-Functional (hệ thống làm tốt đến mức nào). Dev thường vững FR nhưng yếu NFR, trong khi NFR mới là thứ làm sập dự án ở phút go-live.
Lợi thế lớn nhất của bạn là hiểu sâu kỹ thuật: bạn biết P95, concurrency, uptime, băng thông nghĩa là gì. Hãy biến hiểu biết đó thành những con số cụ thể trong tài liệu. Quy tắc vàng để ghi nhớ suốt sự nghiệp BA: mọi NFR phải đo được — nếu không gắn được con số, đó chưa phải là một yêu cầu.