Non-Functional Requirement(NFR)
Yêu cầu về chất lượng vận hành của hệ thống: nhanh, an toàn, ổn định, dễ mở rộng, chạy được trên môi trường nào. Không viết ra thì dev tự quyết, và QC không biết đường nào mà test.
Định nghĩa
Hệ thống chạy đúng nghiệp vụ nhưng xuất báo cáo phải chờ 4 phút, mật khẩu lưu dạng plain text, đúng ngày khuyến mãi thì sập. Không cái nào là lỗi chức năng. Tất cả là hậu quả của NFR không được viết ra.
NFR mô tả hệ thống phải tốt đến mức nào, chứ không mô tả nó làm gì. Trong tài liệu chuẩn (ISO/IEC 25010) người ta gọi là đặc tính chất lượng, và ở dự án thật, đây là phần bị cắt đầu tiên khi tài liệu gấp.
NFR mà không có con số thì chỉ là một lời chúc.
Các nhóm NFR hay gặp
| Nhóm | Hỏi cái gì | Ví dụ viết đo được |
|---|---|---|
| Hiệu năng | Nhanh cỡ nào, chịu tải bao nhiêu | API tra cứu số dư trả về p95 dưới 500ms khi có 300 request/giây |
| Khả dụng | Được phép chết bao lâu | Uptime 99,5% theo tháng, cửa sổ bảo trì tối đa 2 giờ, báo trước 48 giờ |
| Bảo mật | Ai được thấy gì, dữ liệu bảo vệ ra sao | Mật khẩu băm bằng bcrypt cost ≥ 12; số CCCD hiển thị dạng che 6 số đầu |
| Khả năng mở rộng | Lớn lên thì sao | Kiến trúc chịu được tăng gấp 3 lượng đơn trong 12 tháng bằng cách thêm node, không sửa code |
| Tương thích | Chạy ở đâu | Web chạy đúng trên Chrome, Edge, Safari 2 phiên bản gần nhất; app hỗ trợ Android 9 trở lên |
| Khả dụng UX | Dùng có dễ không | Nhân viên mới thao tác trọn một đơn hàng trong 3 phút sau 30 phút đào tạo |
| Khả năng bảo trì | Sửa có dễ không | Độ phủ unit test tối thiểu 70% cho module tính phí |
| Tuân thủ | Luật nào bắt buộc | Log truy cập dữ liệu cá nhân lưu tối thiểu 24 tháng |
| Sao lưu, phục hồi | Hỏng thì bao lâu sống lại | RPO 15 phút, RTO 4 giờ, diễn tập phục hồi 6 tháng một lần |
Không cần dùng hết. Chọn nhóm có rủi ro thật cho dự án của bạn: 5–15 NFR có số hơn hẳn một danh sách 60 dòng chung chung.
Ví dụ thực tế
9 giờ sáng, cổng đăng ký nhập học của một hệ thống trường tư mở, và chỉ mở đúng một ngày. Trong 30 phút đầu có khoảng 17.500 phụ huynh truy cập, đỉnh tầm 6.000 người đồng thời.
Với dự án này, FR chỉ có mấy cái: điền form, tải giấy tờ, nộp lệ phí, tra kết quả. Phần khó nằm hết ở NFR:
- Hệ thống phục vụ 6.000 người dùng đồng thời trong 30 phút đầu, tỷ lệ lỗi HTTP 5xx dưới 0,5%.
- Thời gian tải trang form dưới 3 giây trên mạng 4G ở mức 5 Mbps.
- File giấy tờ tải lên tối đa 5MB, quét virus trước khi lưu, lưu ở vùng lưu trữ không cho truy cập công khai.
- Khi hệ thống thanh toán của đối tác lỗi, cổng vẫn nhận hồ sơ và đánh dấu chờ thanh toán, không chặn toàn bộ luồng.
- Nhật ký truy cập hồ sơ học sinh lưu 24 tháng, chỉ tài khoản vai trò tuyển sinh xem được.
Viết NFR sao cho test được
Ba mảnh bắt buộc: chỉ số + ngưỡng + điều kiện đo. Thiếu mảnh cuối là nguồn cãi nhau lớn nhất. "Trang chủ tải dưới 2 giây" — đo ở máy nào, mạng nào, có cache không, bao nhiêu người đồng thời. Ba người đo ra ba kết quả, ai cũng đúng.
Với hiệu năng, dùng phân vị thay vì trung bình. Trung bình 400ms nghe rất đẹp trong khi 5% người dùng chờ 9 giây. p95 và p99 phản ánh trải nghiệm thật hơn nhiều.
Với bảo mật, đừng viết "hệ thống phải an toàn". Liệt kê cụ thể: OWASP Top 10, phân quyền theo vai trò, chính sách mật khẩu, mã hoá khi truyền và khi lưu — mỗi dòng kèm một cách kiểm.
So sánh nhanh với FR
| Câu hỏi | FR | NFR |
|---|---|---|
| Chủ ngữ | Hệ thống làm gì | Hệ thống làm tốt đến đâu |
| Test bằng | Test case chức năng | Test hiệu năng, pentest, kiểm cấu hình |
| Sửa muộn tốn gì | Thêm màn hình, thêm luồng | Thường phải sửa kiến trúc |
Chính cái ô "thường phải sửa kiến trúc" là lý do NFR không được để tới sprint 8. Thêm một màn hình ở sprint 8 thì khó chịu; đổi mô hình lưu dữ liệu vì tới lúc đó mới biết phải giữ log 24 tháng thì đau hơn nhiều.
Câu hay bị hỏi phỏng vấn
"Cho một ví dụ NFR trong dự án bạn từng làm." Đừng trả lời "hệ thống phải nhanh và bảo mật". Nói một con số, nói bạn lấy nó ở đâu ra, và ai là người ký vào nó. Ý thứ ba mới là ý ít người nói được, vì nó chỉ có nếu bạn từng thật sự đi xin chữ ký cho một dòng NFR.
