Mở đầu — vì sao bài này quan trọng
Khi bạn còn làm Marketing, bạn quen với việc đo lường những thứ "nhìn thấy được": có bao nhiêu người click, tỷ lệ chuyển đổi là bao nhiêu, chiến dịch mang về bao nhiêu lead. Đó là những yêu cầu về chức năng — hệ thống làm được gì. Nhưng khi bước sang vai trò BA, bạn sẽ sớm phát hiện ra rằng phần lớn các dự án "thất bại sau khi go-live" không phải vì thiếu chức năng, mà vì thiếu thứ ít ai để ý: chất lượng vận hành của hệ thống.
Một trang landing page bán hàng có đầy đủ chức năng — hiển thị sản phẩm, thêm vào giỏ, thanh toán — nhưng nếu nó tải mất 8 giây trong ngày sale 12.12, bạn mất hàng nghìn đơn hàng. Chức năng vẫn "đúng", nhưng trải nghiệm thì hỏng. Đó chính là địa hạt của Non-Functional Requirements (NFR) — yêu cầu phi chức năng.
NFR là một trong những kỹ năng phân biệt BA junior với BA trung cấp. BA mới thường chỉ viết được "hệ thống cho phép người dùng đăng nhập" (functional). BA giỏi viết thêm: "hệ thống phải xử lý 5.000 lượt đăng nhập đồng thời với thời gian phản hồi dưới 2 giây, đạt uptime 99,9% mỗi tháng". Sự khác biệt nằm ở đó. Bài này sẽ giúp bạn nắm vững 7 nhóm NFR chính, cách viết NFR có thể đo lường được, và cách tránh những cái bẫy khiến NFR trở thành những câu sáo rỗng vô dụng.
Khái niệm cốt lõi
NFR là gì và khác Functional Requirement ở đâu
Functional Requirement (FR) mô tả hệ thống làm gì — hành vi, tính năng, quy tắc nghiệp vụ. Ví dụ: "Người dùng có thể hủy đơn hàng trong vòng 30 phút sau khi đặt."
Non-Functional Requirement (NFR) mô tả hệ thống vận hành tốt đến mức nào — chất lượng, ràng buộc, thuộc tính của toàn hệ thống. Ví dụ: "Thao tác hủy đơn phải hoàn tất và phản hồi cho người dùng trong vòng 2 giây, ở mức tải 1.000 đơn hủy/phút."
Cách dễ nhớ: FR trả lời câu hỏi "What?", còn NFR trả lời "How well?". FR thường gắn với một use case cụ thể; NFR thường trải ngang qua nhiều tính năng (cross-cutting). Vì vậy một NFR như "trang phải tải dưới 2 giây" có thể áp dụng cho hàng chục màn hình cùng lúc.
Khung FURPS+ — bản đồ để không bỏ sót
Để không quên loại NFR nào, ngành hay dùng khung FURPS+ (do Hewlett-Packard đề xuất). Trong bài này ta gom thành 7 nhóm thực dụng nhất cho BA:
1. Performance (Hiệu năng) — Hệ thống phản hồi nhanh đến đâu? Gồm ba chỉ số con:
- Response time (thời gian phản hồi): từ lúc người dùng bấm đến lúc nhận kết quả. Ví dụ: API trả về dưới 500ms ở phân vị 95 (P95).
- Throughput (thông lượng): số giao dịch xử lý được trong một đơn vị thời gian, ví dụ 2.000 giao dịch/giây.
- Capacity (sức chứa): số người dùng/dữ liệu tối đa hệ thống chứa được, ví dụ 10 triệu tài khoản.
3. Availability (Tính sẵn sàng) — Hệ thống "sống" được bao nhiêu phần trăm thời gian? Đo bằng uptime: 99,9% (gọi là "three nines") nghĩa là được phép downtime khoảng 43 phút/tháng; 99,99% ("four nines") chỉ còn ~4,3 phút/tháng. Mỗi "số 9" thêm vào làm chi phí tăng vọt — đây là điểm BA phải đàm phán với stakeholder.
4. Reliability (Độ tin cậy) — Hệ thống có chạy ổn định, không lỗi vặt, phục hồi tốt sau sự cố không? Đo bằng MTBF (thời gian trung bình giữa hai lần hỏng) và MTTR (thời gian trung bình để phục hồi). Khác với availability ở chỗ: một hệ thống có thể "sẵn sàng" nhưng vẫn hay trả kết quả sai — đó là vấn đề reliability.
5. Security (Bảo mật) — Bảo vệ dữ liệu và quyền truy cập. Gồm: mã hóa dữ liệu (at-rest và in-transit), phân quyền, audit log, chống tấn công (SQL injection, brute-force). Với BA ở VN, nhóm này thường gắn chặt với tuân thủ pháp lý (sẽ học sâu ở bài Compliance/PDPD).
6. Usability (Khả năng sử dụng) — Dễ học, dễ dùng, ít lỗi thao tác. Đây là nơi nền Marketing của bạn cực mạnh: bạn đã quen tư duy về trải nghiệm người dùng, friction, drop-off. NFR usability có thể viết: "Người dùng mới hoàn thành quy trình đặt hàng đầu tiên trong dưới 3 phút mà không cần hướng dẫn."
7. Maintainability & Portability (Khả năng bảo trì & di động) — Code/hệ thống có dễ sửa, dễ nâng cấp, dễ chuyển sang nền tảng khác không? BA ít viết chi tiết nhóm này (thiên về kỹ thuật), nhưng cần ghi nhận ràng buộc như "phải chạy được trên cả iOS 14+ và Android 9+".
Dấu "+" trong FURPS+ nhắc bạn còn các ràng buộc khác: pháp lý (Compliance), khả năng quan sát (Observability/logging), khả năng truy cập cho người khuyết tật (Accessibility), localization (đa ngôn ngữ).
Đặc tính SMART của một NFR tốt
Một NFR chỉ có giá trị khi đo lường được. So sánh:
- Tệ: "Hệ thống phải nhanh." (Nhanh là bao nhiêu? Ai nghiệm thu?)
- Tốt: "95% các request tới API thanh toán phải hoàn tất trong dưới 800ms, đo trong điều kiện 1.000 giao dịch/giây, môi trường production."
Tình huống thực tế
Tình huống 1 — Tiki và cái bẫy "quên Performance" mùa sale 11.11
Một đội dự án (tình huống mô phỏng dựa trên bối cảnh các sàn TMĐT VN) xây tính năng "flash sale" cho ngày 11.11. Functional requirement viết rất đầy đủ: hiển thị đồng hồ đếm ngược, giới hạn mỗi tài khoản mua 1 sản phẩm, tự khóa khi hết hàng. Demo trên môi trường test với 20 người chạy mượt mà, ai cũng hài lòng.
Đêm 11.11, lúc 0h00, 150.000 người cùng vào tranh mua 500 chiếc điện thoại giảm giá sốc. Hệ thống treo 6 phút. Trang trả về lỗi 503, người dùng phẫn nộ trên fanpage, và 500 chiếc điện thoại bán không hết vì khách không vào nổi.
Vấn đề: BA đã viết FR hoàn hảo nhưng bỏ trắng NFR về performance và scalability. Lẽ ra phải có dòng: "Tính năng flash sale phải chịu được đỉnh tải 200.000 người dùng đồng thời trong 5 phút đầu, với response time P95 dưới 3 giây và tỷ lệ lỗi dưới 1%."
Bài học: NFR về tải phải dựa trên kịch bản tải đỉnh (peak load), không phải tải trung bình. Marketing của bạn biết rõ ngày nào là đỉnh — hãy dùng chính dữ liệu đó để định lượng NFR. Một BA từng làm Marketing có lợi thế lớn: bạn biết "11.11 traffic gấp 30 lần ngày thường", con số mà dev thuần kỹ thuật có thể không nắm.
Tình huống 2 — MoMo và bài toán "mỗi số 9 đáng giá bao nhiêu"
Với ví điện tử như MoMo (tình huống minh họa), stakeholder ban đầu yêu cầu uptime "99,99%" cho dịch vụ chuyển tiền vì nghe có vẻ "đẳng cấp". BA ngồi tính: từ 99,9% (43 phút downtime/tháng) lên 99,99% (4,3 phút/tháng) đòi hỏi kiến trúc dự phòng kép, multi-region, đội trực 24/7 — chi phí hạ tầng tăng ước tính 40%.
BA giỏi không gật đầu ngay. Anh ấy chia dịch vụ thành hai nhóm: luồng chuyển tiền (critical — phải 99,99%) và luồng xem lịch sử giao dịch (có thể chấp nhận 99,5%). Bằng cách phân tầng NFR theo mức độ quan trọng nghiệp vụ, đội tiết kiệm được phần lớn chi phí mà vẫn bảo vệ trải nghiệm cốt lõi.
Bài học: Availability không phải "càng cao càng tốt" — nó là bài toán đánh đổi chi phí. Nhiệm vụ của BA là gắn mỗi mức NFR với giá trị nghiệp vụ để stakeholder ra quyết định có cơ sở, thay vì chọn theo cảm tính.
Tình huống 3 — Edtech và NFR về Usability cho học viên lớn tuổi
Một nền tảng edtech VN (giả định) ra mắt app học tiếng Anh cho người đi làm, trong đó có nhóm học viên 40-55 tuổi. Functional requirement đầy đủ, app chạy nhanh, nhưng tỷ lệ hoàn thành bài học đầu tiên chỉ đạt 30%. Phân tích cho thấy: nút bấm quá nhỏ, font chữ mặc định 12px, quy trình đăng ký 7 bước.
BA bổ sung NFR usability cụ thể: "90% người dùng trong nhóm tuổi 40-55 hoàn thành đăng ký trong dưới 2 phút; cỡ chữ tối thiểu 16px; mọi nút thao tác chính có vùng chạm tối thiểu 44x44px." Sau khi áp dụng, tỷ lệ hoàn thành tăng lên 68%.
Bài học: Usability là NFR, và nó có thể đo được qua tỷ lệ hoàn thành, thời gian thao tác, số lỗi. Đây chính là lúc tư duy Marketing — đo conversion, tối ưu funnel — chuyển thẳng thành kỹ năng BA.
Hướng dẫn từng bước
Đây là quy trình thực dụng để bóc tách và viết NFR cho một tính năng:
Bước 1 — Xác định các tính năng/luồng quan trọng (critical paths). Không phải mọi màn hình đều cần NFR khắt khe. Hãy tìm những luồng tạo ra tiền hoặc rủi ro lớn nhất: thanh toán, đăng nhập, tìm kiếm. Dồn công sức NFR vào đó.
Bước 2 — Với mỗi nhóm FURPS+, đặt câu hỏi gợi mở cho stakeholder:
- Performance: "Người dùng chờ tối đa bao lâu trước khi thấy kết quả là chấp nhận được?"
- Scalability: "Trong 12 tháng tới, lượng người dùng dự kiến tăng bao nhiêu? Đỉnh tải rơi vào dịp nào?"
- Availability: "Hệ thống chết 1 giờ thì doanh nghiệp mất bao nhiêu tiền/uy tín?"
- Security: "Dữ liệu nào nhạy cảm nhất? Ai được phép xem?"
- Usability: "Người dùng mục tiêu là ai? Họ rành công nghệ đến đâu?"
Bước 4 — Phân tầng ưu tiên. Gắn mỗi NFR vào mức Must/Should/Could (liên hệ MoSCoW). Không phải NFR nào cũng bắt buộc — phân tầng giúp đội cân đối ngân sách.
Bước 5 — Ghi NFR vào tài liệu đúng chỗ. NFR có thể nằm trong một mục riêng "Non-Functional Requirements" của SRS, hoặc gắn vào acceptance criteria của user story dưới dạng điều kiện ràng buộc. Với Agile, nhiều đội tách NFR thành các tiêu chí "Definition of Done" áp dụng cho toàn sprint.
Bước 6 — Bắt tay với QA và Dev để xác nhận tính khả thi. NFR phải kiểm thử được. Hỏi QA: "Anh đo cái này bằng cách nào?". Nếu QA lắc đầu, NFR của bạn chưa đủ rõ.
Lỗi thường gặp & mẹo
Lỗi 1 — Viết NFR chung chung, không đo được. "Hệ thống phải thân thiện, nhanh, an toàn" là vô nghĩa. Mẹo: mỗi NFR phải có con số và đơn vị. Nếu không gắn được con số, đó chưa phải NFR mà chỉ là mong muốn.
Lỗi 2 — Quên hỏi về điều kiện tải. Response time 1 giây với 10 người rất khác với 10.000 người. Luôn kèm "ở mức tải bao nhiêu". Đây là lỗi kinh điển của marketer mới chuyển sang vì quen demo ở quy mô nhỏ.
Lỗi 3 — Áp NFR "đắt tiền" cho mọi thứ. Đòi 99,99% uptime cho trang "Giới thiệu công ty" là lãng phí. Mẹo: phân tầng theo giá trị nghiệp vụ — luồng tạo tiền mới cần NFR cao.
Lỗi 4 — Bỏ quên NFR cho đến cuối dự án. NFR nhồi vào phút chót thường buộc phải đập đi xây lại kiến trúc, rất tốn kém. Mẹo: đưa NFR vào ngay từ giai đoạn thiết kế, vì chúng định hình kiến trúc.
Lỗi 5 — Đặt ngưỡng theo cảm tính. "Dưới 2 giây" từ đâu ra? Mẹo: dựa trên dữ liệu thực — benchmark đối thủ, nghiên cứu (ví dụ Google chỉ ra cứ thêm 1 giây load, conversion giảm đáng kể), hoặc chính dữ liệu Marketing cũ của bạn.
Mẹo vàng cho người từ Marketing: Bạn vốn quen với A/B testing và đo lường hành vi. Hãy xem NFR như những "KPI vận hành" của sản phẩm. Tư duy "cứ thêm 1 giây thì rớt bao nhiêu % khách" chính là cầu nối tự nhiên giúp bạn định lượng NFR thuyết phục hơn cả nhiều BA thuần kỹ thuật.
Bài tập thực hành
Bài tập 1 — Phân loại. Cho các yêu cầu sau, đánh dấu FR hay NFR:
- "Người dùng có thể đặt lại mật khẩu qua email."
- "Email đặt lại mật khẩu phải được gửi đến hộp thư người dùng trong vòng 30 giây."
- "Hệ thống mã hóa mật khẩu bằng thuật toán bcrypt."
- "Người dùng có thể lọc sản phẩm theo giá."
- "Trang kết quả lọc hiển thị trong dưới 1,5 giây với 50.000 sản phẩm."
Bài tập 2 — Viết lại cho đo được. Nhận các NFR "lỏng" sau và viết lại đầy đủ 4 thành phần (chỉ số + ngưỡng + điều kiện + nghiệm thu):
- "App phải tải nhanh."
- "Hệ thống phải an toàn."
- "Giao diện phải dễ dùng."
Tóm tắt
NFR — yêu cầu phi chức năng — quyết định một hệ thống vận hành tốt đến mức nào, trong khi FR chỉ nói nó làm được gì. Phần lớn sự cố sau go-live (treo mùa sale, downtime, người dùng bỏ cuộc) bắt nguồn từ NFR bị bỏ quên hoặc viết hời hợt.
Dùng khung FURPS+ để không bỏ sót 7 nhóm: Performance, Scalability, Availability, Reliability, Security, Usability, Maintainability — cùng các ràng buộc cộng thêm như Compliance và Accessibility. Một NFR chỉ có giá trị khi đo lường được, với đủ 4 thành phần: chỉ số, ngưỡng, điều kiện đo và cách nghiệm thu.
Hãy nhớ ba nguyên tắc: (1) NFR phải có con số, (2) NFR phải gắn điều kiện tải, (3) NFR phải phân tầng theo giá trị nghiệp vụ vì mỗi mức cao hơn đều đắt hơn. Và lợi thế lớn nhất của bạn — người từ Marketing — là tư duy đo lường hành vi và hiểu rõ đỉnh tải kinh doanh: hãy biến nó thành những NFR sắc bén mà ít BA thuần kỹ thuật viết được.