Bài 4 — Phát hiện Mâu thuẫn & Trùng lặp Yêu cầu bằng AI
Vấn đề
Trong một BRD dài, hai yêu cầu có thể mâu thuẫn nhau ("khách được hủy đơn bất cứ lúc nào" vs "không được hủy đơn sau khi đã thanh toán") hoặc trùng lặp với cách diễn đạt khác nhau ("gửi OTP qua SMS" và "xác thực bằng mã một lần qua tin nhắn"). Mắt người đọc tuần tự rất khó bắt các cặp này khi chúng cách nhau 40 trang. AI đọc toàn cục và so sánh từng cặp rất nhanh.
Các loại vấn đề AI giúp phát hiện
- Mâu thuẫn trực tiếp (contradiction): hai yêu cầu không thể cùng đúng.
- Trùng lặp (duplication): cùng ý, khác chữ → gây đếm trùng effort, test trùng.
- Chồng lấn/mơ hồ ranh giới (overlap): hai yêu cầu giẫm chân, không rõ cái nào ưu tiên.
- Mơ hồ định lượng: "nhanh", "nhiều", "an toàn" — không đo được.
Ví dụ cụ thể + prompt mẫu
Bạn là trợ lý rà soát chất lượng yêu cầu (requirements QA).
Đọc TOÀN BỘ danh sách yêu cầu dưới đây và tìm:
A) Các CẶP MÂU THUẪN (không thể cùng đúng)
B) Các CẶP TRÙNG LẶP / CHỒNG LẤN (cùng ý, khác diễn đạt)
C) Yêu cầu MƠ HỒ / không đo được (nêu từ ngữ gây mơ hồ)Với mỗi phát hiện, xuất: [Loại] | REQ ID liên quan | Trích nguyên văn phần xung đột |
Giải thích ngắn | Đề xuất hướng xử lý | Độ tin cậy(Cao/TB/Thấp).
Quan trọng: chỉ dùng REQ ID có trong dữ liệu.
Nếu KHÔNG tìm thấy vấn đề nào, nói rõ "không phát hiện", đừng bịa cho đủ.
[YÊU CẦU]
REQ-101: Khách hàng có thể hủy đơn hàng bất cứ lúc nào.
REQ-102: Không cho phép hủy đơn sau khi khách đã thanh toán.
REQ-103: Hệ thống gửi mã OTP qua SMS khi đăng nhập.
REQ-104: Khi đăng nhập, hệ thống xác thực bằng mã một lần gửi qua tin nhắn.
REQ-105: Trang chủ phải tải nhanh.
AI sẽ báo: REQ-101 vs REQ-102 = mâu thuẫn (đề xuất: thêm điều kiện "trước khi thanh toán"); REQ-103 vs REQ-104 = trùng lặp (gộp làm một); REQ-105 = mơ hồ ("nhanh" cần ngưỡng, ví dụ ≤2 giây).
Các bước thực hiện
- Gom toàn bộ yêu cầu của một phạm vi vào một danh sách phẳng có ID.
- Chạy prompt rà soát ở trên (nếu >50 REQ, chia theo chủ đề để giữ chất lượng).
- Lập bảng "phát hiện" và phân loại lại bằng chuyên môn — AI đề xuất, bạn quyết.
- Với mâu thuẫn: đưa ra buổi làm rõ với PO/stakeholder, ghi quyết định.
- Với trùng lặp: gộp REQ, cập nhật RTM và các test liên quan (tránh mồ côi).
- Với mơ hồ: viết lại theo tiêu chí SMART/đo được, thêm acceptance criteria.
- Lưu "nhật ký quyết định" (decision log) để về sau truy nguồn.
Template Conflict/Dup Log (tái dùng)
[REQUIREMENTS CONFLICT & DUP LOG]
ID phát hiện | Loại(Mâu thuẫn/Trùng/Mơ hồ) | REQ liên quan | Trích dẫn |
Quyết định | Người duyệt | Ngày | Trạng thái(Open/Resolved)Checklist rà soát trước khi baseline:
[ ] Đã quét mâu thuẫn toàn tập
[ ] Đã gộp/loại trùng lặp và cập nhật RTM
[ ] Mọi từ mơ hồ ("nhanh/an toàn/nhiều") đã có ngưỡng đo
[ ] Mọi phát hiện "độ tin cậy Thấp" đã được BA xác minh
[ ] Decision log đã ghi + có người duyệt
Sai lầm thường gặp
- Ảo giác mâu thuẫn. AI đôi khi "thấy" xung đột không có thật do hiểu sai nghiệp vụ đặc thù. Luôn đọc trích dẫn nguyên văn nó đưa ra; nếu nó không trích được, khả năng cao là bịa.
- Gộp trùng lặp mà quên cập nhật test/RTM → tạo test mồ côi hoặc mất truy vết. Mỗi lần gộp phải sửa RTM.
- Tin "không phát hiện" một cách tuyệt đối. AI không quét được ngữ cảnh nó không có (ví dụ ràng buộc pháp lý ngoài BRD). "Không thấy" ≠ "không có".
- Phụ thuộc quá mức để tự ý sửa yêu cầu. Mâu thuẫn yêu cầu thường phản ánh xung đột lợi ích giữa các bên — phải giải quyết bằng đối thoại, không phải AI tự chọn.
- Rò rỉ dữ liệu: danh sách yêu cầu có thể tiết lộ chiến lược sản phẩm. Dùng công cụ được duyệt.