Viết NFR đo được bằng AI cho tính năng ngân hàng số
Playbook giúp BA và PO biến các yêu cầu như “chuyển tiền phải nhanh, ổn định, bảo mật” thành NFR có bối cảnh, tiêu chí kiểm thử, câu hỏi làm rõ và bản nháp sẵn sàng đưa vào Jira.
Một yêu cầu như: “Ứng dụng chuyển tiền phải nhanh, ổn định và bảo mật” nghe có vẻ rõ ràng. Nhưng khi đưa vào backlog, mỗi bên có thể hiểu một kiểu.
“Nhanh” là bao lâu? “Ổn định” trong điều kiện tải nào? “Bảo mật” là xác thực giao dịch, phân quyền truy cập, bảo vệ dữ liệu hay lưu vết thao tác?
Nếu không làm rõ, team có thể hoàn thành luồng chức năng nhưng vẫn chưa đáp ứng chất lượng vận hành mà business và khách hàng kỳ vọng.
Với BA/PO ngân hàng số, AI không nên là công cụ “quyết định hộ” yêu cầu. Vai trò hữu ích hơn là giúp biến câu nói mơ hồ thành bản nháp NFR có thể xác minh, chỉ ra giả định và chuẩn bị câu hỏi để cả team cùng chốt.
NFR là gì?
Yêu cầu chức năng (functional requirement) mô tả hệ thống làm gì.
Ví dụ:
> Khách hàng có thể tạo và gửi lệnh chuyển tiền.
Yêu cầu phi chức năng (non-functional requirement — NFR) mô tả hệ thống phải như thế nào khi cung cấp chức năng đó. Đây là các tiêu chí dùng để đánh giá cách hệ thống vận hành, thay vì một hành vi đơn lẻ.
Với tính năng chuyển tiền, NFR có thể thuộc các nhóm:
Hiệu năng: phản hồi trong ngưỡng đã thống nhất.
Độ tin cậy và khả dụng: xử lý, thông báo trạng thái hoặc lỗi rõ ràng.
Bảo mật và riêng tư: bảo vệ dữ liệu và kiểm soát quyền truy cập.
Khả năng mở rộng: duy trì chất lượng vận hành khi tải tăng.
Khả năng kiểm thử: có điều kiện để QA hoặc vận hành xác minh.
Tuân thủ: đáp ứng các ràng buộc pháp lý, quy định, tiêu chuẩn hoặc giao thức áp dụng.
NFR thường có ý nghĩa kiến trúc. Vì vậy, BA/PO nên đưa chúng vào thảo luận ngay từ lúc làm rõ phạm vi, thay vì để đến cuối sprint hoặc giao riêng cho đội kỹ thuật.
> Tham khảo: Non-functional requirement
Quy trình 3 bước: từ câu nói business đến NFR kiểm thử được
Bước 1: Ghi nguyên văn nhu cầu ban đầu
Đừng vội “dịch” câu nói của stakeholder thành thông số kỹ thuật.
Ví dụ:
> “Khách hàng cần chuyển tiền nhanh, ứng dụng đừng bị lỗi và phải bảo mật.”
Câu này chưa thể là acceptance criteria, nhưng nó vẫn quan trọng vì phản ánh nhu cầu cần được làm rõ.
Bước 2: Dùng AI để phân loại phần thiếu
Yêu cầu AI tách phần chức năng, NFR, từ mơ hồ, giả định ẩn và câu hỏi cần xác nhận. Mục tiêu là chuẩn bị cho buổi refinement hoặc workshop, không phải sao chép nguyên đầu ra vào Jira.
Mẫu prompt:
text
Bạn là Business Analyst cho sản phẩm <loại sản phẩm>.
Hãy phân tích yêu cầu sau:
"<yêu cầu mơ hồ>"
Bối cảnh:
Người dùng: <nhóm người dùng>
Chức năng liên quan: <chức năng>
Kênh sử dụng: <mobile/web/internal>
Ràng buộc đã biết: <quy định, hệ thống tích hợp, giả định>
Yêu cầu đầu ra:
Phân biệt phần nào là functional requirement, phần nào là NFR.
Nhóm NFR theo: hiệu năng, độ tin cậy/khả dụng, bảo mật/riêng tư,
khả năng kiểm thử, khả năng mở rộng, tuân thủ và khả năng sử dụng.
Nêu các từ mơ hồ hoặc chưa đo được.
Đề xuất câu hỏi làm rõ cho business, kiến trúc sư, QA và vận hành.
Không tự đưa ra ngưỡng, quy định hoặc cam kết chưa có dữ liệu.
Với thông tin thiếu, dùng <placeholder> và ghi rõ cần xác nhận.
Trình bày kết quả bằng bảng ngắn gọn.
Thay vì hỏi chung chung “nhanh là sao?”, BA có thể đặt câu hỏi cụ thể hơn:
Áp dụng cho màn hình hay bước giao dịch nào?
“Kết quả” là hệ thống tiếp nhận lệnh hay giao dịch hoàn tất?
Điều kiện tải cần đánh giá là gì?
Những trạng thái lỗi nào cần hiển thị cho khách hàng?
Ai có thẩm quyền chốt ngưỡng và mức chấp nhận?
Bước 3: Viết NFR có thể xác minh
Một NFR tốt cần đủ cụ thể để team hiểu:
Nó áp dụng trong bối cảnh nào.
Điều gì được đo hoặc quan sát.
Điều kiện nào được xem là đạt.
QA, kỹ thuật hoặc vận hành sẽ xác minh bằng cách nào.
Không phải NFR nào cũng cần bắt đầu bằng một con số. Tuy nhiên, yêu cầu phải dẫn đến cách kiểm tra rõ ràng.
Sau khi đã nhận được phản hồi từ các bên liên quan, dùng prompt thứ hai:
text
Dựa trên thông tin dưới đây, hãy viết NFR có thể kiểm thử cho Jira.
Tính năng: <tên tính năng>
Bối cảnh nghiệp vụ: <bối cảnh>
Quyết định đã chốt: <các ngưỡng hoặc quy tắc đã xác nhận>
NFR cần viết: <danh sách nhóm NFR>
Với mỗi NFR, trả về:
Tên ngắn
Mô tả theo mẫu "Hệ thống phải..."
Điều kiện áp dụng
Tiêu chí chấp nhận theo Given/When/Then
Cách kiểm thử hoặc bằng chứng cần có
Phụ thuộc, giả định và câu hỏi còn mở
Không suy đoán thông số còn thiếu. Giữ <placeholder> nếu chưa có quyết định.
Ví dụ: biến “nhanh và bảo mật” thành nội dung có thể thảo luận
Đầu vào:
text
Tính năng: Chuyển tiền trên ứng dụng ngân hàng số
Yêu cầu ban đầu:
"Khách hàng chuyển tiền phải nhanh, không bị lỗi và bảo mật."
Thông tin đã biết:
Người dùng: khách hàng đã đăng nhập
Có bước xác nhận giao dịch
Cần hiển thị trạng thái giao dịch cho khách hàng
Chưa có ngưỡng hiệu năng và chưa xác định quy định áp dụng
Bản nháp NFR phù hợp có thể có dạng:
| Nhóm | NFR đề xuất | Điều cần chốt |
|---|---|---|
| Hiệu năng | Hệ thống phải hiển thị kết quả xử lý lệnh chuyển tiền trong <ngưỡng thời gian> tại điều kiện tải đã thống nhất. | “Kết quả” là xác nhận tiếp nhận hay hoàn tất giao dịch? |
| Độ tin cậy | Khi không thể xử lý lệnh, hệ thống phải hiển thị trạng thái rõ ràng và không tạo cảm giác giao dịch đã thành công. | Danh sách trạng thái và cách xử lý từng lỗi. |
| Bảo mật | Hệ thống phải chỉ cho phép khách hàng đã xác thực thực hiện bước xác nhận giao dịch theo cơ chế được phê duyệt. | Cơ chế xác thực, trường hợp hết phiên, thiết bị mới. |
| Riêng tư | Hệ thống phải bảo vệ dữ liệu giao dịch theo quy định áp dụng và quyền truy cập đã được phân công. | Dữ liệu cần che, người được xem, thời hạn lưu giữ. |
| Khả năng kiểm toán | Hệ thống phải lưu bằng chứng về thao tác xác nhận và kết quả xử lý để phục vụ kiểm tra. | Trường dữ liệu cần lưu, nơi lưu và thời hạn lưu. |
Một acceptance criterion có thể được AI soạn nháp:
text
Given khách hàng đã đăng nhập và đã nhập thông tin chuyển tiền hợp lệ
When khách hàng xác nhận lệnh chuyển tiền
Then hệ thống phải trả về trạng thái xử lý trong <ngưỡng thời gian>
And trạng thái hiển thị phải phân biệt rõ: thành công, đang xử lý hoặc không thành công
And hệ thống phải lưu <thông tin kiểm toán đã được phê duyệt>
Điểm quan trọng không phải là để AI chọn hộ <ngưỡng thời gian>. Giá trị của bản nháp là giúp team thấy rõ các quyết định còn thiếu: định nghĩa thành công, trạng thái trung gian, dữ liệu cần lưu và cách xác minh.
Đưa NFR vào Jira mà không biến ticket thành “bức tường chữ”
Bạn có thể đặt NFR trong phần Acceptance Criteria của work item tính năng. Nếu một NFR ảnh hưởng đến nhiều story hoặc nhiều thành phần, cân nhắc tạo ticket riêng và liên kết với các story liên quan.
Mẫu cấu trúc:
text
User story
Là <vai trò người dùng>,
tôi muốn <mục tiêu>,
để <giá trị nghiệp vụ>.
NFR
Hiệu năng: <NFR đã chốt>
Bảo mật/riêng tư: <NFR đã chốt>
Độ tin cậy: <NFR đã chốt>
Tuân thủ: <NFR đã chốt>
Acceptance criteria
Given <bối cảnh>
When <hành động hoặc điều kiện>
Then <kết quả đo được>
Open questions
<câu hỏi chưa chốt>
Dependencies/assumptions
<phụ thuộc và giả định>
Trong PRD hoặc Confluence, nên giữ thêm:
Mục tiêu và bối cảnh nghiệp vụ.
Giả định.
Phụ thuộc.
Nội dung ngoài phạm vi.
Các quyết định và câu hỏi còn mở.
Theo hướng dẫn của Atlassian, PRD cần tạo được sự hiểu biết chung giữa các bên liên quan, đồng thời được cập nhật khi hiểu biết về sản phẩm thay đổi. Điều này phù hợp với cách làm Agile hơn là cố định mọi chi tiết ngay từ đầu.
> Tham khảo: How to create a product requirements document
Checklist review đầu ra AI
Trước khi đưa NFR vào Jira hoặc PRD, BA/PO nên rà lại:
[ ] Có từ mơ hồ như “nhanh”, “an toàn”, “ổn định”, “dễ dùng” chưa được định nghĩa không?
[ ] NFR áp dụng cho toàn hệ thống, một kênh hay một luồng giao dịch cụ thể?
[ ] Có đang nhầm lẫn giữa yêu cầu chức năng và chất lượng vận hành không?
[ ] QA hoặc vận hành có thể xác minh tiêu chí này không?
[ ] AI có biến giả định thành kết luận mà chưa được business xác nhận không?
[ ] NFR có mâu thuẫn với trải nghiệm người dùng, tích hợp hoặc ràng buộc đã biết không?
[ ] Ai chịu trách nhiệm chốt từng <placeholder>?
Các NFR liên quan đến bảo mật, riêng tư, tuân thủ và lưu giữ dữ liệu cần được xác nhận bởi đầu mối có thẩm quyền, thay vì chỉ dựa vào quyết định của PO hoặc đầu ra AI.
Lưu ý khi dùng AI với ngữ cảnh ngân hàng số
Không đưa vào công cụ AI không được phê duyệt các dữ liệu như:
Thông tin khách hàng hoặc tài khoản.
Lịch sử giao dịch.
Bí mật nghiệp vụ.
Cấu hình bảo mật.
Tài liệu nội bộ chưa được phép chia sẻ.
Khi cần tạo bản nháp, hãy thay dữ liệu thật bằng placeholder như <khách hàng>, <số tiền> hoặc <mã giao dịch>, và tuân theo chính sách sử dụng AI của tổ chức.
AI phù hợp để tạo khung phân tích, câu hỏi và cấu trúc NFR. Các quyết định về ngưỡng, rủi ro và mức chấp nhận vẫn cần được chốt qua trao đổi giữa business, kỹ thuật, QA, vận hành và các đầu mối kiểm soát phù hợp.