Dùng AI rà soát tài liệu yêu cầu: tìm chỗ thiếu, mơ hồ, mâu thuẫn

Playbook giúp BA/PO dùng AI như người phản biện vòng đầu cho user story, acceptance criteria và luồng nghiệp vụ: phát hiện điểm mơ hồ, thông tin thiếu, ngoại lệ và câu hỏi cần xác nhận trước khi tạo Jira.

Một user story có thể nghe rất rõ trong cuộc họp, nhưng lại chứa nhiều giả định ngầm khi được đưa vào Jira.

Ví dụ:

> “Khách hàng có thể khóa thẻ nhanh khi nghi ngờ mất thẻ.”

“Nh nhanh” là bao lâu? Áp dụng cho loại thẻ nào? Nếu thẻ đang có giao dịch xử lý dở thì sao? Khách hàng có cần xác thực lại không?

Đây là lúc AI hữu ích nhất: không phải để tự quyết định chính sách nghiệp vụ, mà để đóng vai người phản biện vòng đầu. AI có thể chỉ ra từ ngữ mơ hồ, chỗ thiếu thông tin, khả năng mâu thuẫn và các câu hỏi BA/PO cần mang tới buổi refinement.

Playbook này áp dụng cho user story, acceptance criteria, biên bản họp, use case và mô tả luồng nghiệp vụ trước khi chúng trở thành backlog.

AI có thể hỗ trợ rà soát yêu cầu như thế nào?

Trong phát triển phần mềm và quản lý sản phẩm, user story là mô tả không chính thức về một tính năng từ góc nhìn người dùng. Một mẫu phổ biến là:

> As a <role>, I can <capability>, so that <benefit>.

User story thường là điểm khởi đầu cho trao đổi giữa các bên liên quan, không nhất thiết là đặc tả hoàn chỉnh. Vì vậy, story ngắn vẫn cần được bổ sung bằng trao đổi, ghi chú, tài liệu liên quan và acceptance criteria.

Acceptance criteria giúp xác định story cần làm gì để Product Owner có thể chấp nhận là hoàn thành. Khi dùng AI để review, hãy yêu cầu AI soi tài liệu theo các góc sau:

Từ ngữ mơ hồ: “nhanh”, “tự động”, “hợp lệ”, “gần đây”, “đầy đủ”. Thông tin còn thiếu: actor, điều kiện đầu vào, dữ liệu, quyền hạn, kết quả mong đợi. Luồng ngoại lệ: dữ liệu không hợp lệ, trạng thái không cho phép, lỗi tích hợp, thao tác lặp. Mâu thuẫn: hai quy tắc dẫn tới kết quả khác nhau trong cùng một tình huống. Khả năng kiểm thử: tiêu chí có thể xác minh bằng hành vi hoặc kết quả quan sát được hay không.

Mục tiêu không phải là để AI “viết hộ” ticket. Mục tiêu là đưa những giả định chưa được viết thành danh sách câu hỏi rõ ràng.

Checklist rà soát trước khi tạo Jira

Dùng checklist này cho từng user story, use case hoặc một luồng nghiệp vụ.

1. Mục tiêu và phạm vi

Ai là người dùng hoặc vai trò thực hiện? Họ muốn đạt kết quả nghiệp vụ nào? Story có nêu rõ giá trị hoặc lợi ích mong muốn không? Phần nào thuộc phạm vi, phần nào chưa thuộc phạm vi? Có phụ thuộc vào hệ thống, đội ngũ hoặc quy trình khác không?

2. Quy tắc nghiệp vụ

Khi nào thao tác được phép hoặc bị từ chối? Trạng thái dữ liệu liên quan đã được nêu rõ chưa? Các vai trò khác nhau có quyền khác nhau không? Nếu nhiều quy tắc cùng áp dụng, thứ tự ưu tiên là gì? Quyết định nghiệp vụ nào vẫn cần stakeholder xác nhận?

3. Luồng chính và ngoại lệ

Luồng thành công bắt đầu và kết thúc ở đâu? Dữ liệu thiếu hoặc sai định dạng được xử lý thế nào? Nếu người dùng thực hiện lại thao tác thì sao? Nếu hệ thống phụ thuộc không phản hồi thì hệ thống hiển thị gì? Dữ liệu ở trạng thái nào khi một bước xử lý chưa có kết quả cuối cùng?

