Bài 1 — Vì sao Traceability là nỗi đau của BA và AI giúp được gì
Bối cảnh: một ngày điển hình của BA
Bạn là BA cho một dự án core-banking. Sprint 9 đang chạy, Product Owner nhắn: "Khách hàng đổi quy định tính lãi suất, ảnh hưởng những gì?". Bạn mở file BRD 80 trang, mở Jira, mở bộ test case trên Excel, rồi bắt đầu dò tay từng dòng. 90 phút sau bạn vẫn không chắc mình đã tìm hết. Đây chính là traceability gap — không có sợi dây nối rõ ràng giữa yêu cầu ↔ thiết kế ↔ test case ↔ code.
Hậu quả thật: một thay đổi nhỏ lọt lưới → test thiếu → bug lên production → mất niềm tin. Traceability không phải thủ tục hành chính; nó là hệ thần kinh của dự án.
Traceability Matrix là gì (nói ngắn gọn)
Ma trận truy vết (RTM - Requirements Traceability Matrix) là bảng ánh xạ mỗi yêu cầu tới các artifact liên quan:
| Req ID | Mô tả yêu cầu | Nguồn | Thiết kế/US | Test case | Trạng thái |
|---|---|---|---|---|---|
| REQ-012 | Tính lãi kép theo ngày | BRD 4.2 | US-45 | TC-88, TC-89 | Đã test |
AI thay đổi cuộc chơi ở đâu
AI (ChatGPT, Claude, Copilot, hay agent nội bộ) giỏi 3 việc mà BA tốn thời gian nhất:
- Trích xuất yêu cầu từ văn bản dài, lộn xộn thành danh sách có cấu trúc.
- Ánh xạ (mapping) yêu cầu với test/thiết kế dựa trên ngữ nghĩa, không chỉ khớp từ khóa.
- Phát hiện lỗ hổng: yêu cầu chưa có test, test mồ côi, yêu cầu mâu thuẫn/trùng.
Ví dụ cụ thể + prompt mẫu
Giả sử bạn có 3 đoạn BRD rời rạc. Prompt để AI trích xuất thành khung RTM:
Bạn là trợ lý BA. Từ đoạn tài liệu dưới đây, trích xuất các YÊU CẦU CHỨC NĂNG riêng biệt.
Với mỗi yêu cầu, xuất bảng markdown gồm cột: Req ID (đặt REQ-001, 002...),
Mô tả (1 câu, giọng "Hệ thống phải..."), Nguồn (số mục trong tài liệu),
Loại (functional/non-functional), Độ ưu tiên đoán (cao/trung/thấp + lý do 1 dòng).
KHÔNG bịa yêu cầu không có trong văn bản. Nếu một câu mơ hồ, đánh dấu [CẦN LÀM RÕ].Tài liệu:
"""
<dán đoạn BRD ở đây>
"""
Các bước bắt đầu ngay hôm nay
- Chọn 1 module nhỏ (5–15 yêu cầu) để làm thí điểm, đừng ôm cả dự án.
- Gom artifact vào một chỗ: đoạn BRD, danh sách user story, danh sách test case (dạng text/CSV).
- Chạy prompt trích xuất ở trên để có khung REQ ID chuẩn hóa.
- Rà soát bản nháp AI: sửa mô tả, gỡ [CẦN LÀM RÕ], xác nhận Req ID.
- Lưu bảng vào file nguồn duy nhất (Google Sheet/Confluence) làm "single source of truth".
- Ghi lại thời gian tiết kiệm được — dữ liệu này giúp bạn thuyết phục sếp mở rộng.
Template khởi động (tái dùng)
[RTM SEED CHECKLIST]
[ ] Phạm vi thí điểm đã chọn (module/epic): ______
[ ] Đã gom: BRD ____ US ____ Testcase ____
[ ] Quy ước Req ID: REQ-### (đã chốt)
[ ] Prompt trích xuất đã lưu trong thư viện prompt
[ ] Bản nháp AI đã được BA review (không dùng thô)
[ ] File nguồn duy nhất đã tạo + phân quyền
[ ] Ghi nhận thời gian trước/sau
Sai lầm thường gặp
- Tin bản nháp AI là sự thật cuối cùng. AI có thể ảo giác (hallucination) — bịa ra yêu cầu "REQ-013: hỗ trợ đa tiền tệ" mà BRD không hề nhắc. Luôn yêu cầu AI trích dẫn nguồn (số mục) và tự đối chiếu.
- Dán nguyên tài liệu mật lên công cụ public. BRD core-banking có thể chứa PII/dữ liệu nhạy cảm → rò rỉ dữ liệu. Ẩn danh số liệu, dùng công cụ được duyệt (bản enterprise không train trên dữ liệu bạn), hoặc chỉ dán phần khung.
- Ôm cả dự án ngay lần đầu → nản, bỏ cuộc. Thí điểm nhỏ, thắng nhỏ, rồi mở rộng.
- Phụ thuộc quá mức: coi AI là người quyết. AI ánh xạ theo ngữ nghĩa nên vẫn sai chỗ tế nhị (nghiệp vụ đặc thù). BA vẫn là người ký duyệt.