Tiếng Việt: Hands On BA Deliverable Package

Hãy tưởng tượng bạn là Business Analyst (BA) tại VinaPay, một ví điện tử tầm trung tại Việt Nam với khoảng 15.000 giao dịch/ngày qua 5 đối tác: 3 ngân hàng liên kết và 2 cổng thanh toán (Napas, VNPay). Ban Giám Đốc vừa phê duyệt dự án "triển khai tính năng đối soát giao dịch tự động (auto-reconciliation) cho ví điện tử" sau khi phòng Kế toán báo cáo rằng quy trình đối soát thủ công hiện tại đang tiêu tốn 3-4 giờ/ngày của 2 nhân sự, phát hiện giao dịch treo (stuck transaction) chậm 3-5 ngày, và vừa suýt bị nhắc nhở trong đợt kiểm toán nội bộ vì thiếu audit trail rõ ràng. Bạn được giao trách nhiệm chủ trì toàn bộ phân tích nghiệp vụ cho dự án này, từ việc hiểu quy trình hiện tại, phỏng vấn stakeholder, đến việc chốt acceptance criteria và bàn giao một bộ deliverable hoàn chỉnh cho đội kỹ thuật và Ban Giám Đốc.

Đây chính là bài tập capstone của module này: một case study xuyên suốt, nối liền bốn kỹ năng đã học — process mapping, stakeholder elicitation, data modeling/gap analysis, và acceptance criteria/Definition of Done — thành MỘT quy trình làm việc thật, với AI hỗ trợ ở mọi giai đoạn. Chúng ta sẽ đi từ đầu đến cuối cùng một bối cảnh: tính năng đối soát giao dịch tự động cho ví điện tử VinaPay. Mỗi phần dưới đây không chỉ hướng dẫn "làm sao" mà còn cho ra sản phẩm thật — process map, transcript phỏng vấn, acceptance criteria, ERD, gap analysis, và cuối cùng là một bộ deliverable sẵn sàng trình bày trước stakeholder.

Map Quy Trình Nghiệp Vụ Và Xác Định Cơ Hội Cải Tiến Với AI

Bước đầu tiên của bất kỳ dự án BA nghiêm túc nào là hiểu rõ quy trình đang vận hành thực tế — không phải quy trình "trên giấy" mà quy trình người ta thực sự làm mỗi ngày. Với VinaPay, đó là quy trình đối soát thủ công đang chạy giữa phòng Kế toán và 5 đối tác thanh toán.

Quy Trình As-Is: Đối Soát Thủ Công Hiện Tại

Sau khi quan sát trực tiếp và phỏng vấn nhanh nhân viên đối soát, quy trình as-is (hiện trạng) được ghi nhận như sau:

Cơ Hội Cải Tiến Được Xác Định

Từ quy trình as-is trên, các bottleneck (điểm nghẽn) và cơ hội cải tiến rõ ràng nhất là:

1. Chi phí thời gian lớn hàng ngày: 2-3 giờ/ngày cho một tác vụ lặp lại có pattern rõ ràng — ứng viên hoàn hảo cho tự động hóa.
2. Sai sót do đối chiếu thủ công: mã giao dịch có format khác nhau giữa các đối tác (ví dụ ngân hàng dùng prefix BANK-, Napas dùng số thuần) khiến VLOOKUP bỏ sót hoặc match sai.
3. Độ trễ phát hiện giao dịch treo: 3-5 ngày mới phát hiện được giao dịch bị "treo" (tiền đã trừ nhưng chưa ghi nhận ở phía đối tác), ảnh hưởng trực tiếp trải nghiệm khách hàng và dòng tiền công ty.
4. Thiếu audit trail chuẩn: ghi chú tay trong Excel không đáp ứng yêu cầu lưu vết của kiểm toán nội bộ và quy định của Ngân hàng Nhà nước về hoạt động trung gian thanh toán.
5. Không có cảnh báo real-time: discrepancy (sai lệch) vượt ngưỡng rủi ro (ví dụ tổng giá trị lệch/ngày > 50 triệu đồng) không được cảnh báo ngay mà phải chờ đến báo cáo cuối tháng.
6. Format dữ liệu không đồng nhất: mỗi đối tác trả file theo cấu trúc riêng, tốn effort chuẩn hóa thủ công lặp lại mỗi ngày.

Các Bước Thực Hành