4. Acceptance criteria

Mỗi tiêu chí có điều kiện, hành động và kết quả mong đợi không? QA có thể kiểm tra mà không cần đoán ý nghiệp vụ không? Có từ ngữ không đo lường được như “dễ dùng”, “thân thiện”, “nhanh” không? Tiêu chí có mâu thuẫn với user story, ghi chú họp hoặc flow không?

Với BPMN hoặc flowchart, thêm một câu hỏi quan trọng:

> Mỗi nhánh quyết định đã có điều kiện rõ ràng và hướng xử lý khi điều kiện không thỏa chưa?

Prompt mẫu: AI reviewer cho tài liệu yêu cầu

Các mô hình ngôn ngữ có thể tạo văn bản tự do và, trong một số cách triển khai, trả về dữ liệu có cấu trúc. Với công việc hằng ngày của BA/PO, bạn có thể bắt đầu bằng prompt văn bản đơn giản sau.

text Bạn là Business Analyst reviewer độc lập.

Nhiệm vụ: rà soát tài liệu yêu cầu dưới đây trước khi tạo Jira.

Nguyên tắc: Không tự bịa quy tắc nghiệp vụ. Không tự kết luận chính sách nếu tài liệu chưa nêu. Mọi thông tin chưa đủ phải được ghi là “câu hỏi cần xác nhận”. Với mỗi nhận xét, hãy trích nguyên văn câu hoặc cụm từ làm căn cứ.

Hãy trả kết quả theo các phần:

Tóm tắt yêu cầu bằng ngôn ngữ đơn giản. Các điểm mơ hồ: Cụm từ gây mơ hồ. Lý do có thể bị hiểu khác nhau. Câu hỏi làm rõ. Thông tin còn thiếu: Actor, điều kiện trước, dữ liệu, kết quả, quyền hạn, phụ thuộc. Luồng ngoại lệ và trường hợp biên cần xác nhận. Mâu thuẫn hoặc nguy cơ mâu thuẫn giữa các quy tắc. Đánh giá acceptance criteria: Tiêu chí có thể kiểm thử. Tiêu chí chưa có kết quả quan sát được. Danh sách câu hỏi ưu tiên để BA/PO trao đổi với stakeholder.

Tài liệu cần review: <dán user story, acceptance criteria, ghi chú họp hoặc mô tả flow tại đây>

Prompt so sánh nhiều nguồn yêu cầu

Khi có biên bản họp, tài liệu Confluence và ticket cũ cùng mô tả một tính năng, hãy yêu cầu AI so sánh trực tiếp thay vì review từng tài liệu riêng lẻ.

text So sánh các tài liệu dưới đây như một BA thực hiện gap analysis.

Chỉ sử dụng thông tin có trong tài liệu. Không suy diễn ngoài nội dung được cung cấp.

Hãy lập danh sách: Quy tắc hoặc yêu cầu xuất hiện nhất quán ở các tài liệu. Quy tắc hoặc yêu cầu mâu thuẫn. Nội dung chỉ xuất hiện ở một tài liệu. Câu hỏi cần xác nhận trước khi tạo hoặc cập nhật Jira. Các quyết định nghiệp vụ cần được ghi nhận chính thức.

<Tài liệu A> ... </Tài liệu A>

<Tài liệu B> ... </Tài liệu B>

Ví dụ: rà soát yêu cầu khóa thẻ

Đầu vào

text User story: Là khách hàng, tôi muốn khóa thẻ nhanh trên ứng dụng khi nghi ngờ mất thẻ để tránh phát sinh giao dịch không mong muốn.

Acceptance criteria: Khách hàng có thể khóa thẻ từ ứng dụng. Hệ thống thông báo khóa thẻ thành công. Thẻ đã khóa không được giao dịch.

Những điểm AI nên chỉ ra

text Điểm mơ hồ: “Khóa thẻ nhanh”: chưa có định nghĩa về điều kiện hoặc thời điểm hoàn tất. “Thẻ”: chưa nêu rõ loại thẻ nào được áp dụng. “Không được giao dịch”: chưa xác định loại giao dịch và thời điểm áp dụng.

