Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa bàn giao một hệ thống đặt vé xem phim cho khách hàng. Hệ thống chạy đúng y như đặc tả: người dùng chọn phim, chọn ghế, thanh toán, nhận vé qua email. Mọi tính năng đều hoạt động. Vậy mà ba tuần sau, khách hàng gọi điện phàn nàn gay gắt: vào giờ cao điểm tối thứ Bảy, khi 5.000 người cùng đặt vé một lúc, hệ thống treo cứng 40 giây mỗi lần bấm nút, và có người đã thanh toán xong nhưng không nhận được vé. Đội phát triển ngơ ngác: "Nhưng chức năng đặt vé chúng tôi làm đúng hết mà?"
Vấn đề ở đây không nằm ở việc hệ thống làm gì, mà nằm ở việc hệ thống làm tốt đến mức nào. Đây chính là ranh giới sống còn giữa hai loại yêu cầu mà mọi Business Analyst (BA) bắt buộc phải phân biệt rõ: Functional Requirements (FR) — yêu cầu chức năng, và Non-Functional Requirements (NFR) — yêu cầu phi chức năng.
Trong kỳ thi ECBA, đây là một chủ đề kinh điển. BABOK xếp hai khái niệm này vào nhóm "Requirements Classification Schema" (lược đồ phân loại yêu cầu) thuộc Knowledge Area Requirements Analysis and Design Definition. Đề thi rất hay đưa ra một câu mô tả và hỏi: "Đây là loại yêu cầu nào?" Nếu bạn không nắm chắc, bạn sẽ mất điểm ở những câu tưởng dễ. Quan trọng hơn, trong công việc thực tế, việc bỏ sót NFR là nguyên nhân số một khiến dự án "đúng tính năng nhưng vẫn thất bại". Bài này sẽ giúp bạn phân biệt rạch ròi, viết đúng, và không bao giờ quên loại yêu cầu thầm lặng nhưng chết người này.
Khái niệm cốt lõi
Functional Requirements — hệ thống PHẢI LÀM GÌ
Functional Requirements mô tả hành vi (behavior) của hệ thống — những gì hệ thống phải làm để phản hồi lại đầu vào hoặc một sự kiện. Nói cách khác, FR trả lời câu hỏi WHAT: hệ thống xử lý dữ liệu gì, tính toán ra sao, trả về kết quả thế nào.
Theo BABOK, functional requirements describe the capabilities a solution must have in terms of the behaviour and information that the solution will manage. Một FR luôn gắn với một chức năng cụ thể, có thể quan sát được và kiểm thử được bằng cách: "đưa đầu vào X, hệ thống phải cho ra kết quả Y".
Ví dụ các FR điển hình:
- "Hệ thống phải gửi mã OTP gồm 6 chữ số đến số điện thoại người dùng khi họ bấm nút Đăng nhập."
- "Khi khách hàng đặt hàng trên 500.000đ, hệ thống phải tự động áp dụng phí giao hàng miễn phí."
- "Hệ thống phải cho phép quản trị viên xuất danh sách đơn hàng ra file Excel."
- "Nếu số dư ví thấp hơn giá trị đơn hàng, hệ thống phải hiển thị thông báo 'Số dư không đủ'."
Non-Functional Requirements — hệ thống PHẢI TỐT NHƯ THẾ NÀO
Non-Functional Requirements (BABOK còn gọi là Quality of Service Requirements — yêu cầu về chất lượng dịch vụ) không mô tả hệ thống làm gì, mà mô tả hệ thống phải làm tốt đến mức nào, dưới điều kiện nào. NFR trả lời câu hỏi HOW WELL: nhanh bao nhiêu, chịu tải bao nhiêu, an toàn ra sao, dễ dùng cỡ nào, hoạt động liên tục đến đâu.
NFR không gắn với một chức năng đơn lẻ mà thường áp dụng xuyên suốt cả hệ thống hoặc một nhóm chức năng. Đây là lý do người ta hay gọi chúng là "cross-cutting" — cắt ngang.
Các nhóm NFR phổ biến (rất hay xuất hiện trong đề ECBA, nên nhớ thuật ngữ tiếng Anh):
- Performance (Hiệu năng): "Trang chủ phải tải xong trong dưới 2 giây với kết nối 4G."
- Scalability (Khả năng mở rộng): "Hệ thống phải xử lý đồng thời 10.000 người dùng vào giờ cao điểm mà thời gian phản hồi không vượt quá 3 giây."
- Availability (Tính sẵn sàng): "Hệ thống phải đạt uptime 99,9% mỗi tháng."
- Reliability (Độ tin cậy): "Tỷ lệ giao dịch thanh toán thất bại do lỗi hệ thống phải dưới 0,1%."
- Security (Bảo mật): "Mật khẩu người dùng phải được mã hóa bằng thuật toán băm bcrypt; dữ liệu thẻ phải tuân thủ chuẩn PCI-DSS."
- Usability (Khả năng dùng được): "Người dùng mới phải hoàn tất đăng ký trong dưới 3 phút mà không cần hướng dẫn."
- Compatibility (Tương thích): "Ứng dụng phải chạy được trên iOS 14 trở lên và Android 9 trở lên."
- Maintainability / Portability / Compliance: dễ bảo trì, dễ chuyển đổi nền tảng, tuân thủ pháp luật (ví dụ Nghị định 13/2023 về bảo vệ dữ liệu cá nhân tại Việt Nam).
Sự khác biệt cốt lõi — bảng so sánh nhanh
| Tiêu chí | Functional Requirement | Non-Functional Requirement |
|---|---|---|
| Câu hỏi trả lời | WHAT — làm gì | HOW WELL — làm tốt đến đâu |
| Mô tả | Hành vi, chức năng cụ thể | Chất lượng, ràng buộc, thuộc tính |
| Phạm vi | Thường gắn một chức năng | Thường cắt ngang nhiều chức năng |
| Khi thiếu thì sao | Hệ thống thiếu tính năng | Hệ thống có đủ tính năng nhưng chậm, không an toàn, hay sập |
| Ví dụ | "Gửi OTP khi đăng nhập" | "OTP phải đến trong vòng 10 giây" |
Tình huống thực tế
Tình huống 1 — Sàn thương mại điện tử và ngày sale 12.12
Một sàn thương mại điện tử giả định tên ShopFast chuẩn bị cho ngày sale lớn 12.12. Đội BA viết đặc tả tính năng "Flash Sale": hệ thống cho phép khách mua sản phẩm giảm giá tới 50%, mỗi sản phẩm giới hạn 1.000 suất.
Đội phát triển làm đúng chức năng: nút bấm hoạt động, trừ tồn kho chính xác, tạo đơn hàng đúng. Tất cả FR đều pass. Nhưng đúng 0h ngày 12.12, khi 80.000 người cùng vào tranh suất Flash Sale trong vòng 30 giây, hệ thống quá tải. Có khách bấm mua thành công nhưng tồn kho bị trừ hai lần (overselling), khiến sàn bán ra 1.150 suất trên 1.000 suất thực có. Hậu quả: phải hủy 150 đơn, khách giận dữ, mất uy tín.
Diễn giải: FR ("cho phép mua, trừ tồn kho") đã được làm đúng. Nhưng đội BA quên ba NFR cực kỳ quan trọng cho bối cảnh sale: Scalability (chịu được 80.000 request đồng thời), Reliability/Data consistency (không được trừ tồn kho sai dù tải cao), và Performance (phản hồi dưới 2 giây). Vì NFR không được viết ra, đội kiểm thử cũng không có kịch bản kiểm thử tải, nên lỗi chỉ lộ ra khi quá muộn.
Bài học: NFR phải được viết ra thành con số đo được trước khi lập trình, vì kiến trúc hệ thống (chọn database, cơ chế khóa tồn kho, cache, hàng đợi) phụ thuộc trực tiếp vào những con số này. Sửa NFR sau khi đã code xong thường đồng nghĩa với việc viết lại kiến trúc — đắt gấp nhiều lần.
Tình huống 2 — Ứng dụng ngân hàng số và bài học bảo mật
Một ngân hàng số giả định tên VietPay ra mắt app chuyển tiền. FR rất rõ: "Người dùng nhập số tài khoản, số tiền, bấm Chuyển, hệ thống thực hiện giao dịch và gửi biên lai." App chạy mượt, giao diện đẹp, người dùng khen.
Ba tháng sau, một số khách bị mất tiền. Điều tra cho thấy: app lưu phiên đăng nhập (session) không hết hạn, và không có cơ chế phát hiện đăng nhập bất thường từ thiết bị lạ. Kẻ gian chiếm được điện thoại cũ của nạn nhân vẫn đăng nhập được sau nhiều tháng.
Diễn giải: Toàn bộ FR chuyển tiền hoạt động hoàn hảo. Lỗ hổng nằm ở các NFR thuộc nhóm Security: yêu cầu về thời gian hết hạn phiên (session timeout), xác thực đa yếu tố khi đăng nhập thiết bị mới, và phát hiện hành vi bất thường. Những NFR này không "hiện hình" trên màn hình nên dễ bị bỏ sót khi cả đội chỉ chăm chăm vào tính năng nhìn thấy được.
Bài học: NFR về bảo mật và tuân thủ (compliance) đặc biệt nguy hiểm khi bị quên, vì hậu quả không xuất hiện ngay mà bùng phát sau, kèm rủi ro pháp lý. Với hệ thống tài chính tại Việt Nam, BA phải chủ động đưa các NFR tuân thủ quy định của Ngân hàng Nhà nước và Nghị định 13/2023 về bảo vệ dữ liệu cá nhân vào đặc tả ngay từ đầu.
Tình huống 3 — App gọi xe và trải nghiệm người dùng
Một startup gọi xe ở Đông Nam Á, tạm gọi GoRide, ra mắt tính năng đặt xe. FR: "Người dùng nhập điểm đón, điểm đến, hệ thống tìm tài xế gần nhất và hiển thị giá." Tính năng đúng 100%.
Nhưng tỷ lệ người dùng bỏ giữa chừng (drop-off) cao bất thường ở bước chờ tìm tài xế. Phân tích cho thấy thao tác tìm tài xế mất trung bình 18 giây, và trong lúc đó màn hình đứng im không có phản hồi nào, khiến người dùng tưởng app bị treo và thoát ra.
Diễn giải: Đây là vấn đề NFR thuộc nhóm Performance và Usability. FR "tìm tài xế" làm đúng, nhưng thiếu NFR về thời gian phản hồi tối đa và về phản hồi trực quan cho người dùng trong lúc chờ. Sau khi đội BA bổ sung NFR "thời gian tìm tài xế phải dưới 8 giây cho 90% lượt đặt" và "phải hiển thị hoạt ảnh tiến trình trong lúc chờ", tỷ lệ bỏ giữa chừng giảm gần một nửa.
Bài học: NFR không chỉ là chuyện kỹ thuật khô khan — nó trực tiếp quyết định trải nghiệm và doanh thu. Một con số phản hồi chậm vài giây có thể đánh mất hàng nghìn khách hàng mà không tính năng nào cứu được.
Hướng dẫn từng bước
Đây là quy trình thực dụng giúp bạn xác định và viết đầy đủ cả FR lẫn NFR cho một yêu cầu.
Bước 1 — Khai thác và liệt kê Functional Requirements trước. Với mỗi nhu cầu của stakeholder, hỏi "Hệ thống phải làm gì?" và viết ra dưới dạng "Hệ thống phải...". Mỗi FR nên độc lập, rõ ràng, kiểm thử được.
Bước 2 — Với MỖI Functional Requirement, đặt câu hỏi NFR đi kèm. Đây là bước quan trọng nhất và hay bị bỏ qua. Dùng một danh sách câu hỏi cố định cho từng nhóm NFR:
- Nhanh đến mức nào? (Performance) — bao nhiêu giây, bao nhiêu giao dịch/giây?
- Chịu được bao nhiêu người dùng cùng lúc? (Scalability)
- Phải hoạt động liên tục đến đâu? (Availability) — uptime bao nhiêu %?
- Cần an toàn cỡ nào? (Security) — mã hóa gì, ai được truy cập?
- Dễ dùng đến đâu? (Usability)
- Phải tuân thủ quy định nào? (Compliance)
Bước 4 — Phân loại và gắn nhãn rõ ràng trong tài liệu. Trong tài liệu đặc tả (BRD/SRS), tách hai mục riêng: "Functional Requirements" và "Non-Functional Requirements", hoặc gắn nhãn [FR]/[NFR] cho từng dòng. Việc này giúp đội kiểm thử và kiến trúc sư biết phải làm gì với từng loại.
Bước 5 — Rà soát với kiến trúc sư và đội kiểm thử sớm. NFR ảnh hưởng đến quyết định kiến trúc, nên phải được xác nhận khả thi trước khi code. Đồng thời, mỗi NFR phải kèm cách kiểm thử (ví dụ: kiểm thử tải bằng công cụ JMeter để xác nhận chịu được 10.000 người).
Lỗi thường gặp & mẹo
Lỗi 1 — Quên hoàn toàn NFR. Đây là lỗi phổ biến nhất. Đội chỉ viết tính năng nhìn thấy được. Mẹo: lập một checklist NFR cố định và bắt buộc đi qua nó cho mọi tính năng quan trọng, đặc biệt các tính năng có giao dịch, tải cao, hoặc dữ liệu nhạy cảm.
Lỗi 2 — Viết NFR chung chung không đo được. "Hệ thống phải nhanh", "phải an toàn", "phải dễ dùng" là những câu vô dụng vì không ai kiểm thử được. Mẹo: ép mình thêm con số. Nếu stakeholder nói "phải nhanh", hãy hỏi lại "nhanh nghĩa là dưới mấy giây thì anh chấp nhận được?".
Lỗi 3 — Nhầm lẫn FR và NFR trong đề thi. Một bẫy kinh điển: "Hệ thống phải hiển thị thông báo lỗi" — đây là FR (hành vi). Nhưng "Thông báo lỗi phải xuất hiện trong vòng 1 giây" — đây là NFR (chất lượng của hành vi đó). Mẹo nhận diện trong phòng thi: nếu câu mô tả một hành động hệ thống thực hiện → FR. Nếu câu mô tả một thuộc tính/giới hạn/mức độ (thời gian, số lượng, %, mã hóa, tương thích) → NFR.
Lỗi 4 — Coi NFR là việc của riêng kỹ thuật. Nhiều BA nghĩ NFR để dev tự lo. Sai. NFR đến từ nhu cầu kinh doanh (khách không chờ quá 3 giây, dữ liệu phải tuân thủ luật) nên BA phải khai thác và viết ra, rồi mới phối hợp với kỹ thuật để định lượng.
Mẹo ghi nhớ cho phòng thi: FR = Function = Feature (tính năng). NFR = chất lượng (quality attributes), thường là các từ kết thúc bằng "-ility": availability, scalability, usability, reliability, security, performance. Thấy "-ility" hoặc thấy con số đo lường → nghĩ ngay NFR.
Bài tập thực hành
Bài 1 — Phân loại. Với mỗi câu sau, ghi rõ FR hay NFR và giải thích ngắn:
- "Hệ thống phải cho phép người dùng đặt lại mật khẩu qua email."
- "Email đặt lại mật khẩu phải đến hộp thư người dùng trong vòng 30 giây."
- "Hệ thống phải hỗ trợ tiếng Việt, tiếng Anh và tiếng Thái."
- "Giao diện phải hiển thị đúng trên trình duyệt Chrome, Safari và Firefox."
- "Người dùng phải có thể lọc sản phẩm theo giá và thương hiệu."
Bài 3 — Sửa NFR mơ hồ. Các NFR sau viết sai vì không đo được. Hãy viết lại cho đúng chuẩn (metric + threshold + condition):
- "Hệ thống phải tải nhanh."
- "Hệ thống phải chịu được nhiều người dùng."
- "Hệ thống phải an toàn."
Tóm tắt
Functional Requirements trả lời câu hỏi hệ thống PHẢI LÀM GÌ — mô tả hành vi, tính năng cụ thể, kiểm thử được bằng cặp đầu vào - đầu ra. Non-Functional Requirements trả lời câu hỏi hệ thống PHẢI TỐT ĐẾN MỨC NÀO — mô tả chất lượng và ràng buộc như hiệu năng, khả năng mở rộng, tính sẵn sàng, bảo mật, khả năng dùng được, tính tương thích; BABOK gọi đây là Quality of Service Requirements.
Điều cần khắc cốt: một hệ thống có thể đúng 100% tính năng mà vẫn thất bại thảm hại nếu NFR bị bỏ quên — như các tình huống ShopFast (quá tải ngày sale), VietPay (lỗ hổng bảo mật), GoRide (chậm khiến khách bỏ đi) đã cho thấy. Vai trò của BA là không bao giờ viết FR mà quên hỏi cặp NFR đi kèm, và luôn lượng hóa NFR thành con số đo được.
Trong phòng thi ECBA, hãy nhớ quy tắc nhận diện: mô tả hành động hệ thống làm → FR; mô tả thuộc tính, mức độ, giới hạn (thời gian, số lượng, %, mã hóa, tương thích, các từ "-ility") → NFR. Nắm chắc ranh giới này, bạn vừa ghi điểm trong kỳ thi, vừa trở thành một BA mà đội phát triển thật sự tin tưởng.