1. Thu thập input quan sát thực tế: ghi hình màn hình, chụp ảnh file Excel mẫu, hoặc note trực tiếp khi ngồi cạnh nhân viên đối soát trong 1-2 ngày làm việc thật.
2. Đưa toàn bộ ghi chú quan sát vào AI, yêu cầu nó tái cấu trúc thành các bước quy trình tuần tự, có actor (người thực hiện) và thời gian ước lượng rõ ràng cho từng bước.
3. Yêu cầu AI phân tích từng bước để tìm dấu hiệu bottleneck: bước nào tốn thời gian bất thường, bước nào phụ thuộc con người thao tác thủ công lặp lại, bước nào có rủi ro sai sót cao.
4. Dùng Miro hoặc Lucidchart để vẽ lại quy trình dưới dạng BPMN (Business Process Model and Notation) trực quan, dựa trên danh sách bước đã được AI cấu trúc.
5. Review sơ đồ cùng phòng Kế toán và IT để xác nhận tính chính xác trước khi dùng làm nền tảng cho bước elicit requirement tiếp theo.

Ví Dụ Prompt

Bạn là một Business Analyst chuyên phân tích quy trình vận hành cho
lĩnh vực fintech. Dưới đây là ghi chú quan sát thô về quy trình đối
soát giao dịch thủ công tại một ví điện tử:

[PASTE GHI CHÚ QUAN SÁT/PHỎNG VẤN THÔ VÀO ĐÂY]

Hãy thực hiện:
1. Tái cấu trúc thành danh sách các bước quy trình tuần tự, mỗi bước
   gồm: mô tả hoạt động, actor thực hiện, thời gian ước lượng, input/
   output của bước đó.
2. Với mỗi bước, đánh giá xem đây có phải là điểm nghẽn (bottleneck)
   không, dựa trên: thời gian tiêu tốn, mức độ thao tác thủ công, khả
   năng gây sai sót con người, và mức độ phụ thuộc vào bên thứ ba.
3. Xuất danh sách tối đa 6 cơ hội cải tiến cụ thể, mỗi cơ hội gắn với
   bước quy trình tương ứng, ưu tiên theo mức độ ảnh hưởng đến chi phí
   vận hành và trải nghiệm khách hàng.

Trả lời bằng tiếng Việt, giữ nguyên thuật ngữ: bottleneck, process
mapping, BPMN.

Output mẫu AI trả về (rút gọn):

Mẹo: Đừng để AI vẽ BPMN diagram thay bạn ngay từ đầu — hãy để nó xuất danh sách bước có cấu trúc dạng text/bảng trước, sau đó con người tự vẽ lại bằng Miro/Lucidchart. AI thường "tưởng tượng" thêm các nhánh rẽ (decision gateway) không tồn tại trong thực tế nếu bạn giao nó vẽ diagram trực tiếp mà không qua bước xác nhận trung gian.

Elicit Và Cấu Trúc Requirements Từ Bản Ghi Phỏng Vấn Stakeholder

Sau khi có bức tranh quy trình as-is, bước tiếp theo là ngồi lại với các stakeholder chính — ở đây là chị Lan (Trưởng phòng Kế toán) và anh Minh (Trưởng phòng Vận hành) — để hiểu rõ họ kỳ vọng gì ở tính năng đối soát tự động, và đâu là các ràng buộc nghiệp vụ/compliance cần tuân thủ.

Trích Đoạn Phỏng Vấn Stakeholder

Dưới đây là một đoạn ngắn trong buổi phỏng vấn thực tế (elicitation session) giữa BA và hai stakeholder:

BA: Chị Lan cho em hỏi, hiện tại giao dịch treo mình phát hiện trễ nhất là bao lâu ạ?

Chị Lan: Có lần lên tới 5 ngày em ạ, vì phải chờ đối tác trả file rồi mới đối chiếu tay được. Chị muốn hệ thống mới phải cảnh báo trong vòng tối đa 1 giờ sau khi phát hiện lệch, không thể để 5 ngày như bây giờ nữa.

BA: Vậy khi phát hiện lệch, chị cần hệ thống phân loại nguyên nhân như thế nào ạ?

Chị Lan: Ít nhất phải phân biệt được 4 loại: giao dịch treo do đối tác chậm trả file, lệch do phí giao dịch tính sai, giao dịch bị trùng, và giao dịch có ở ví nhưng không có ở đối tác (hoặc ngược lại). Mỗi loại xử lý khác nhau.