Thông tin còn thiếu: Khách hàng có cần xác thực lại trước khi khóa thẻ không? Có được gửi yêu cầu khóa cho thẻ đã ở trạng thái khóa không? Việc mở khóa có thuộc phạm vi của story này không? Ứng dụng hiển thị gì nếu chưa nhận được kết quả từ hệ thống quản lý thẻ?

Luồng ngoại lệ cần xác nhận: Khách hàng chọn một thẻ không thuộc quyền sử dụng. Thẻ đã hết hiệu lực hoặc đã bị hủy. Yêu cầu khóa đang xử lý nhưng người dùng thao tác lại. Hệ thống chưa trả về kết quả cuối cùng.

Acceptance criteria cần làm rõ: “Thông báo thành công” cần nêu trạng thái hoặc kết quả được hiển thị. “Không được giao dịch” cần xác định phạm vi giao dịch và thời điểm hiệu lực.

Điểm mấu chốt: AI không được phép tự kết luận chính sách khóa thẻ. AI chỉ giúp BA nhìn thấy nơi chính sách đó chưa được ghi rõ.

Sau khi stakeholder trả lời, hãy cập nhật quyết định vào nơi nhóm đang quản lý tài liệu, rồi mới hoàn thiện story và acceptance criteria trong Jira.

Ba bước kiểm tra đầu ra của AI

Không nên sao chép nguyên văn câu trả lời AI vào ticket. Hãy kiểm tra lại theo ba bước.

1. Đối chiếu bằng chứng

Mỗi nhận xét có bám vào câu nào trong tài liệu không?

Nếu AI không thể trích dẫn đoạn liên quan, hãy xem đó là một giả định hoặc gợi ý, không phải lỗi yêu cầu đã được xác minh.

2. Phân loại đúng vấn đề

Tách hai nhóm việc:

Lỗi diễn đạt yêu cầu: câu mơ hồ, thiếu actor, thiếu điều kiện, thiếu kết quả. Câu hỏi cần quyết định nghiệp vụ: quy tắc, quyền hạn, ưu tiên hoặc phạm vi cần stakeholder chốt.

AI có thể phát hiện khoảng trống. Người chịu trách nhiệm nghiệp vụ mới là người quyết định cách lấp khoảng trống đó.

3. Chuyển thành hành động

Mỗi câu hỏi quan trọng cần có:

Người trả lời hoặc người phê duyệt. Nơi ghi nhận quyết định. Ảnh hưởng đến user story, flow hoặc acceptance criteria. Trạng thái theo dõi cho đến khi được làm rõ.

Lưu ý khi đưa tài liệu vào công cụ AI

Trước khi sử dụng bất kỳ công cụ AI nào, hãy tuân theo chính sách dữ liệu của tổ chức.

Một cách giảm bớt dữ liệu nhạy cảm trong ví dụ là thay thông tin cụ thể bằng placeholder:

<mã khách hàng> <số tiền> <tên đối tác> <mã hợp đồng>

Việc thay thế dữ liệu chỉ là một bước chuẩn bị. BA/PO vẫn cần xác định công cụ và môi trường sử dụng có được tổ chức phê duyệt cho loại tài liệu đó hay không.

Checklist chốt trước khi tạo Jira

[ ] Story nêu được vai trò, khả năng và giá trị mong muốn. [ ] Quy tắc nghiệp vụ có điều kiện áp dụng rõ ràng. [ ] Luồng thành công và các ngoại lệ quan trọng đã được xem xét. [ ] Acceptance criteria có thể kiểm thử bằng kết quả quan sát được. [ ] Các câu hỏi do AI nêu đã được phân loại: bỏ, hỏi lại hoặc cập nhật tài liệu. [ ] Quyết định từ stakeholder đã được ghi nhận, không chỉ nằm trong câu trả lời AI.

AI là một người đọc khó tính hữu ích trước Jira. Nhưng trách nhiệm chốt ý nghĩa nghiệp vụ vẫn thuộc về BA, PO và stakeholder. Dùng AI đúng vai sẽ giúp nhóm bước vào refinement với ít câu “ý em là…” hơn.