Mở đầu — vì sao bài này quan trọng
Hãy hình dung thế này: bạn vừa làm BA cho một dự án ngân hàng số. Đội dev xây xong tính năng chuyển khoản, demo chạy mượt mà, mọi user story đều pass. Khách hàng ký nghiệm thu. Ba tháng sau, vào ngày 30 Tết, lượng giao dịch tăng gấp 8 lần, hệ thống treo, người dùng không chuyển được tiền lì xì, và app bị bão 1 sao trên App Store. Tất cả các yêu cầu chức năng (functional requirements) đều đúng — nhưng hệ thống vẫn thất bại.
Vấn đề nằm ở chỗ không ai đặc tả rõ: "Hệ thống phải xử lý được bao nhiêu giao dịch mỗi giây? Thời gian phản hồi tối đa là bao lâu? Uptime cam kết là bao nhiêu?" Đó chính là 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 "hệ thống làm việc đó TỐT đến mức nào".
Với bạn — người từ QA/Tester chuyển sang BA — đây là một mảnh đất cực kỳ màu mỡ, và đây là lý do tôi muốn nhấn mạnh: trong suốt quãng đời QA, bạn đã từng viết test cho performance, từng chạy load test bằng JMeter, từng log những bug kiểu "trang load 12 giây", từng phát hiện hệ thống crash khi 500 user đăng nhập cùng lúc. Bạn đã sống chung với NFR mà có khi không gọi đúng tên nó. Khi chuyển sang BA, kỹ năng cảm nhận "ngưỡng chất lượng" này biến thành một siêu năng lực. Hầu hết BA xuất thân từ nghiệp vụ thuần (business) rất yếu về NFR — họ viết requirement chức năng rất tốt nhưng bỏ trống hoàn toàn phần phi chức năng. Bạn thì khác. Bài này sẽ giúp bạn hệ thống hóa mảng kiến thức đó để trở thành điểm mạnh khác biệt trong sự nghiệp BA.
Khái niệm cốt lõi
NFR là gì và vì sao thường bị bỏ quên
NFR mô tả các thuộc tính chất lượng (quality attributes) của hệ thống — những đặc tính ràng buộc cách hệ thống vận hành chứ không phải hành vi cụ thể. Một functional requirement viết: "Người dùng có thể tìm kiếm sản phẩm theo từ khóa". Một NFR đi kèm sẽ viết: "Kết quả tìm kiếm phải trả về trong vòng 2 giây với 95% các truy vấn, khi hệ thống đang phục vụ 10.000 người dùng đồng thời".
NFR thường bị bỏ quên vì ba lý do: (1) nó không hiện ra trên màn hình nên stakeholder ít nghĩ tới; (2) nó khó định lượng nếu không có kinh nghiệm; (3) hậu quả của việc thiếu nó chỉ lộ ra khi đã quá muộn — lúc lên production. Đây chính là chỗ tư duy QA của bạn phát huy: bạn quen nghĩ tới "điều gì sẽ vỡ" hơn là "điều gì sẽ chạy".
Khung FURPS+
Để không bỏ sót, ngành phần mềm dùng nhiều khung phân loại. Phổ biến nhất trong giới BA là FURPS+, do Robert Grady (HP) đưa ra, và bản nâng cấp ISO/IEC 25010. Tôi sẽ đi qua FURPS+ vì nó dễ nhớ và bạn có thể dùng như một checklist khi viết requirement.
FURPS là viết tắt của năm nhóm, cộng thêm dấu "+" cho các ràng buộc bổ sung:
1. Functionality (Chức năng). Đây là phần functional, nhưng trong FURPS nó còn bao gồm các thuộc tính như bảo mật (security), khả năng tương tác (interoperability) và tính năng phụ. Lưu ý: security trong nhiều mô hình hiện đại được tách thành NFR riêng. Ví dụ NFR security: "Mọi mật khẩu phải được hash bằng bcrypt với cost factor tối thiểu 12; phiên đăng nhập tự hết hạn sau 15 phút không hoạt động".
2. Usability (Khả năng sử dụng). Hệ thống dễ dùng đến mức nào — bao gồm tính nhất quán giao diện, tài liệu hướng dẫn, và đặc biệt là khả năng tiếp cận (accessibility) theo chuẩn WCAG 2.1. WCAG (Web Content Accessibility Guidelines) có ba mức A, AA, AAA. Đa số dự án thương mại nhắm mức AA. Ví dụ NFR usability: "Toàn bộ form nhập liệu phải đạt WCAG 2.1 mức AA — độ tương phản màu chữ tối thiểu 4.5:1, mọi thao tác thực hiện được bằng bàn phím, có nhãn aria cho screen reader". Với người Việt làm dự án cho khách Nhật, Âu, Mỹ thì WCAG gần như bắt buộc trong hợp đồng.
3. Reliability (Độ tin cậy). Hệ thống ổn định và chịu lỗi tốt đến đâu. Hai chỉ số bạn phải thuộc lòng:
- Uptime / Availability: thường viết dạng "số chín". 99,9% (three nines) nghĩa là được phép sập tối đa ~8,77 giờ/năm. 99,99% (four nines) chỉ cho phép ~52,6 phút/năm. Đừng viết "hệ thống phải luôn online" — vô nghĩa và không test được.
- MTBF (Mean Time Between Failures) — thời gian trung bình giữa hai lần lỗi, và MTTR (Mean Time To Recovery) — thời gian trung bình để phục hồi. Ví dụ: "MTTR cho sự cố nghiêm trọng (P1) không vượt quá 30 phút".
4. Performance (Hiệu năng). Đây là sân nhà của bạn nếu từng làm performance testing. Bốn chỉ số chính:
- Latency / Response time: thời gian phản hồi một thao tác. Thường đặc tả theo percentile, ví dụ "p95 < 500ms" (95% request nhanh hơn 500ms) thay vì lấy trung bình — vì trung bình che giấu các trường hợp tệ.
- Throughput: số lượng giao dịch xử lý được trong một đơn vị thời gian, ví dụ "2.000 TPS — transactions per second".
- Concurrency: số người dùng đồng thời hệ thống chịu được.
- Resource utilization: mức dùng CPU, RAM, băng thông ở tải đỉnh.
Dấu "+" gom các ràng buộc còn lại: Design constraints (ràng buộc thiết kế), Implementation (ngôn ngữ, công nghệ bắt buộc), Interface (giao tiếp hệ thống ngoài), Physical (phần cứng), và đặc biệt quan trọng ở Việt Nam: Legal/Compliance — tuân thủ pháp lý như PDPD (Nghị định 13/2023 về bảo vệ dữ liệu cá nhân) hay GDPR cho khách châu Âu. Đây là cầu nối sang Bài 36 về compliance, nên ở đây tôi chỉ điểm danh.
Đặc điểm của một NFR tốt: phải đo được
Quy tắc vàng: một NFR không đo được là một NFR vô dụng. "Hệ thống phải nhanh" là một lời than vãn, không phải requirement. "Trang chủ phải tải xong (Largest Contentful Paint) dưới 2,5 giây trên mạng 4G ở khu vực TP.HCM, đo bằng Lighthouse, đạt với 90% lượt truy cập" mới là một NFR. Mỗi NFR tốt cần có: chỉ số (metric), giá trị mục tiêu (target), điều kiện đo (context/load), và cách đo (measurement method). Đây chính xác là cấu trúc bạn từng dùng khi viết test case — chỉ đổi tên gọi.
Tình huống thực tế
Ví dụ 1 — Ví điện tử mùa cao điểm (bối cảnh Việt Nam)
Một ví điện tử lớn tại Việt Nam (tạm gọi là "ViPay") triển khai tính năng lì xì online dịp Tết. Functional requirement rất rõ: người dùng tạo bao lì xì, nạp tiền, gửi cho bạn bè. Demo hoàn hảo. Nhưng BA của dự án — vốn xuất thân từ nghiệp vụ tài chính — không viết NFR về tải.
Đêm Giao thừa, lượng giao dịch nhảy từ ~3.000 TPS ngày thường lên ~25.000 TPS trong khung 22h–0h30. Hệ thống thiết kế chỉ chịu được 8.000 TPS. Kết quả: hàng đợi nghẽn, nhiều người bị trừ tiền nhưng bao lì xì không tới, bộ phận CSKH ngập trong khiếu nại, và đội kỹ thuật phải làm reconciliation (đối soát) thủ công suốt mùng 1.
Khi review post-mortem, một BA mới — xuất thân QA — đề xuất bổ sung bộ NFR: "Hệ thống phải chịu tải đỉnh 30.000 TPS với p95 response time < 800ms trong khung giờ cao điểm; khi quá tải phải xếp hàng có kiểm soát (graceful degradation) thay vì trả lỗi; mọi giao dịch trừ tiền nhưng thất bại phải tự động hoàn (auto-refund) trong 5 phút". Năm sau, với NFR này làm kim chỉ nam, đội kỹ thuật chủ động load test trước Tết và hệ thống trụ vững.
Bài học: functional đúng 100% vẫn có thể là dự án thất bại. Người có tư duy "điều gì sẽ vỡ ở tải đỉnh" — chính là tư duy QA — là người đáng giá nhất trong phòng họp requirement.
Ví dụ 2 — Dự án outsource cho khách Đức và bẫy WCAG (bối cảnh Đông Nam Á)
Một công ty outsource ở TP.HCM nhận dự án xây cổng thông tin nội bộ cho một tập đoàn Đức. Hợp đồng có một dòng nhỏ: "tuân thủ accessibility theo quy định EU". Đội Việt Nam tập trung làm chức năng, bỏ qua dòng đó vì nghĩ nó "không quan trọng".
Đến lúc nghiệm thu, khách hàng thuê một bên thứ ba audit theo WCAG 2.1 AA. Sản phẩm fail hàng loạt: độ tương phản màu không đạt, không dùng được bằng bàn phím, ảnh thiếu alt text, video thiếu phụ đề. Theo luật của Đức (BITV, dựa trên EU Directive 2016/2102), cổng thông tin loại này bắt buộc đạt accessibility. Đội Việt Nam phải rework gần như toàn bộ frontend, trễ deadline 6 tuần và bị phạt hợp đồng.
BA mới của dự án — từng làm QA và quen kiểm thử accessibility bằng công cụ axe DevTools — đã viết lại bộ NFR usability ngay từ giai đoạn đầu cho phase 2: liệt kê cụ thể từng tiêu chí WCAG 2.1 AA áp dụng, kèm cách verify (dùng axe, kiểm tra bằng screen reader NVDA, test điều hướng bàn phím). Phase 2 pass audit ngay lần đầu.
Bài học: NFR mơ hồ trong hợp đồng ("tuân thủ accessibility") là quả bom hẹn giờ. BA phải dịch nó thành tiêu chí đo được. Và kinh nghiệm QA về test accessibility giúp bạn biết chính xác cần đặc tả gì.
Ví dụ 3 — SLA và "số chín" trong dự án SaaS y tế
Một startup Việt làm phần mềm quản lý phòng khám (SaaS) ký hợp đồng với chuỗi phòng khám, cam kết SLA uptime "99,9%". Nghe thì oai, nhưng BA non kinh nghiệm không tính ra con số thực: 99,9% nghĩa là được sập tối đa 43,8 phút/tháng. Hệ thống thực tế phải bảo trì định kỳ 2 tiếng mỗi tháng — đã vượt xa hạn mức, chưa kể sự cố ngoài ý muốn.
Hậu quả: tháng nào cũng vi phạm SLA, phải bồi thường (service credit) cho khách. BA đã không phân biệt planned downtime (bảo trì có kế hoạch) với unplanned downtime. Một BA giỏi sẽ đàm phán: "99,9% uptime tính trên giờ hoạt động, loại trừ cửa sổ bảo trì được thông báo trước 48h trong khung 2h–4h sáng Chủ nhật". Cùng một con số "99,9%" nhưng định nghĩa khác nhau hoàn toàn về mặt nghĩa vụ.
Bài học: với NFR về reliability, ma quỷ nằm ở định nghĩa và điều kiện biên. Đừng chỉ chép con số — hãy làm rõ nó đo trên cái gì, loại trừ những gì.
Hướng dẫn từng bước
Đây là quy trình thực dụng để khai thác và viết NFR cho một tính năng bất kỳ.
Bước 1 — Lấy functional requirement làm điểm xuất phát. Với mỗi user story hay tính năng, hỏi: "Tính năng này cần chạy NHANH tới đâu, ỔN ĐỊNH tới đâu, AN TOÀN tới đâu, DỄ DÙNG tới đâu?". Mỗi câu hỏi tương ứng một nhóm FURPS.
Bước 2 — Dùng FURPS+ làm checklist quét. Đi qua lần lượt 5+1 nhóm. Tự hỏi từng nhóm có ràng buộc gì không. Tư duy QA giúp bạn ở đây: với mỗi nhóm, tưởng tượng kịch bản hệ thống vỡ — đó chính là NFR cần đặc tả.
Bước 3 — Định lượng mỗi NFR theo công thức 4 thành phần. Mỗi NFR phải có: Metric (đo cái gì) + Target (giá trị mục tiêu) + Condition (trong điều kiện tải/môi trường nào) + Measurement (đo bằng công cụ/cách nào). Thiếu một thành phần là NFR chưa hoàn chỉnh.
Bước 4 — Lấy số mục tiêu từ đúng nguồn. Đừng bịa con số. Số đến từ: dữ liệu vận hành hiện tại (analytics, log), benchmark đối thủ, ràng buộc hợp đồng/SLA, quy định pháp lý, và khả năng hạ tầng. Hỏi stakeholder kinh doanh "đỉnh tải mùa cao điểm gấp mấy lần ngày thường" là câu hỏi vàng.
Bước 5 — Phối hợp với kiến trúc sư và đội kỹ thuật để kiểm chứng tính khả thi. NFR "p99 < 10ms" nghe hay nhưng có thể bất khả thi với kiến trúc hiện tại hoặc đội tiền 10 lần. NFR phải vừa tham vọng vừa thực tế.
Bước 6 — Gắn NFR vào Acceptance Criteria và kế hoạch test. Đây là nơi nền QA của bạn tỏa sáng: mỗi NFR phải có một cách verify rõ ràng. NFR không có test tương ứng sẽ không bao giờ được kiểm chứng và sẽ rơi vào quên lãng.
Bước 7 — Ưu tiên hóa. Không phải NFR nào cũng ngang nhau. Với hệ thống thanh toán, security và data integrity là sống còn; với landing page marketing, performance và usability quan trọng hơn. Dùng MoSCoW để phân loại Must/Should/Could.
Lỗi thường gặp & mẹo
Lỗi 1 — Viết NFR không đo được. "Hệ thống phải thân thiện, nhanh, ổn định". Đây là điều ước, không phải requirement. Mẹo: mỗi khi viết một tính từ (nhanh, ổn, an toàn), tự ép mình gắn ngay một con số và đơn vị phía sau.
Lỗi 2 — Dùng giá trị trung bình thay vì percentile. "Response time trung bình 300ms" che giấu việc 5% người dùng phải chờ 8 giây. Luôn ưu tiên p95/p99 cho các NFR performance — đây là điều dân QA performance hiểu rõ mà BA thuần nghiệp vụ thường bỏ qua.
Lỗi 3 — Quên điều kiện tải. "Tải trang dưới 2 giây" — với 1 user hay 10.000 user đồng thời? Trên 4G hay wifi? NFR không có context là vô nghĩa.
Lỗi 4 — Copy SLA mà không hiểu nghĩa. Như ví dụ 3, ghi "99,99%" cho oai rồi không đủ năng lực đáp ứng. Luôn quy đổi "số chín" ra số phút/giờ downtime thực tế trước khi cam kết.
Lỗi 5 — Đặc tả NFR quá muộn. NFR ảnh hưởng tới kiến trúc. Một hệ thống thiết kế cho 1.000 user rất khó "vá" để chịu 100.000 user. NFR phải xuất hiện từ giai đoạn đầu, không phải khi sắp release.
Mẹo tận dụng nền QA: Giữ một thư viện NFR cá nhân — mỗi lần bạn từng log bug về performance, security hay usability ở thời QA, hãy chuyển nó thành một mẫu NFR. Dần dần bạn có một checklist NFR thực chiến mà ít BA nào có. Ngoài ra, làm quen với ISO/IEC 25010 (phiên bản hiện đại hơn FURPS, gồm 8 nhóm: functional suitability, performance efficiency, compatibility, usability, reliability, security, maintainability, portability) để dùng khi làm việc với khách hàng quốc tế đòi hỏi chuẩn chính thống.
Bài tập thực hành
Bài 1 — Chuyển bug thành NFR. Lấy 3 bug performance/security/usability bạn từng gặp thời QA (hoặc giả định). Với mỗi bug, viết một NFR đủ 4 thành phần (Metric + Target + Condition + Measurement) để ngăn bug đó tái diễn ở cấp requirement.
Bài 2 — Quét FURPS+ cho một tính năng. Chọn tính năng "đăng nhập bằng OTP qua SMS" của một app ngân hàng. Đi qua từng nhóm FURPS+ và viết ít nhất một NFR đo được cho mỗi nhóm (Functionality/Security, Usability, Reliability, Performance, Supportability, và một ràng buộc Legal theo PDPD).
Bài 3 — Quy đổi số chín. Tính chính xác số phút downtime tối đa mỗi tháng cho các mức 99%, 99,9%, 99,95%, 99,99%. Sau đó viết một câu cam kết SLA có loại trừ planned maintenance, đủ chặt chẽ để dùng trong hợp đồng.
Bài 4 — Phản biện một NFR tồi. Cho NFR: "Trang chủ phải load nhanh và hoạt động tốt với nhiều người dùng". Viết lại thành một NFR chuẩn, chỉ ra đủ 4 điểm yếu của bản gốc và cách bạn sửa từng điểm.
Tóm tắt
NFR — yêu cầu phi chức năng — trả lời câu hỏi "hệ thống làm việc TỐT đến mức nào", và là nơi rất nhiều dự án đúng chức năng vẫn thất bại trên production. Dùng khung FURPS+ (Functionality/Security, Usability gồm WCAG, Reliability gồm uptime/MTBF/MTTR, Performance gồm latency/throughput/concurrency, Supportability, và dấu "+" cho ràng buộc pháp lý như PDPD/GDPR) làm checklist để không bỏ sót. Nguyên tắc bất di bất dịch: mỗi NFR phải đo được, với đủ 4 thành phần Metric + Target + Condition + Measurement; ưu tiên percentile (p95/p99) hơn trung bình; luôn quy đổi "số chín" ra con số thực; và đặc tả NFR sớm vì nó định hình kiến trúc.
Quan trọng nhất với bạn: nền QA không phải gánh nặng cần bỏ lại, mà là lợi thế cạnh tranh lớn nhất ở mảng này. Tư duy "điều gì sẽ vỡ", thói quen định lượng ngưỡng chất lượng, và kinh nghiệm test performance/security/accessibility biến bạn thành BA hiếm hoi viết NFR chắc tay. Hãy biến từng bug từng log thành một mẫu NFR — đó là tài sản nghề nghiệp mà ít ai có được.