Anh Minh: Bên vận hành thì chị muốn nhấn mạnh thêm là mọi thay đổi thủ công vào sổ cái sau khi đối soát phải được ghi log đầy đủ — ai sửa, sửa lúc nào, lý do gì. Kiểm toán năm ngoái đã nhắc bọn em về việc này rồi.

BA: Dạ, vậy về khối lượng, hệ thống cần xử lý được tối đa bao nhiêu giao dịch một ngày ạ?

Chị Lan: Hiện tại khoảng 15.000 giao dịch/ngày, nhưng theo kế hoạch tăng trưởng thì cuối năm sau có thể lên 40.000-50.000/ngày, nên hệ thống phải scale được.

Requirements Được AI Cấu Trúc Từ Transcript

Từ đoạn transcript trên (và các đoạn phỏng vấn khác không trích ở đây), AI tổng hợp thành danh sách requirement có cấu trúc như sau:

Functional Requirements:

Non-Functional Requirements:

Các Bước Thực Hành

1. Ghi âm (có xin phép) hoặc ghi chú song song trong buổi phỏng vấn với từng stakeholder, giữ nguyên văn càng nhiều càng tốt thay vì diễn giải lại ngay lúc phỏng vấn.
2. Đưa transcript thô vào AI ngay sau buổi phỏng vấn, khi ngữ cảnh còn "nóng", yêu cầu nó trích xuất riêng biệt functional requirement và non-functional requirement.
3. Yêu cầu AI gắn mỗi requirement với câu trích dẫn gốc làm bằng chứng (traceability), không để requirement "trôi nổi" không rõ nguồn.
4. Rà lại danh sách requirement với chính stakeholder đã phỏng vấn trong vòng 24-48 giờ, xác nhận AI hiểu đúng ý, không suy diễn sai.
5. Đưa các requirement đã xác nhận vào backlog dưới dạng epic/story, chuẩn bị cho bước viết acceptance criteria chi tiết.

Ví Dụ Prompt

Bạn là một Business Analyst giàu kinh nghiệm trong lĩnh vực thanh toán
điện tử. Dưới đây là bản ghi phỏng vấn stakeholder về nhu cầu cho tính
năng đối soát giao dịch tự động:

[PASTE TRANSCRIPT PHỎNG VẤN VÀO ĐÂY]

Hãy thực hiện:
1. Trích xuất tất cả Functional Requirement (FR) — mô tả hệ thống PHẢI
   làm gì. Mỗi FR gắn với câu trích dẫn nguyên văn làm bằng chứng.
2. Trích xuất tất cả Non-Functional Requirement (NFR) — hiệu năng, bảo
   mật, compliance, khả năng mở rộng. Mỗi NFR cũng gắn trích dẫn nguồn
   hoặc ghi rõ "suy luận từ ràng buộc ngành" nếu không có câu trích dẫn
   trực tiếp.
3. Đánh dấu các requirement còn mơ hồ, cần hỏi lại stakeholder để làm
   rõ trước khi đưa vào backlog chính thức.
4. Xuất kết quả dưới dạng 2 bảng Markdown: FR và NFR, mỗi bảng có cột
   Mã, Requirement, Nguồn/Trích dẫn.

Trả lời bằng tiếng Việt, giữ nguyên thuật ngữ: Functional Requirement,
Non-Functional Requirement, traceability.

Mẹo: Luôn giữ transcript gốc lại cùng với bảng requirement đã cấu trúc, không xóa đi sau khi AI xử lý xong. Khi có tranh cãi về scope giữa BA và dev/PO sau này, transcript gốc là bằng chứng traceability (khả năng truy vết) duy nhất chứng minh requirement đến từ đâu, không phải do BA "tự nghĩ ra".

Generate Acceptance Criteria, Data Model Và Gap Analysis Report

Có requirement rồi, bước tiếp theo là biến chúng thành thứ đội kỹ thuật có thể implement và test được: acceptance criteria cụ thể, data model (mô hình dữ liệu) rõ ràng, và một gap analysis (phân tích khoảng cách) đối chiếu hiện trạng với trạng thái mong muốn.

Acceptance Criteria Cho FR-02 (Phân Loại Discrepancy Tự Động)

Lấy FR-02 làm ví dụ — yêu cầu quan trọng nhất về mặt nghiệp vụ — acceptance criteria theo format Given-When-Then được soạn như sau:

