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 thanh toán cho khách hàng. Mọi chức năng đều chạy đúng: tạo giao dịch được, hoàn tiền được, đối soát được. Demo trên môi trường test mượt mà. Nhưng ngày khai trương, lúc cao điểm có 5.000 người cùng bấm "Thanh toán" trong một phút, hệ thống quay tròn 30 giây rồi báo lỗi timeout. Khách bỏ giỏ hàng, call center cháy máy, và sếp gọi cho bạn lúc 11 giờ đêm.
Vấn đề ở đây không phải là hệ thống làm sai chức năng — mà là hệ thống làm chức năng đó không đủ tốt. Đây chính là địa hạt của Non-Functional Requirements (NFR) — yêu cầu phi chức năng. Nếu Functional Requirements trả lời câu hỏi "hệ thống làm gì", thì NFR trả lời câu hỏi "hệ thống làm việc đó tốt đến mức nào": nhanh ra sao, chịu được bao nhiêu người, an toàn thế nào, dễ vận hành đến đâu.
Với một Technical BA, NFR là nơi bạn tạo ra khác biệt rõ rệt so với một BA chức năng thuần túy. Bất kỳ ai cũng có thể viết "người dùng đăng nhập bằng email và mật khẩu". Nhưng để viết được "trang đăng nhập phải phản hồi dưới 500ms ở phân vị 95 (p95) khi có 2.000 phiên đồng thời, và phải sẵn sàng 99.9% thời gian trong tháng" thì bạn cần hiểu hệ thống vận hành thực sự ra sao. NFR thường là thứ bị bỏ quên trong tài liệu, nhưng lại là nguyên nhân số một khiến dự án thất bại lúc go-live. Bài này sẽ giúp bạn nắm chắc các nhóm NFR cốt lõi và cách viết chúng sao cho đo được và kiểm thử được.
Khái niệm cốt lõi
NFR là những ràng buộc về chất lượng và vận hành của hệ thống. Chúng cắt ngang toàn bộ các tính năng chứ không gắn với một màn hình hay nghiệp vụ cụ thể. Một NFR tốt luôn phải đo lường được — nghĩa là có con số, có ngưỡng, có điều kiện. Câu "hệ thống phải nhanh" không phải là NFR; "hệ thống phải trả kết quả tìm kiếm dưới 800ms ở p95" mới là NFR.
Hãy đi qua những nhóm NFR quan trọng nhất mà một Technical BA cần thành thạo.
1. Performance — Hiệu năng
Đây là nhóm được nhắc đến nhiều nhất. Performance gồm hai khía cạnh chính:
- Response time (thời gian phản hồi): hệ thống mất bao lâu để trả về kết quả cho một yêu cầu. Lưu ý quan trọng: đừng bao giờ chỉ viết "thời gian trung bình", vì trung bình che giấu sự thật. Hãy dùng percentile: p50 (trung vị), p95, p99. Nếu p99 = 3 giây, nghĩa là cứ 100 người thì có 1 người chờ 3 giây — và với 1 triệu request/ngày, đó là 10.000 người không hài lòng.
- Throughput (thông lượng): hệ thống xử lý được bao nhiêu yêu cầu trong một đơn vị thời gian — thường tính bằng TPS (transactions per second) hoặc RPS (requests per second).
2. Scalability — Khả năng mở rộng
Scalability là khả năng hệ thống "lớn lên" khi tải tăng. Có hai hướng:
- Vertical scaling (scale up): nâng cấp máy mạnh hơn — thêm CPU, RAM. Đơn giản nhưng có trần và đắt.
- Horizontal scaling (scale out): thêm nhiều máy/instance chạy song song. Linh hoạt hơn nhưng đòi hỏi hệ thống phải thiết kế stateless, có load balancer.
3. Availability — Tính sẵn sàng
Availability đo bằng phần trăm thời gian hệ thống hoạt động, thường gọi là "số 9":
| Mức | % uptime | Downtime tối đa/năm |
|---|---|---|
| Hai số 9 | 99% | ~3.65 ngày |
| Ba số 9 | 99.9% | ~8.76 giờ |
| Bốn số 9 | 99.99% | ~52.6 phút |
| Năm số 9 | 99.999% | ~5.26 phút |
4. Reliability — Độ tin cậy
Khác với availability (hệ thống có chạy không), reliability đo hệ thống chạy có đúng và ổn định không. Hai chỉ số kinh điển:
- MTBF (Mean Time Between Failures): thời gian trung bình giữa hai lần hỏng.
- MTTR (Mean Time To Recovery): thời gian trung bình để phục hồi sau khi hỏng.
5. Security — An toàn bảo mật
Ở mức NFR, bạn nêu yêu cầu bảo mật đo được: mã hóa dữ liệu khi truyền (TLS 1.2 trở lên), khi lưu (AES-256), thời gian hết hạn phiên, chính sách mật khẩu, tuân thủ chuẩn (PCI-DSS, ISO 27001). Lưu ý: bài này chỉ chạm bề mặt — chủ đề bảo mật được đào sâu ở các bài 30–33.
6. Usability, Maintainability, Compatibility
- Usability: hệ thống dễ dùng đến đâu — ví dụ "người dùng mới hoàn tất đăng ký trong dưới 3 phút mà không cần hướng dẫn".
- Maintainability: dễ sửa, dễ thêm tính năng — đo bằng test coverage, độ phức tạp code, thời gian triển khai một thay đổi.
- Compatibility: chạy được trên trình duyệt/thiết bị/hệ điều hành nào — "hỗ trợ Chrome, Safari, Edge 2 phiên bản gần nhất; iOS 14+ và Android 9+".
Khung FURPS+ để không bỏ sót
Một mẹo để nhớ đủ nhóm NFR là khung FURPS+: Functionality, Usability, Reliability, Performance, Supportability, và dấu + cho các ràng buộc thêm (design, implementation, interface, physical). Khi rà soát tài liệu, đi qua từng chữ cái và tự hỏi: "Mình đã có yêu cầu đo được cho nhóm này chưa?"
Tình huống thực tế
Ví dụ 1 — Sàn TMĐT và cú sập ngày Mega Sale (bối cảnh Đông Nam Á)
Một sàn thương mại điện tử tại Việt Nam (gọi là ShopViet) chuẩn bị cho sự kiện sale ngày 11/11. Năm trước, lượng truy cập lúc 0 giờ tăng vọt gấp 12 lần so với ngày thường, hệ thống checkout sập 40 phút, ước tính mất khoảng 8 tỷ đồng doanh thu và vô số khách rời bỏ.
Năm nay, BA của ShopViet ngồi lại và viết NFR rõ ràng cho mùa sale: hệ thống checkout phải chịu peak 20.000 TPS, response time p95 dưới 1 giây, availability 99.95% trong khung 4 giờ vàng, và phải horizontal scale tự động khi CPU vượt 70%. Đặc biệt, họ thêm một NFR về graceful degradation: khi quá tải, các tính năng phụ (gợi ý sản phẩm, đánh giá) được tắt trước để dồn tài nguyên cho luồng thanh toán.
Kết quả: nhờ NFR cụ thể, đội kỹ thuật biết chính xác phải load test ở mức nào và chuẩn bị auto-scaling. Ngày 11/11 năm đó hệ thống trụ vững.
Bài học: NFR không phải tài liệu để cho có. Con số "20.000 TPS" và "p95 < 1s" trở thành tiêu chí nghiệm thu (acceptance criteria) cho khâu performance test. Không có con số thì không ai biết "đủ tốt" là bao nhiêu.
Ví dụ 2 — Ngân hàng số và bài học "số 9" đắt giá (bối cảnh Việt Nam)
Một ngân hàng số tại Việt Nam đặt mục tiêu availability 99.999% (năm số 9) cho toàn bộ hệ thống mobile banking, vì "ngân hàng thì phải luôn online". Khi BA ngồi với kiến trúc sư để phân tích, họ phát hiện ra để đạt năm số 9, cần multi-region active-active, đồng bộ dữ liệu xuyên vùng theo thời gian thực, và đội trực 24/7 — chi phí hạ tầng tăng thêm khoảng 40 tỷ đồng/năm.
BA đã làm đúng việc của mình: phân rã yêu cầu. Không phải mọi luồng đều cần năm số 9. Họ chia ra: luồng truy vấn số dư và chuyển khoản cần 99.99% (mất tối đa ~52 phút/năm), còn luồng xem lịch sử giao dịch và sao kê chỉ cần 99.9%. Tính năng mở thẻ tín dụng online thậm chí chấp nhận 99.5% vì không khẩn cấp. Nhờ phân tầng, chi phí giảm hơn một nửa mà trải nghiệm khách hàng quan trọng vẫn được bảo vệ.
Bài học: NFR cần được thương lượng dựa trên giá trị nghiệp vụ và chi phí, không phải đặt mức cao nhất cho mọi thứ. Vai trò của BA là làm cầu nối giữa kỳ vọng của business ("luôn online") và thực tế kỹ thuật ("mỗi số 9 đắt gấp nhiều lần"). Đây là lúc bạn thể hiện giá trị Technical BA.
Ví dụ 3 — Ứng dụng gọi xe và NFR về reliability (bối cảnh khu vực)
Một ứng dụng gọi xe (giả định là RideGo) gặp khiếu nại: app vẫn mở được (availability cao) nhưng tính năng định vị tài xế thỉnh thoảng trả về vị trí sai lệch hoặc đứng hình. Đội phát triển bối rối vì uptime báo cáo vẫn 99.9%.
Vấn đề là họ chỉ có NFR về availability mà thiếu NFR về reliability và data accuracy. BA bổ sung: vị trí tài xế phải cập nhật mỗi 3 giây với độ trễ p95 dưới 2 giây; tỷ lệ định vị sai lệch quá 50m phải dưới 0.5%; MTTR cho lỗi định vị dưới 5 phút. Khi có chỉ số rõ ràng, đội mới phát hiện nút thắt nằm ở một message queue bị nghẽn lúc cao điểm.
Bài học: Availability và reliability là hai thứ khác nhau. "Hệ thống có chạy" không đồng nghĩa với "hệ thống chạy đúng và ổn định". Một bộ NFR đầy đủ phải tách bạch hai khía cạnh này.
Hướng dẫn từng bước
Đây là quy trình thực dụng để bạn xây dựng bộ NFR cho một dự án:
Bước 1 — Xác định bối cảnh và phân loại hệ thống. Hệ thống này phục vụ ai, lưu lượng cỡ nào, có liên quan tiền/dữ liệu nhạy cảm không? Một hệ thống nội bộ 50 người dùng và một sàn TMĐT triệu user có NFR hoàn toàn khác nhau. Đừng copy NFR từ dự án cũ một cách máy móc.
Bước 2 — Đi qua từng nhóm NFR bằng khung FURPS+ hoặc danh sách chuẩn. Với mỗi nhóm (performance, scalability, availability, reliability, security, usability, maintainability, compatibility), tự hỏi: nhóm này có liên quan đến hệ thống không? Nếu có, mức yêu cầu là bao nhiêu?
Bước 3 — Lượng hóa mỗi yêu cầu. Đây là bước quan trọng nhất. Mỗi NFR phải có: chỉ số đo (metric), ngưỡng (threshold), và điều kiện (condition). Áp dụng nguyên tắc SMART. Ví dụ thay vì "hệ thống phải nhanh", viết: "95% request tra cứu đơn hàng trả về dưới 600ms khi có 1.500 phiên đồng thời."
Bước 4 — Gắn NFR với giá trị nghiệp vụ và chi phí. Với mỗi ngưỡng, hỏi business: nếu không đạt thì hậu quả là gì? Và hỏi kỹ thuật: để đạt thì tốn bao nhiêu? Đây là nơi bạn thương lượng để ra mức hợp lý (xem ví dụ ngân hàng số ở trên).
Bước 5 — Định nghĩa cách kiểm chứng. Mỗi NFR phải kèm phương pháp đo: load test bằng JMeter/k6 cho performance, chaos testing cho reliability, audit log cho security. Một NFR không kiểm chứng được thì vô nghĩa.
Bước 6 — Đưa NFR vào Definition of Done và acceptance criteria. NFR phải là một phần của tiêu chí nghiệm thu, không phải phụ lục bị bỏ quên. Tính năng chưa pass performance test thì chưa "done".
Lỗi thường gặp & mẹo
Lỗi 1 — Viết NFR mơ hồ, không đo được. "Hệ thống phải thân thiện với người dùng", "phải có hiệu năng cao", "phải bảo mật". Đây là những câu vô dụng vì không ai kiểm chứng được. Mẹo: với mỗi NFR, hỏi "làm sao tester chứng minh điều này pass hay fail?". Nếu không trả lời được bằng con số, NFR chưa đạt.
Lỗi 2 — Dùng giá trị trung bình thay vì percentile. "Thời gian phản hồi trung bình 200ms" nghe đẹp nhưng vô nghĩa nếu p99 là 5 giây. Mẹo: luôn dùng p95/p99 cho response time. Trung bình che giấu các đuôi dài (long tail) — chính những request chậm này mới làm khách bực.
Lỗi 3 — Đặt mọi NFR ở mức cao nhất. Yêu cầu năm số 9 và p95 < 100ms cho mọi tính năng nghe "an toàn" nhưng đẩy chi phí lên trời và thường bất khả thi. Mẹo: phân tầng NFR theo mức độ quan trọng nghiệp vụ. Luồng critical mức cao, luồng phụ mức thấp hơn.
Lỗi 4 — Quên điều kiện tải. "API trả về dưới 300ms" — dưới tải nào? 10 user hay 10.000 user? Mẹo: mọi NFR về performance phải kèm điều kiện về concurrency hoặc throughput.
Lỗi 5 — Bỏ NFR đến cuối dự án. NFR thường bị xem là "phần kỹ thuật, để sau". Nhưng nhiều NFR (như scalability, availability) ảnh hưởng trực tiếp đến kiến trúc — sửa sau khi đã build xong cực kỳ đắt. Mẹo: thu thập NFR ngay từ giai đoạn đầu, song song với functional requirements.
Lỗi 6 — Nhầm lẫn availability với reliability. Như ví dụ RideGo, hai khái niệm này tách biệt. Mẹo: hỏi cả hai câu — "hệ thống có chạy không?" và "hệ thống chạy có đúng và ổn định không?".
Bài tập thực hành
Bài tập 1 — Biến mơ hồ thành đo được. Cho 3 câu NFR mơ hồ sau, hãy viết lại thành NFR đo được (có metric, threshold, condition):
- "Trang chủ phải load nhanh."
- "Hệ thống phải luôn sẵn sàng."
- "Việc tìm kiếm sản phẩm phải mượt."
Bài tập 3 — Rà soát bằng FURPS+. Lấy một tính năng bạn quen thuộc (ví dụ: chức năng đăng nhập). Đi qua từng nhóm FURPS+ và viết ít nhất một NFR đo được cho mỗi nhóm áp dụng được. Sau đó tự hỏi: NFR nào bạn dễ quên nhất nếu không có khung này?
Bài tập 4 — Định nghĩa cách kiểm chứng. Với mỗi NFR bạn viết ở bài tập 1, hãy mô tả ngắn gọn: dùng công cụ/phương pháp gì để kiểm chứng, và pass/fail dựa trên tiêu chí nào?
Tóm tắt
Non-Functional Requirements là yêu cầu về chất lượng và vận hành — trả lời câu hỏi hệ thống làm chức năng tốt đến mức nào, chứ không phải làm gì. Với Technical BA, đây là nơi tạo khác biệt rõ rệt và cũng là nguyên nhân hàng đầu khiến dự án thất bại lúc go-live nếu bị bỏ quên.
Những điểm cốt lõi cần nhớ:
- Các nhóm NFR chính: Performance (response time theo percentile, throughput), Scalability (vertical/horizontal), Availability (số 9 và downtime tương ứng), Reliability (MTBF, MTTR, RPO, RTO), Security, và Usability/Maintainability/Compatibility.
- Một NFR tốt luôn đo được: có metric, threshold và condition. Câu "phải nhanh" không phải NFR; "p95 < 600ms với 1.500 phiên đồng thời" mới là.
- Luôn dùng percentile (p95/p99) thay vì trung bình cho response time.
- Phân tầng NFR theo giá trị nghiệp vụ — không đặt mọi thứ ở mức cao nhất, vì mỗi "số 9" đắt theo cấp số nhân.
- Phân biệt rõ availability (có chạy không) và reliability (chạy có đúng và ổn định không).
- Dùng khung FURPS+ để rà soát không bỏ sót, và đưa NFR vào acceptance criteria ngay từ đầu dự án.