Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa hoàn thành tài liệu yêu cầu cho một ứng dụng đặt lịch khám bệnh. Bạn đã mô tả rất chi tiết: người dùng đăng nhập được, chọn bác sĩ được, đặt lịch được, hủy lịch được, nhận email xác nhận được. Team dev code xong, demo chạy ngon lành trên máy của họ. Ai cũng vui.
Rồi ngày go-live đến. 8 giờ sáng, hàng nghìn bệnh nhân đồng loạt mở app để đặt lịch. Hệ thống chậm như rùa, có người bấm "Đặt lịch" xong đợi 40 giây mới thấy phản hồi, có người bị văng ra khỏi trang. Đến trưa thì server sập. Cả team hoảng loạn tìm lỗi. Nhưng đây không phải "lỗi" theo nghĩa thông thường — hệ thống làm đúng mọi thứ bạn yêu cầu. Vấn đề là bạn chưa bao giờ nói nó phải làm những việc đó nhanh đến mức nào, cho bao nhiêu người cùng lúc, và an toàn ra sao.
Đó chính là khoảng trống mang tên Non-Functional Requirement (NFR) — yêu cầu phi chức năng. Và đây là một trong những thứ mà BA fresher bỏ qua nhiều nhất, gây hậu quả đắt nhất. Trong bài này, tôi sẽ giúp bạn hiểu rõ NFR là gì, đi sâu vào 8 thuộc tính mà người mới thường quên, và trang bị cho bạn cách viết NFR sao cho có thể đo lường được — thứ tách một BA nghiệp dư khỏi một BA đáng tin cậy.
Khái niệm cốt lõi
NFR là gì?
Nếu functional requirement (yêu cầu chức năng) trả lời câu hỏi "Hệ thống làm được gì?" thì non-functional requirement trả lời câu hỏi "Hệ thống làm việc đó tốt đến mức nào?".
- Functional: "Người dùng có thể tìm kiếm sản phẩm theo tên."
- Non-functional: "Kết quả tìm kiếm phải trả về trong vòng 2 giây với 95% số lần tìm, ngay cả khi có 5.000 người dùng đồng thời."
Vì sao fresher hay bỏ qua NFR?
Có ba lý do rất con người. Thứ nhất, NFR vô hình — khi mọi thứ chạy tốt, không ai để ý; chỉ khi nó hỏng người ta mới nhận ra thiếu. Thứ hai, stakeholder ít khi tự nói ra. Không ai bước vào phòng họp và bảo "Tôi cần hệ thống chịu được 10.000 người cùng lúc" — họ mặc định điều đó là hiển nhiên. Thứ ba, NFR khó viết cho đo được. Nói "hệ thống phải nhanh" thì dễ, nhưng "nhanh" là bao nhiêu? BA fresher thường dừng ở mức mơ hồ đó và tưởng mình đã xong việc.
8 thuộc tính NFR mà BA fresher hay bỏ qua
Đây là danh sách 8 thuộc tính bạn cần khắc cốt ghi tâm. Với mỗi cái, tôi cho bạn câu hỏi gợi ý để "moi" ra yêu cầu từ stakeholder:
- Performance (hiệu năng) — Hệ thống phản hồi nhanh thế nào? Đo bằng response time (thời gian phản hồi) và throughput (số giao dịch xử lý được mỗi giây). Câu hỏi: "Người dùng chấp nhận đợi tối đa bao lâu cho thao tác này?"
- Scalability (khả năng mở rộng) — Khi lượng người dùng hoặc dữ liệu tăng gấp 10 lần, hệ thống có gánh nổi không, hay phải viết lại từ đầu? Câu hỏi: "Trong 2 năm tới, số người dùng dự kiến tăng đến đâu?"
- Availability (tính sẵn sàng) — Hệ thống được phép "chết" bao nhiêu thời gian? Thường viết dưới dạng % uptime, ví dụ 99,9% (tức chỉ được down khoảng 8,7 giờ/năm). Câu hỏi: "Nếu hệ thống ngừng chạy 1 giờ vào giờ cao điểm, thiệt hại là gì?"
- Security (bảo mật) — Dữ liệu được bảo vệ ra sao? Ai được xem gì? Có mã hóa không? Có tuân thủ luật (như Nghị định 13/2023 về bảo vệ dữ liệu cá nhân tại Việt Nam) không? Câu hỏi: "Dữ liệu nào là nhạy cảm, và ai tuyệt đối không được truy cập?"
- Usability (tính dễ dùng) — Người dùng mới mất bao lâu để thao tác thành thạo? Có cần đào tạo không? Câu hỏi: "Người dùng của chúng ta là ai — dân văn phòng rành công nghệ hay cô bán hàng 50 tuổi?"
- Reliability (độ tin cậy) — Hệ thống chạy ổn định thế nào, tần suất lỗi ra sao, và khi lỗi thì phục hồi nhanh không? Đo bằng MTBF (thời gian trung bình giữa các lần hỏng). Câu hỏi: "Nếu một giao dịch thanh toán bị gián đoạn giữa chừng, chuyện gì phải xảy ra?"
- Maintainability (khả năng bảo trì) — Khi cần sửa lỗi hay thêm tính năng, mất bao nhiêu công? Câu hỏi: "Team sẽ cần thay đổi phần nào thường xuyên nhất trong tương lai?"
- Compatibility / Portability (tính tương thích) — Hệ thống chạy trên trình duyệt nào, thiết bị nào, tích hợp với hệ thống cũ nào? Câu hỏi: "Khách hàng của bạn đang dùng trình duyệt và thiết bị gì?"
Tình huống thực tế
Tình huống 1: Sàn thương mại điện tử và ngày "sale sập sàn"
Một startup thương mại điện tử tại TP.HCM — tạm gọi là ShopFast — chuẩn bị cho đợt flash sale 12/12. BA của họ, một bạn fresher, viết requirement rất kỹ về chức năng: giỏ hàng, mã giảm giá, thanh toán qua ví MoMo, tính phí ship. Tất cả functional đều hoàn hảo.
Ngày sale, 0 giờ đêm, lượng truy cập tăng vọt gấp 30 lần bình thường. Trang chủ load 25 giây, nhiều người bấm thanh toán thì bị lỗi "timeout", một số đơn bị trừ tiền nhưng không ghi nhận. Doanh thu 2 tiếng đầu — thời điểm vàng — gần như bằng không, và tệ hơn là khủng hoảng niềm tin.
Diễn giải: Bạn BA đã bỏ qua Performance và Scalability. Không ai định nghĩa "hệ thống phải chịu được X người đồng thời", nên team dev thiết kế hạ tầng chỉ vừa đủ cho tải ngày thường. Ngoài ra, việc "trừ tiền nhưng không ghi đơn" là lỗi Reliability — thiếu yêu cầu về tính toàn vẹn giao dịch (transaction phải hoặc thành công trọn vẹn, hoặc rollback hoàn toàn).
Bài học: Với các sự kiện có tính bùng nổ (flash sale, mở bán vé, tuyển sinh online), BA phải chủ động hỏi con số tải đỉnh và viết thành NFR đo được: "Hệ thống phải xử lý được 5.000 giao dịch/phút với response time dưới 3 giây ở mức tải đỉnh gấp 30 lần trung bình ngày thường."
Tình huống 2: App ngân hàng và bài toán bảo mật
Một ngân hàng số tại Việt Nam triển khai tính năng chuyển tiền mới. BA mô tả đầy đủ luồng: nhập số tài khoản, nhập số tiền, xác nhận, nhận thông báo. Chức năng chạy trơn tru trong demo.
Nhưng khi đội kiểm thử bảo mật (security testing) vào cuộc, họ phát hiện: mật khẩu người dùng được lưu dưới dạng chưa mã hóa mạnh, phiên đăng nhập không tự hết hạn sau thời gian không hoạt động, và không có giới hạn số lần nhập sai OTP. Với một sản phẩm tài chính, đây là những lỗ hổng chí mạng — có thể dẫn đến vi phạm quy định của Ngân hàng Nhà nước và mất tiền thật của khách.
Diễn giải: BA đã bỏ qua thuộc tính Security và một phần Reliability. Trong domain ngân hàng, NFR bảo mật không phải "điểm cộng" mà là điều kiện sống còn, đôi khi được luật hóa. Việc phiên không tự hết hạn cũng liên quan Usability ngược chiều — dễ dùng quá mà thiếu an toàn thì thành thảm họa.
Bài học: Trong các domain nhạy cảm (ngân hàng, bảo hiểm, y tế), BA cần phối hợp với bộ phận security/compliance ngay từ giai đoạn thu thập yêu cầu, và viết NFR cụ thể: "Mọi mật khẩu phải được băm (hash) bằng thuật toán chuẩn; phiên đăng nhập tự động kết thúc sau 5 phút không hoạt động; khóa tài khoản sau 5 lần nhập sai OTP."
Tình huống 3: Phần mềm cho hợp tác xã nông nghiệp — bài học Usability
Một dự án phần mềm quản lý bán hàng cho các hợp tác xã nông nghiệp ở miền Tây. Team dev làm ra một giao diện hiện đại, nhiều tính năng, nhiều menu lồng nhau. Về mặt functional thì "khủng". Nhưng người dùng thực tế là các bác nông dân, tiểu thương lớn tuổi, ít tiếp xúc công nghệ. Kết quả: sau một tháng, phần lớn quay lại ghi sổ tay vì "app rối quá, không biết bấm đâu".
Diễn giải: Đây là thất bại về Usability. BA đã không định nghĩa chân dung người dùng và mức độ dễ dùng cần thiết. Một hệ thống "đúng chức năng" nhưng người dùng không dùng nổi thì coi như thất bại toàn tập.
Bài học: NFR về usability phải xuất phát từ việc hiểu người dùng thật. Ví dụ NFR đo được: "Người dùng mới (trên 45 tuổi, chưa quen smartphone) phải hoàn thành một đơn bán hàng trong vòng 3 phút mà không cần hướng dẫn, đạt tỷ lệ thành công tối thiểu 80% trong buổi kiểm thử thực địa."
Hướng dẫn từng bước
Đây là quy trình bạn có thể áp dụng ngay để không bỏ sót NFR trong dự án tiếp theo:
Bước 1 — Rà từng functional requirement qua "bộ lọc 8 thuộc tính". Mỗi khi viết xong một chức năng, tự hỏi: chức năng này cần nhanh cỡ nào (Performance)? Chịu được bao nhiêu người (Scalability)? Có dữ liệu nhạy cảm không (Security)? Người dùng có dễ dùng không (Usability)? Nếu hỏng thì sao (Reliability, Availability)? Cứ đi qua đủ 8 mục như một checklist.
Bước 2 — Chủ động khai thác từ stakeholder. Đừng đợi họ nói. Dùng các câu hỏi gợi ý ở phần trên. Đặc biệt hỏi về kịch bản xấu nhất: "Ngày đông khách nhất là khi nào, khoảng bao nhiêu người?", "Nếu hệ thống sập 1 tiếng thì mất bao nhiêu tiền?". Con số đau ví thường moi ra NFR nhanh nhất.
Bước 3 — Biến mọi NFR thành dạng ĐO ĐƯỢC. Đây là bước quan trọng nhất. Áp dụng công thức: [Thuộc tính] + [Điều kiện] + [Con số/Ngưỡng cụ thể] + [Cách đo].
- Yếu: "Hệ thống phải nhanh."
- Tốt: "95% yêu cầu tìm kiếm phải trả kết quả trong dưới 2 giây, đo tại mức tải 3.000 người dùng đồng thời."
Bước 4 — Ghi NFR đúng chỗ và gắn với chức năng liên quan. NFR có thể được ghi ở phần riêng trong tài liệu (một mục "Non-functional Requirements"), hoặc gắn ngay dưới user story dưới dạng acceptance criteria. Với NFR áp dụng toàn hệ thống (như "toàn bộ trang phải load dưới 3 giây"), hãy ghi thành yêu cầu chung.
Bước 5 — Xác nhận (validate) với người có thẩm quyền. NFR thường ràng buộc chi phí và hạ tầng, nên cần được kiến trúc sư/tech lead và stakeholder gật đầu. "99,99% uptime" nghe hay nhưng có thể tốn gấp nhiều lần "99,9%" — phải cân bằng giữa mong muốn và ngân sách.
Lỗi thường gặp & mẹo
Lỗi 1 — Viết NFR mơ hồ, không đo được. "Thân thiện", "nhanh", "an toàn", "ổn định" — đây là những từ vô nghĩa trong tài liệu BA nếu không kèm con số. Mẹo: mỗi khi viết một tính từ, tự hỏi "đo bằng cách nào?". Nếu không trả lời được, chưa viết xong.
Lỗi 2 — Chỉ tập trung functional, coi NFR là "để sau". NFR bị đẩy đến cuối dự án thì thường quá muộn — vì nó ảnh hưởng đến kiến trúc hệ thống, thứ rất tốn kém để sửa về sau. Mẹo: đưa NFR vào ngay từ giai đoạn thu thập yêu cầu, song song với functional.
Lỗi 3 — Copy NFR từ dự án cũ mà không suy nghĩ. "99,9% uptime" hợp với ngân hàng nhưng thừa thãi cho một app nội bộ 20 người dùng. Mẹo: NFR phải xuất phát từ ngữ cảnh thật của dự án này, không phải khuôn mẫu.
Lỗi 4 — Đặt NFR phi thực tế. Yêu cầu "response time 0,1 giây" hay "100% uptime" nghe oách nhưng bất khả thi hoặc cực kỳ tốn kém. Mẹo: luôn kiểm tra tính khả thi với đội kỹ thuật trước khi chốt.
Lỗi 5 — Quên các NFR "vô hình" như Maintainability và Compatibility. Đây là hai thuộc tính bị bỏ quên nhiều nhất vì người dùng cuối không "thấy" chúng. Mẹo: luôn hỏi "hệ thống này sẽ sống bao lâu, ai bảo trì, chạy trên thiết bị/trình duyệt nào?".
Mẹo vàng: Hãy in ra checklist 8 thuộc tính và dán cạnh màn hình. Trước khi gửi bất kỳ tài liệu requirement nào, chạy mắt qua 8 mục đó cho từng chức năng quan trọng. Chỉ thói quen nhỏ này thôi đã đưa bạn vượt trên đa số fresher.
Bài tập thực hành
Bài 1 — Biến đổi NFR mơ hồ thành đo được. Cho các câu sau, hãy viết lại thành NFR có thể kiểm chứng (kèm con số và cách đo):
- "App phải load nhanh."
- "Hệ thống phải bảo mật tốt."
- "Giao diện phải dễ dùng."
Bài 3 — Đặt câu hỏi khai thác. Bạn đang làm requirement cho hệ thống đặt vé xem phim online của một chuỗi rạp lớn tại Việt Nam. Hãy viết 8 câu hỏi (mỗi câu ứng với một thuộc tính NFR) mà bạn sẽ hỏi stakeholder để khai thác yêu cầu phi chức năng.
Sau khi làm xong, hãy tự chấm: NFR của bạn có con số cụ thể chưa? Có kiểm chứng được bằng test không? Nếu chưa, hãy viết lại — đó chính là kỹ năng cần luyện.
Tóm tắt
- NFR (yêu cầu phi chức năng) mô tả cách hệ thống hoạt động tốt đến đâu, khác với functional requirement mô tả hệ thống làm gì. Đây là phần định nghĩa "chất lượng" của sản phẩm.
- BA fresher hay bỏ qua NFR vì nó vô hình, stakeholder ít tự nói ra, và khó viết cho đo được — nhưng hậu quả (sập server, lộ dữ liệu, người dùng bỏ đi) thường rất đắt.
- Ghi nhớ 8 thuộc tính như một checklist: Performance, Scalability, Availability, Security, Usability, Reliability, Maintainability, Compatibility.
- Nguyên tắc sống còn: mọi NFR phải đo được — theo công thức [Thuộc tính] + [Điều kiện] + [Con số] + [Cách đo]. Nếu không kiểm chứng được bằng test thì coi như chưa viết.
- Quy trình: rà từng chức năng qua bộ lọc 8 thuộc tính → chủ động khai thác từ stakeholder → viết dạng đo được → ghi đúng chỗ → validate với kỹ thuật và stakeholder.
- Đưa NFR vào từ sớm, vì nó ảnh hưởng đến kiến trúc — thứ cực kỳ đắt để sửa về sau.