Given một giao dịch tồn tại trong core ledger nhưng KHÔNG xuất hiện
  trong file settlement của đối tác tương ứng sau 24 giờ kể từ giờ
  giao dịch
When hệ thống chạy chu kỳ đối soát tự động
Then giao dịch được gắn nhãn "Giao dịch treo" (stuck transaction)
  và được đưa vào hàng đợi cảnh báo trong vòng 1 giờ

Given một giao dịch có mặt ở cả core ledger và file settlement, nhưng
  số tiền phí (fee) ghi nhận khác nhau giữa hai nguồn
When hệ thống so khớp giao dịch theo mã giao dịch
Then giao dịch được gắn nhãn "Lệch phí" (fee mismatch) kèm số tiền
  chênh lệch cụ thể

Given hai giao dịch có cùng mã giao dịch, cùng số tiền, xuất hiện
  trong cùng file settlement của một đối tác
When hệ thống chạy đối soát
Then giao dịch được gắn nhãn "Giao dịch trùng" (duplicate) và chỉ
  một giao dịch được ghi nhận vào sổ cái chính thức

Given một giao dịch xuất hiện trong file settlement của đối tác
  nhưng KHÔNG có bản ghi tương ứng trong core ledger
When hệ thống chạy đối soát
Then giao dịch được gắn nhãn "Giao dịch một chiều" (one-sided) và
  được escalate (chuyển cấp) cho Trưởng nhóm kế toán xử lý thủ công

Data Model: ERD Cho Tính Năng Đối Soát

Mô hình dữ liệu (data model) tối thiểu cần có, thể hiện dưới dạng bảng entity và quan hệ (có thể dựng trực tiếp trong dbdiagram.io):

Gap Analysis: Hiện Trạng So Với Trạng Thái Mong Muốn

Các Bước Thực Hành

1. Với mỗi FR đã chốt ở bước trước, đưa vào AI để sinh acceptance criteria theo Given-When-Then, yêu cầu bao phủ cả happy path và các discrepancy type đã liệt kê.
2. Đưa toàn bộ danh sách entity/thuộc tính nghiệp vụ (rút ra từ requirement) vào AI, yêu cầu đề xuất ERD ở dạng text, sau đó dựng trực quan bằng dbdiagram.io hoặc Lucidchart.
3. Review ERD cùng dev backend để xác nhận tính khả thi kỹ thuật — đặc biệt kiểm tra xem entity AuditLog có đáp ứng đúng yêu cầu compliance đã nêu trong FR-04 không.
4. Đưa mô tả as-is (từ Section 1) và to-be (từ requirement đã chốt) vào AI, yêu cầu sinh bảng gap analysis theo từng khía cạnh (tốc độ, độ chính xác, compliance, khả năng mở rộng).
5. Ưu tiên hóa các gap theo mức độ ảnh hưởng và độ phức tạp kỹ thuật để lập roadmap triển khai theo giai đoạn (phase), không cố làm hết một lần.

Ví Dụ Prompt

Bạn là Business Analyst phụ trách thiết kế chi tiết cho tính năng đối
soát giao dịch tự động. Dưới đây là một Functional Requirement:

"FR-02: Phân loại discrepancy tự động thành 4 nhóm: giao dịch treo,
lệch phí, giao dịch trùng, giao dịch một chiều."

Hãy sinh acceptance criteria theo format Given-When-Then, tối thiểu
4 tiêu chí (mỗi loại discrepancy 1 tiêu chí), đảm bảo:
- Điều kiện Given nêu rõ trạng thái dữ liệu cụ thể (không mơ hồ).
- Điều kiện Then nêu rõ kết quả có thể kiểm tra được (nhãn gắn vào
  giao dịch, hành động hệ thống thực hiện tiếp theo).

Trả lời bằng tiếng Việt, giữ nguyên cấu trúc Given-When-Then.

Dưới đây là danh sách requirement liên quan đến dữ liệu của tính năng
đối soát giao dịch:

[PASTE FR-01 ĐẾN FR-05 VÀ NFR-01 ĐẾN NFR-03]

Hãy đề xuất một Entity-Relationship Model (ERD) tối thiểu đáp ứng các
requirement trên, gồm:
1. Danh sách entity, mỗi entity kèm 4-6 thuộc tính chính.
2. Quan hệ giữa các entity (1-1, 1-nhiều, nhiều-nhiều), giải thích lý
   do chọn loại quan hệ đó.
3. Chỉ rõ entity nào phục vụ trực tiếp yêu cầu audit trail (FR-04).

