Mở đầu — vì sao bài này quan trọng
Hãy thử tưởng tượng bạn vừa bàn giao một hệ thống đặt vé xem phim cho CGV. Mọi tính năng đều chạy đúng: chọn ghế được, thanh toán được, gửi vé qua email được. Khách hàng nghiệm thu từng dòng chức năng, gật đầu hài lòng. Rồi tối thứ Sáu khi bộ phim bom tấn ra mắt, 50.000 người cùng vào đặt vé một lúc. Hệ thống treo cứng trong 8 phút. Doanh thu bốc hơi, mạng xã hội dậy sóng, và người đầu tiên bị gọi vào phòng họp khẩn là Business Analyst — chính là bạn.
Câu hỏi đau đớn: "Chức năng đặt vé hoạt động hoàn hảo mà, sao lại hỏng?" Câu trả lời nằm ở chỗ chúng ta đã viết đầy đủ chức năng làm gì (functional requirements) nhưng quên mất hệ thống phải làm tốt đến mức nào (non-functional requirements — NFR).
NFR là phần "vô hình" của requirements. Stakeholder hiếm khi tự nói ra "tôi muốn hệ thống chịu được 50.000 người đồng thời", bởi với họ điều đó là hiển nhiên. Nhưng "hiển nhiên" trong đầu họ và "đã viết ra để dev biết mà xây" là hai chuyện khác nhau hoàn toàn. Một BA giỏi không chờ stakeholder nói ra NFR — họ chủ động khai thác, lượng hóa và viết chúng thành các yêu cầu kiểm chứng được. Đây chính là ranh giới phân biệt một BA "ghi chép yêu cầu" với một BA thực sự bảo vệ được dự án.
Bài này tập trung riêng vào kỹ năng viết NFR đúng và đầy đủ — phân loại theo mô hình FURPS+, lượng hóa từng loại, và biến những kỳ vọng mơ hồ thành tiêu chí có thể test được.
Khái niệm cốt lõi
NFR là gì và khác functional requirement ra sao
Functional requirement (FR) mô tả hệ thống làm gì — "Người dùng có thể đặt lại mật khẩu qua email". Non-functional requirement (NFR) mô tả hệ thống vận hành tốt đến mức nào khi làm việc đó — "Email đặt lại mật khẩu phải đến hộp thư người dùng trong vòng 30 giây ở 99% trường hợp".
Một cách ví von dễ nhớ: nếu FR là "chiếc xe phải chạy được", thì NFR là "chiếc xe phải đạt 100 km/h trong 8 giây, tiêu thụ dưới 6 lít/100km, và phanh dừng trong 35 mét". FR quyết định hệ thống có dùng được không; NFR quyết định hệ thống có đáng dùng không và có sống sót trong thực tế không.
Mô hình FURPS+ — bộ khung phân loại NFR
FURPS+ do Hewlett-Packard đề xuất là một trong những bộ khung phân loại NFR dễ áp dụng nhất. Mỗi chữ cái là một nhóm chất lượng:
F — Functionality (Chức năng mở rộng): Đây là phần dễ gây nhầm. Trong FURPS, "F" không phải là FR thông thường mà là các thuộc tính chức năng có tính chất xuyên suốt như bảo mật (security), khả năng (capability), và tính tương thích/khả năng phối hợp. Ví dụ: "Hệ thống phải mã hóa toàn bộ dữ liệu thẻ theo chuẩn PCI DSS", "Mật khẩu phải băm bằng bcrypt với cost factor tối thiểu 12".
U — Usability (Tính khả dụng): Trải nghiệm người dùng và khả năng tiếp cận. Bao gồm độ dễ học, tính nhất quán, accessibility (hỗ trợ người khiếm thị, tương phản màu...), và tài liệu hướng dẫn. Ví dụ: "Người dùng mới hoàn tất đăng ký không quá 3 phút mà không cần xem hướng dẫn", "Giao diện đạt chuẩn WCAG 2.1 mức AA".
R — Reliability (Độ tin cậy): Khả năng hệ thống hoạt động ổn định, ít lỗi và phục hồi tốt. Bao gồm uptime (thời gian khả dụng), MTBF (Mean Time Between Failures — thời gian trung bình giữa hai lần hỏng), MTTR (Mean Time To Recover — thời gian trung bình để phục hồi), và tỉ lệ lỗi cho phép. Ví dụ: "Hệ thống đạt uptime 99,9% theo tháng (tối đa 43 phút downtime/tháng)".
P — Performance (Hiệu năng): Tốc độ và khả năng chịu tải. Bao gồm response time (thời gian phản hồi), throughput (số giao dịch/giây), số người dùng đồng thời, và mức tiêu thụ tài nguyên. Ví dụ: "Trang danh sách sản phẩm load dưới 2 giây ở phân vị 95 (p95) khi có 10.000 người dùng đồng thời".
S — Supportability (Khả năng hỗ trợ/bảo trì): Mức độ dễ vận hành, bảo trì, mở rộng và cấu hình hệ thống. Bao gồm khả năng bảo trì, kiểm thử, cấu hình, cài đặt, khả năng mở rộng (scalability), và quốc tế hóa. Ví dụ: "Hệ thống hỗ trợ thêm ngôn ngữ mới mà không cần sửa code, chỉ qua file cấu hình".
Dấu + (plus): Mở rộng cho các ràng buộc không nằm gọn trong 5 nhóm trên:
- Design constraints: "Phải dùng cơ sở dữ liệu Oracle theo chuẩn doanh nghiệp".
- Implementation constraints: "Backend viết bằng Java 17, tuân thủ coding standard nội bộ".
- Interface constraints: "Tích hợp với cổng thanh toán VNPAY qua API v2".
- Physical/Legal constraints: "Dữ liệu công dân Việt Nam phải lưu trữ trên máy chủ đặt tại Việt Nam theo Nghị định 13/2023 về bảo vệ dữ liệu cá nhân".
Đặc tính sống còn của một NFR tốt: phải lượng hóa được
NFR tồi: "Hệ thống phải nhanh", "Giao diện phải thân thiện", "Hệ thống phải an toàn". Những câu này vô nghĩa với developer và không thể test. Nhanh là bao nhiêu giây? An toàn theo chuẩn nào?
NFR tốt luôn có công thức: [Tiêu chí đo] + [Ngưỡng số cụ thể] + [Điều kiện/ngữ cảnh].
Ví dụ: "Thời gian phản hồi (tiêu chí) của API tra cứu số dư phải dưới 500ms ở p95 (ngưỡng) khi hệ thống đang xử lý 2.000 request/giây (điều kiện)". Một developer đọc câu này biết chính xác phải xây gì; một tester biết chính xác phải đo gì.
Tình huống thực tế
Tình huống 1 — Sàn TMĐT và "ngày đôi" 9/9
Một sàn thương mại điện tử tại Việt Nam (gọi là ShopFast) chuẩn bị cho campaign 9/9. Ở giai đoạn đầu, BA chỉ viết FR: "Người dùng thêm sản phẩm vào giỏ", "Áp mã giảm giá", "Thanh toán". Ngày sự kiện, lưu lượng tăng gấp 30 lần bình thường. Trang chủ load 14 giây, nhiều người dùng nhấn "Đặt hàng" hai ba lần vì tưởng treo, gây trùng đơn và trừ kho sai.
Sau sự cố, BA ngồi lại bổ sung NFR. Nhóm Performance: "Trang chủ và trang sản phẩm phải load dưới 3 giây ở p95 khi có tối thiểu 80.000 phiên đồng thời". Nhóm Reliability: "Trong khung giờ flash sale, hệ thống chấp nhận degrade có kiểm soát — nếu vượt tải, hiển thị hàng chờ (queue) thay vì lỗi 500". Nhóm Functionality/bảo mật giao dịch: "Nút Đặt hàng phải chống double-submit, một mã giỏ hàng chỉ tạo được một đơn trong 5 giây".
Bài học: NFR về hiệu năng và độ tin cậy phải được khai thác từ kịch bản tải đỉnh, không phải tải trung bình. BA cần chủ động hỏi: "Ngày bận nhất trong năm trông như thế nào?" — vì đó mới là lúc hệ thống bị thử lửa.
Tình huống 2 — Ngân hàng số và Nghị định 13
Một ngân hàng triển khai tính năng mở tài khoản online bằng eKYC. BA ban đầu tập trung vào luồng chức năng: chụp CCCD, đối chiếu khuôn mặt, tạo tài khoản. Đến vòng review với bộ phận pháp chế và an ninh thông tin, hàng loạt NFR mới lộ ra.
Nhóm Functionality (security): "Toàn bộ ảnh CCCD và dữ liệu sinh trắc học phải mã hóa AES-256 khi lưu trữ (at rest) và TLS 1.2+ khi truyền (in transit)"; "Hệ thống ghi audit log mọi truy cập dữ liệu cá nhân, lưu tối thiểu 5 năm". Nhóm dấu + (legal): "Dữ liệu khách hàng Việt Nam lưu trữ tại trung tâm dữ liệu đặt tại Việt Nam, tuân thủ Nghị định 13/2023". Nhóm Performance: "Kết quả đối chiếu khuôn mặt trả về dưới 5 giây ở p90". Nhóm Reliability: "Dịch vụ eKYC đạt uptime 99,95% trong giờ giao dịch".
Bài học: Trong các ngành chịu quản lý chặt (banking, fintech, y tế), một phần lớn NFR đến từ tuân thủ pháp lý và bảo mật, không phải từ mong muốn của người dùng. BA bắt buộc phải kéo pháp chế, an ninh thông tin và DevOps vào quá trình khai thác NFR sớm, vì sửa các ràng buộc này về sau cực kỳ tốn kém.
Tình huống 3 — Ứng dụng gọi xe và độ trễ định vị
Một startup gọi xe ở Đông Nam Á phát hiện tỉ lệ hủy chuyến cao bất thường. Điều tra ra: vị trí tài xế trên bản đồ cập nhật chậm 10–15 giây, khách thấy xe "đứng yên" nên hủy. Đây không phải lỗi chức năng — tính năng định vị vẫn chạy đúng — mà là thiếu NFR về performance và usability.
BA bổ sung: "Vị trí tài xế cập nhật tối đa mỗi 3 giây với độ trễ hiển thị dưới 2 giây"; "Khi mất GPS, ứng dụng hiển thị thông báo rõ ràng trong 1 giây thay vì treo bản đồ". Sau khi triển khai, tỉ lệ hủy chuyến giảm khoảng 18%.
Bài học: NFR không phải thứ "tốt thì có" — chúng trực tiếp tác động đến chỉ số kinh doanh. Một con số response time đúng có thể cứu hàng triệu đồng doanh thu mỗi ngày.
Hướng dẫn từng bước
Bước 1 — Rà soát từng FR và hỏi "tốt đến mức nào". Với mỗi yêu cầu chức năng, đặt câu hỏi: nhanh đến đâu, chính xác đến đâu, an toàn ra sao, chịu được bao nhiêu người. Mỗi câu trả lời là một NFR tiềm năng. Đây là cách phát hiện NFR hiệu quả nhất vì NFR thường "bám" vào FR.
Bước 2 — Duyệt qua từng nhóm FURPS+ như một checklist. Lần lượt tự hỏi: Functionality (bảo mật, tuân thủ)? Usability (UX, accessibility)? Reliability (uptime, MTBF)? Performance (tốc độ, tải)? Supportability (bảo trì, mở rộng)? Và dấu + (ràng buộc kỹ thuật, pháp lý)? Đi hết 6 nhóm giúp bạn không bỏ sót cả mảng NFR.
Bước 3 — Khai thác ngưỡng số từ đúng stakeholder. NFR cần con số, và con số phải đến từ người có thẩm quyền: ngưỡng performance hỏi kiến trúc sư và đội vận hành; uptime và SLA hỏi business owner; bảo mật và lưu trữ dữ liệu hỏi pháp chế/an ninh. Đừng tự bịa số — hãy hỏi "ngưỡng nào là chấp nhận được, ngưỡng nào là không thể tha thứ".
Bước 4 — Viết theo công thức lượng hóa. Mỗi NFR phải có: tiêu chí đo + ngưỡng số + điều kiện. Ưu tiên dùng phân vị (p95, p99) thay vì "trung bình", vì trung bình che giấu trải nghiệm tệ của nhóm người dùng bị ảnh hưởng nặng nhất.
Bước 5 — Định nghĩa cách đo và tiêu chí nghiệm thu. Một NFR chưa hoàn chỉnh nếu chưa nói rõ đo bằng gì, trong điều kiện nào. Ví dụ: "Đo qua công cụ load test JMeter với kịch bản 10.000 virtual user trong 30 phút". Điều này biến NFR thành điều khoản nghiệm thu rõ ràng.
Bước 6 — Đưa NFR vào tài liệu và liên kết với FR. Ghi NFR thành mục riêng trong SRS, gắn ID và liên kết tới các FR liên quan để khi FR thay đổi, bạn rà được NFR nào bị ảnh hưởng.
Lỗi thường gặp & mẹo
Lỗi 1 — Viết NFR mơ hồ, không số. "Hệ thống phải nhanh và ổn định" là câu nói của khách, không phải requirement. Mẹo: mỗi NFR phải vượt qua bài test "tester có đo được không?". Nếu không đo được, nó chưa xong.
Lỗi 2 — Dùng giá trị trung bình thay vì phân vị. "Response time trung bình 1 giây" nghe ổn, nhưng có thể 10% người dùng đang chịu 8 giây. Mẹo: dùng p95/p99 cho các yêu cầu hiệu năng quan trọng.
Lỗi 3 — Bỏ quên NFR cho đến cuối dự án. NFR như scalability hay security thường ăn sâu vào kiến trúc; phát hiện muộn nghĩa là phải đập đi xây lại. Mẹo: khai thác NFR ngay từ giai đoạn phân tích, song song với FR.
Lỗi 4 — Đặt ngưỡng phi thực tế "cho chắc". "Uptime 100%" hay "response time 0ms" là bất khả thi và đẩy chi phí lên vô lý. Mẹo: mỗi "số 9" thêm vào uptime (99,9% → 99,99%) tăng chi phí theo cấp số nhân; hãy cân bằng giữa kỳ vọng và ngân sách.
Lỗi 5 — NFR mâu thuẫn nhau mà không nhận ra. "Bảo mật tối đa" thường xung đột với "đăng nhập trong 1 giây"; "mã hóa mọi thứ" xung đột với "hiệu năng cao nhất". Mẹo: khi viết NFR, luôn rà các cặp đánh đổi (trade-off) và để stakeholder quyết định ưu tiên.
Lỗi 6 — Quên NFR về vận hành (supportability). Đội dev hay tập trung tính năng mà quên hệ thống cần được giám sát, backup, rollback. Mẹo: luôn hỏi "khi hệ thống hỏng lúc 2 giờ sáng, đội vận hành cần gì để phục hồi?".
Bài tập thực hành
Bài tập 1 — Chuyển NFR mơ hồ thành NFR lượng hóa. Viết lại 4 câu sau theo công thức [tiêu chí + ngưỡng + điều kiện]:
- "Trang web phải tải nhanh."
- "Hệ thống phải an toàn."
- "Ứng dụng phải dễ dùng."
- "Hệ thống phải luôn sẵn sàng."
Bài tập 3 — Phát hiện đánh đổi. Trong danh sách NFR bạn viết ở Bài tập 2, chỉ ra ít nhất một cặp NFR có khả năng xung đột nhau, giải thích vì sao, và đề xuất stakeholder nào sẽ quyết định ưu tiên.
Bài tập 4 — Phỏng vấn khai thác NFR. Soạn 8 câu hỏi bạn sẽ dùng trong buổi elicitation để moi ra NFR ẩn từ business owner và đội vận hành cho một hệ thống đặt lịch khám bệnh online. Gợi ý: bắt đầu từ "ngày bận nhất", "điều gì xảy ra khi hệ thống sập", "dữ liệu nào nhạy cảm về pháp lý".
Tóm tắt
Non-Functional Requirements là phần dễ bị bỏ quên nhất nhưng lại quyết định hệ thống có sống sót trong thực tế hay không. Trong khi functional requirement nói hệ thống làm gì, NFR nói hệ thống phải làm tốt đến mức nào.
Mô hình FURPS+ cho bạn bộ khung phân loại đầy đủ: Functionality (bảo mật, tuân thủ), Usability (trải nghiệm, accessibility), Reliability (uptime, MTBF, MTTR), Performance (tốc độ, tải), Supportability (bảo trì, mở rộng), cùng dấu + cho các ràng buộc kỹ thuật và pháp lý.
Nguyên tắc vàng: mọi NFR phải lượng hóa được theo công thức [tiêu chí đo + ngưỡng số + điều kiện], ưu tiên phân vị p95/p99 thay vì trung bình, và luôn kèm cách đo để biến thành tiêu chí nghiệm thu. Hãy khai thác NFR sớm — song song với FR — từ kịch bản tải đỉnh, từ pháp chế và an ninh, từ đội vận hành. Và đừng quên: NFR thường mâu thuẫn nhau, nhiệm vụ của BA là làm rõ các đánh đổi để stakeholder ra quyết định có cơ sở. Khi bạn viết NFR đúng và đầy đủ, bạn không chỉ ghi chép yêu cầu — bạn đang bảo vệ cả dự án khỏi cú sập tối thứ Sáu.