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. Chức năng nào cũng chạy: chọn ghế được, thanh toán được, gửi mã QR về email được. Đội QA test từng kịch bản, tất cả đều "pass". Thế nhưng đến đêm công chiếu bom tấn, 50.000 người cùng vào đặt vé trong 10 phút, hệ thống treo cứng, giao dịch trừ tiền nhưng không trả vé, khách hàng tràn lên fanpage chửi. Về mặt chức năng, hệ thống của bạn đúng. Về mặt vận hành thực tế, nó thất bại hoàn toàn.
Cái thiếu ở đây chính là Non-Functional Requirements (NFR) — yêu cầu phi chức năng. Đây là lằn ranh phân biệt một BA viết spec "cho có" với một Technical BA thực thụ. Functional requirements trả lời câu hỏi "hệ thống làm được gì", còn NFR trả lời câu hỏi khó hơn nhiều: "hệ thống làm việc đó tốt đến mức nào" — nhanh ra sao, chịu tải bao nhiêu, an toàn cỡ nào, khôi phục sau sự cố mất bao lâu.
Trong suốt khóa Technical BA Masterclass này, NFR là sợi chỉ đỏ xuyên suốt: khi bạn thiết kế database, viết API spec, chọn kiến trúc, hay đánh giá rủi ro kỹ thuật — tất cả đều quay về những con số NFR mà bạn đặt ra hôm nay. Vì vậy, đây là bài học nền tảng. Nắm chắc nó, bạn sẽ thôi viết những dòng spec mơ hồ kiểu "hệ thống phải nhanh" và bắt đầu viết những yêu cầu mà kỹ sư có thể đo lường, kiểm thử, và nghiệm thu.
Khái niệm cốt lõi
Functional vs Non-Functional — phân biệt rõ ràng
Functional Requirements (FR) mô tả hành vi của hệ thống — những việc hệ thống phải làm để phục vụ nghiệp vụ:
- Người dùng đăng nhập bằng số điện thoại và OTP.
- Hệ thống tìm kiếm sản phẩm theo từ khóa.
- Hệ thống tính tổng đơn hàng và áp mã giảm giá.
- Đăng nhập phải hoàn tất trong vòng 2 giây ở phân vị 95 (95% người dùng được phục vụ dưới 2 giây).
- Trang tìm kiếm phải chịu được 3.000 lượt truy vấn đồng thời mà thời gian phản hồi không vượt 800ms.
- Hệ thống phải đạt độ sẵn sàng 99,9% trong một tháng (downtime tối đa ~43 phút/tháng).
Các nhóm NFR quan trọng nhất
NFR có nhiều cách phân loại, nhưng một Technical BA cần nắm chắc các nhóm sau:
1. Performance (Hiệu năng) — Tốc độ và thông lượng. Gồm:
- Response time / Latency: thời gian hệ thống trả lời một yêu cầu.
- Throughput: số giao dịch xử lý được mỗi giây (TPS) hoặc mỗi phút.
- Resource utilization: mức dùng CPU, RAM, băng thông ở tải bình thường.
2. Scalability (Khả năng mở rộng) — Hệ thống lớn lên thế nào khi tải tăng. Phân biệt scale up (nâng cấp máy mạnh hơn) và scale out (thêm nhiều máy). NFR scalability thường gắn với mốc tăng trưởng: "hỗ trợ 100.000 người dùng hoạt động hằng ngày năm nay, mở rộng tới 1 triệu trong 18 tháng mà không phải viết lại kiến trúc".
3. Availability & Reliability (Độ sẵn sàng & Độ tin cậy) — Đây là nhóm hay bị nhầm. Availability là phần trăm thời gian hệ thống hoạt động (đo bằng "số 9"). Reliability là khả năng chạy đúng không lỗi trong một khoảng thời gian (đo bằng MTBF — mean time between failures, MTTR — mean time to recovery). Bảng "số 9" mà mọi BA nên thuộc lòng:
| Mức availability | Downtime/năm | Downtime/tháng |
|---|---|---|
| 99% (hai số 9) | ~3,65 ngày | ~7,2 giờ |
| 99,9% (ba số 9) | ~8,76 giờ | ~43 phút |
| 99,99% (bốn số 9) | ~52 phút | ~4,3 phút |
| 99,999% (năm số 9) | ~5,26 phút | ~26 giây |
5. Usability (Tính khả dụng) — Có thể đo: người dùng mới hoàn tất quy trình đặt hàng lần đầu trong dưới 3 phút; tỉ lệ thao tác lỗi dưới 2%; hỗ trợ màn hình từ 360px.
6. Maintainability & Portability (Khả năng bảo trì & chuyển đổi) — Thời gian onboard kỹ sư mới, độ phủ test tối thiểu, khả năng triển khai trên cloud khác nhau.
7. Compliance (Tuân thủ) — Ràng buộc pháp lý. Ở Việt Nam, Nghị định 13/2023/NĐ-CP về bảo vệ dữ liệu cá nhân buộc nhiều hệ thống phải lưu trữ và xử lý dữ liệu người dùng theo quy định cụ thể — đây là NFR bắt buộc, không phải "nên có".
Đặc tính của một NFR tốt: SMART và đo lường được
NFR tệ: "Hệ thống phải nhanh và an toàn." Câu này vô nghĩa vì không ai nghiệm thu được. NFR tốt phải đo lường được, gắn điều kiện rõ ràng, và kiểm thử được:
> "Ở tải 2.000 người dùng đồng thời, API tra cứu số dư phải trả về kết quả với p95 ≤ 600ms và p99 ≤ 1.200ms, đo trong 30 phút liên tục, tỉ lệ lỗi < 0,1%."
Câu này có: ngữ cảnh tải, chỉ số (percentile), ngưỡng cụ thể, thời gian đo, và tiêu chí lỗi. Kỹ sư có thể dựng test, QA có thể nghiệm thu, và bạn có thể đưa vào hợp đồng SLA.
Tình huống thực tế
Tình huống 1 — Sàn thương mại điện tử và đêm flash sale
Một sàn TMĐT giả định tên ShopViet chuẩn bị cho đợt sale 12/12. Năm trước, BA chỉ viết FR: "Người dùng thêm sản phẩm vào giỏ và thanh toán." Hệ thống chạy ổn ngày thường với khoảng 500 đơn/phút. Đến 0h ngày sale, lưu lượng vọt lên 40 lần. Trang chủ load 15 giây, nút "Mua ngay" bấm không phản hồi, hàng tồn kho bị bán âm (oversold) vì hệ thống không xử lý kịp tranh chấp đồng thời. Ước tính thiệt hại doanh thu một đêm hơn 4 tỉ đồng, chưa kể uy tín.
Năm sau, Technical BA vào cuộc và bổ sung NFR rõ ràng:
- Scalability: "Hệ thống phải auto-scale để xử lý đỉnh 20.000 đơn/phút trong khung 0h–2h ngày sale."
- Performance: "Thời gian load trang sản phẩm p95 ≤ 1,5s ở tải đỉnh."
- Reliability: "Không cho phép oversold — tồn kho phải nhất quán dưới điều kiện 5.000 yêu cầu đặt mua đồng thời cho cùng một SKU."
Tình huống 2 — Ngân hàng số và yêu cầu "ba số chín rưỡi"
Một ngân hàng số tại Việt Nam (tạm gọi NeoBank) ký hợp đồng với đối tác core banking. Trong hồ sơ thầu, BA của ngân hàng viết NFR availability cho dịch vụ chuyển khoản: 99,95% mỗi tháng, tức downtime tối đa chỉ khoảng 21,9 phút/tháng. Quan trọng hơn, họ tách riêng yêu cầu:
- RTO (Recovery Time Objective): khi sự cố nghiêm trọng, dịch vụ phải khôi phục trong ≤ 15 phút.
- RPO (Recovery Point Objective): dữ liệu giao dịch mất tối đa tương ứng 0 giây — không được mất bất kỳ giao dịch tiền nào đã xác nhận.
Bài học: NFR là công cụ thương lượng và quản trị rủi ro, không chỉ là yêu cầu kỹ thuật. Khi bạn viết RTO/RPO và mức availability bằng con số, bạn biến những kỳ vọng mơ hồ thành điều khoản hợp đồng có thể chế tài. Đây chính là lý do Technical BA phải hiểu sự khác biệt giữa availability, reliability, RTO và RPO.
Tình huống 3 — Ứng dụng gọi xe và bài học latency
Một startup gọi xe ở Đông Nam Á phát hiện tỉ lệ tài xế nhận chuyến giảm dần ở khung giờ cao điểm. Đào sâu mới thấy: API tính giá và ghép chuyến có latency trung bình 400ms — nghe rất ổn. Nhưng khi nhìn p99, con số là 4,2 giây. Cứ 100 chuyến thì có 1 chuyến mà tài xế phải chờ hơn 4 giây, đủ để họ bực mình tắt app hoặc khách hủy.
Đội sản phẩm đặt lại NFR: "p99 của API ghép chuyến ≤ 800ms ở tải giờ cao điểm." Kỹ sư tối ưu lại truy vấn và thêm cache, kéo p99 xuống 700ms. Tỉ lệ hủy chuyến do chờ lâu giảm rõ rệt.
Bài học: "Trung bình" là kẻ nói dối. Một Technical BA giỏi luôn yêu cầu chỉ số theo percentile, vì trải nghiệm tệ nhất của nhóm người dùng "đuôi dài" mới là thứ phá hỏng danh tiếng sản phẩm.
Hướng dẫn từng bước
Đây là quy trình để bạn moi ra và viết NFR một cách bài bản:
Bước 1 — Bắt đầu từ ngữ cảnh nghiệp vụ và rủi ro. Hỏi: "Điều gì sẽ xảy ra nếu phần này chậm/sập/bị lộ dữ liệu?" Mỗi rủi ro nghiêm trọng thường ám chỉ một NFR. Hệ thống thanh toán mà sập 1 giờ thì mất bao nhiêu tiền? Câu trả lời định ra mức availability bạn cần.
Bước 2 — Phỏng vấn đúng người với câu hỏi định lượng. Đừng hỏi "anh muốn hệ thống nhanh không" (ai cũng trả lời có). Hãy hỏi: "Vào ngày bận nhất năm, bao nhiêu người dùng cùng lúc?", "Người dùng chờ tối đa bao lâu trước khi bỏ?", "Pháp chế yêu cầu lưu log bao lâu?". Nguồn dữ liệu: số liệu lịch sử (analytics), bộ phận vận hành, đội bảo mật, và phòng pháp chế.
Bước 3 — Lượng hóa từng yêu cầu. Biến mọi mong muốn mơ hồ thành con số có đơn vị, có ngữ cảnh tải, có percentile. "Nhanh" → "p95 ≤ 1s ở 1.000 user đồng thời".
Bước 4 — Gắn NFR vào từng phần hệ thống, đừng để chung chung. Không phải mọi API đều cần p99 dưới 500ms. API tra cứu số dư cần nhanh; API xuất báo cáo cuối tháng có thể chấp nhận 30 giây. Phân tầng NFR theo mức độ quan trọng (critical / standard / background) giúp tiết kiệm chi phí hạ tầng rất nhiều.
Bước 5 — Định nghĩa cách kiểm thử và nghiệm thu. Với mỗi NFR, ghi rõ: đo bằng công cụ gì, trong điều kiện nào, ngưỡng pass/fail là bao nhiêu. Một NFR không kiểm thử được thì không phải NFR — nó chỉ là lời chúc.
Bước 6 — Đưa vào tài liệu và đối chiếu với SLA/hợp đồng. NFR của bạn phải nhất quán với cam kết SLA với khách hàng và với nhà cung cấp hạ tầng. Nếu bạn cam kết 99,99% nhưng nhà cung cấp cloud chỉ bảo đảm 99,9%, bạn đang hứa thứ không kiểm soát được.
Bước 7 — Rà soát lại định kỳ. NFR không bất biến. Khi lượng người dùng tăng gấp đôi, các con số tải phải được cập nhật lại.
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à nhanh." Đây là lỗi phổ biến nhất. Mẹo: nếu QA không thể viết một test case để nghiệm thu câu đó, nó chưa phải NFR.
Lỗi 2 — Dùng giá trị trung bình thay vì percentile. Như tình huống gọi xe, trung bình che giấu trải nghiệm tệ. Mẹo: mặc định dùng p95/p99 cho mọi yêu cầu hiệu năng.
Lỗi 3 — Bỏ quên NFR cho đến cuối dự án. NFR phát hiện muộn thường buộc viết lại kiến trúc — cực kỳ tốn kém. Mẹo: thu thập NFR ngay từ giai đoạn phân tích, song song với FR.
Lỗi 4 — "Gold-plating" NFR. Đòi 99,999% availability cho một blog nội bộ là lãng phí khủng khiếp — mỗi "số 9" tăng thêm khiến chi phí hạ tầng tăng theo cấp số. Mẹo: cân bằng giữa nhu cầu nghiệp vụ thực và chi phí. Hỏi "khách hàng có thực sự trả tiền cho mức này không?".
Lỗi 5 — Nhầm availability với reliability, hoặc RTO với RPO. Mẹo nhớ: Availability = "bao nhiêu phần trăm thời gian hệ thống sống". RTO = "mất bao lâu để hồi sinh sau sự cố". RPO = "được phép mất bao nhiêu dữ liệu". Ba thứ khác nhau, đừng gộp.
Lỗi 6 — Không đặt ngữ cảnh tải. "p95 ≤ 1s" mà không nói ở bao nhiêu user đồng thời thì vô nghĩa, vì 1s ở 10 user khác hẳn 1s ở 10.000 user. Luôn kèm điều kiện tải.
Bài tập thực hành
Bài 1 — Lượng hóa NFR. Cho yêu cầu mơ hồ: "Tính năng tìm kiếm khách sạn phải nhanh và luôn hoạt động." Hãy viết lại thành 3 NFR đo lường được, mỗi câu phải có: chỉ số, ngưỡng, percentile (nếu là performance), điều kiện tải, và cách nghiệm thu.
Bài 2 — Tính downtime. Một dịch vụ cam kết availability 99,95%/tháng. Tính downtime tối đa cho phép trong một tháng (giả định 30 ngày). Nếu trong tháng này hệ thống đã sập 18 phút, đội vận hành còn "ngân sách downtime" bao nhiêu phút trước khi vi phạm SLA?
Bài 3 — Phân tầng NFR. Cho một app ngân hàng có ba nhóm chức năng: (a) chuyển tiền, (b) xem lịch sử giao dịch, (c) xuất sao kê PDF cuối tháng. Hãy đề xuất mức performance và availability phù hợp cho từng nhóm, và giải thích vì sao không nên áp cùng một mức cho cả ba.
Bài 4 — Phỏng vấn stakeholder. Viết 5 câu hỏi định lượng bạn sẽ hỏi để thu thập NFR cho một hệ thống bán vé tàu Tết — thời điểm tải cực cao và nhạy cảm về công bằng (tránh một người ôm hết vé).
Tóm tắt
Non-Functional Requirements là phần "chất lượng" của hệ thống — trả lời câu hỏi hệ thống làm việc tốt đến mức nào, bổ sung cho Functional Requirements vốn chỉ nói hệ thống làm gì. Một hệ thống đúng 100% chức năng vẫn có thể thất bại thảm hại nếu bỏ quên NFR, như ví dụ rạp phim và sàn TMĐT đầu bài.
Những điểm cốt lõi cần nhớ:
- Bảy nhóm NFR chính: Performance, Scalability, Availability/Reliability, Security, Usability, Maintainability, Compliance.
- NFR tốt phải đo lường được: có chỉ số, ngưỡng, percentile, điều kiện tải, và cách nghiệm thu. Nếu QA không test được, nó chưa phải NFR.
- Dùng percentile, không dùng trung bình — vì trải nghiệm "đuôi dài" (p99) mới phá hỏng sản phẩm.
- Thuộc lòng bảng "số 9" và phân biệt rõ availability, reliability, RTO, RPO.
- Thu thập NFR sớm, phân tầng theo mức quan trọng, và tránh gold-plating gây lãng phí chi phí.