Xuất kết quả dưới dạng bảng Markdown: Entity | Thuộc tính chính |
Quan hệ. Trả lời bằng tiếng Việt, giữ nguyên thuật ngữ: ERD, entity,
foreign key.

Mẹo: Đừng để AI tự quyết định loại quan hệ (1-1 hay 1-nhiều) cho các entity nghiệp vụ nhạy cảm như Discrepancy hay AuditLog mà không hỏi lại dev backend. AI thường chọn quan hệ "hợp lý về mặt lý thuyết" nhưng có thể không khớp với ràng buộc thực tế của hệ thống core ledger hiện có — luôn đối chiếu ERC đề xuất với schema database hiện tại trước khi chốt.

Xây Dựng Một Bộ Deliverable Business Analysis Sẵn Sàng Trình Bày Trước Stakeholder

Bước cuối cùng của capstone này là đóng gói toàn bộ output — process map, requirement, acceptance criteria, ERD, gap analysis — thành MỘT bộ tài liệu mạch lạc, để Ban Giám Đốc, đội kỹ thuật và các phòng ban liên quan đều có thể đọc, hiểu và ra quyết định dựa trên đó.

Cấu Trúc Bộ Deliverable Cuối Cùng

Bộ tài liệu BRD/Functional Spec (Business Requirement Document) hoàn chỉnh cho dự án đối soát giao dịch tự động VinaPay nên có cấu trúc mục lục như sau:

1. Executive Summary (Tóm tắt điều hành)
2. Bối cảnh và mục tiêu dự án
   2.1. Vấn đề hiện tại (quy trình as-is, số liệu chi phí/thời gian)
   2.2. Mục tiêu kinh doanh và chỉ số thành công (KPI)
3. Quy trình nghiệp vụ
   3.1. Sơ đồ quy trình As-Is (BPMN)
   3.2. Sơ đồ quy trình To-Be (BPMN)
   3.3. Danh sách bottleneck và cơ hội cải tiến
4. Yêu cầu nghiệp vụ (Requirements)
   4.1. Functional Requirements (FR-01 đến FR-05)
   4.2. Non-Functional Requirements (NFR-01 đến NFR-03)
   4.3. Nguồn gốc requirement (traceability tới phỏng vấn/quan sát)
5. Acceptance Criteria và Definition of Done
   5.1. Acceptance Criteria theo Given-When-Then cho từng FR
   5.2. Definition of Done tổng thể của dự án
6. Data Model
   6.1. ERD tổng thể
   6.2. Mô tả chi tiết từng entity
7. Gap Analysis
   7.1. Bảng so sánh As-Is và To-Be
   7.2. Đề xuất roadmap triển khai theo giai đoạn
8. Rủi ro và giả định (Risks & Assumptions)
9. Phụ lục (transcript phỏng vấn, dữ liệu thô, biên bản họp)

Mẫu Trích Đoạn Executive Summary

Dưới đây là ví dụ đoạn Executive Summary hoàn chỉnh, sẵn sàng đưa vào tài liệu trình Ban Giám Đốc:

Tóm tắt điều hành: Quy trình đối soát giao dịch thủ công hiện tại tiêu tốn 3-4 giờ/ngày của 2 nhân sự phòng Kế toán, phát hiện giao dịch treo chậm tới 5 ngày, và không đáp ứng đầy đủ yêu cầu audit trail của kiểm toán nội bộ. Dự án triển khai tính năng đối soát giao dịch tự động sẽ giảm thời gian phát hiện discrepancy xuống dưới 1 giờ, tự động phân loại 4 nhóm nguyên nhân sai lệch, và xây dựng audit trail đầy đủ đáp ứng quy định của Ngân hàng Nhà nước. Hệ thống được thiết kế để xử lý tối thiểu 50.000 giao dịch/ngày, đáp ứng kế hoạch tăng trưởng đến cuối năm sau. Tài liệu này trình bày chi tiết yêu cầu nghiệp vụ, acceptance criteria, data model và gap analysis làm cơ sở cho đội kỹ thuật ước lượng effort và lên kế hoạch triển khai theo 3 giai đoạn.

Các Bước Thực Hành

1. Tổng hợp toàn bộ output đã tạo ra ở ba phần trước (process map, requirement, acceptance criteria, ERD, gap analysis) vào một thư mục làm việc chung, đặt tên file rõ ràng theo cấu trúc mục lục.
2. Đưa tất cả nội dung thô vào AI, yêu cầu viết Executive Summary súc tích (150-200 từ), nêu bật vấn đề, giải pháp, và lợi ích đo lường được — dành cho người đọc không có thời gian đọc hết tài liệu chi tiết.
3. Dùng AI để rà soát tính nhất quán giữa các phần: kiểm tra xem mọi FR có acceptance criteria tương ứng không, mọi entity trong ERD có phục vụ ít nhất một requirement không, mọi gap trong gap analysis có được đề cập ở phần roadmap không.
4. Đưa toàn bộ tài liệu vào Confluence hoặc Notion theo đúng cấu trúc mục lục, gắn link chéo giữa các phần (ví dụ từ FR-02 link sang acceptance criteria tương ứng và entity Discrepancy trong ERD).
5. Tổ chức một buổi trình bày (walkthrough) 30-45 phút với Ban Giám Đốc, phòng Kế toán, phòng Vận hành và đội kỹ thuật, dùng chính bộ tài liệu này làm nền, thu thập phản hồi cuối cùng trước khi chuyển giao cho sprint planning.

Ví Dụ Prompt

Bạn là Business Analyst chuẩn bị bàn giao tài liệu dự án cho Ban Giám
Đốc và đội kỹ thuật. Dưới đây là toàn bộ nội dung đã hoàn thiện của dự
án đối soát giao dịch tự động:

[PASTE: process map, danh sách FR/NFR, acceptance criteria, ERD, gap
analysis đã hoàn thiện ở các bước trước]

Hãy thực hiện:
1. Viết một đoạn Executive Summary 150-200 từ, nêu rõ: vấn đề hiện tại
   (kèm số liệu cụ thể), giải pháp đề xuất, lợi ích đo lường được, và
   phạm vi tài liệu này bao gồm những gì.
2. Rà soát tính nhất quán: liệt kê nếu có FR nào chưa có acceptance
   criteria tương ứng, entity nào trong ERD không phục vụ requirement
   nào, hoặc gap nào trong gap analysis chưa có đề xuất roadmap xử lý.
3. Đề xuất cấu trúc mục lục hoàn chỉnh cho tài liệu BRD, đánh số phần/
   mục rõ ràng, sẵn sàng đưa vào Confluence.

Trả lời bằng tiếng Việt, giữ nguyên thuật ngữ: Executive Summary, BRD,
traceability, roadmap.

Output rà soát tính nhất quán mẫu (rút gọn):

Mẹo: Trước buổi trình bày chính thức với Ban Giám Đốc, luôn chạy một vòng "stress test" tài liệu bằng cách nhờ AI đóng vai một stakeholder khó tính (ví dụ CFO hoặc kiểm toán viên) đặt câu hỏi phản biện về tài liệu. Điều này giúp bạn phát hiện lỗ hổng lập luận hoặc thiếu số liệu trước khi bị hỏi thật trong phòng họp, nơi bạn không có cơ hội sửa lại câu trả lời.

Những Điểm Chính Cần Nhớ

• Một capstone BA thực thụ là một chuỗi liên tục — process mapping, elicitation, data modeling/gap analysis, acceptance criteria — không phải bốn bài tập rời rạc; AI phát huy giá trị lớn nhất khi được dùng nhất quán xuyên suốt cùng một bối cảnh nghiệp vụ.
• Process mapping nên bắt đầu từ quan sát/ghi chú thô, để AI cấu trúc thành các bước có actor và thời gian rõ ràng, rồi con người xác nhận trước khi vẽ BPMN chính thức.
• Requirement luôn phải gắn với trích dẫn nguồn (traceability) từ transcript phỏng vấn hoặc quan sát thực tế — không để AI "suy diễn" requirement không có bằng chứng.
• Acceptance criteria, ERD và gap analysis phải được đối chiếu chéo lẫn nhau: mỗi requirement cần có acceptance criteria tương ứng, mỗi entity trong data model phải phục vụ ít nhất một requirement, mỗi gap phải có hướng xử lý trong roadmap.
• Bộ deliverable cuối cùng chỉ có giá trị khi nó mạch lạc và dễ đọc với người không tham gia sâu vào quá trình phân tích — dùng AI để viết Executive Summary súc tích và rà soát tính nhất quán trước khi trình bày, nhưng luôn tự kiểm tra lại bằng vai trò một stakeholder phản biện trước buổi họp thật.