AI 需求追蹤矩陣：由 User Story 到 Test Case 嘅可追溯性工作流
2026-08-12 · BA × AI 實戰 · Eric Cheung
點解需求追蹤係 BA 嘅隱形工作
寫 User Story 好爽。但三個月之後，當業務部門問「呢個需求改咗，邊啲測試要重跑？」，你答唔答得出？需求追蹤矩陣（Requirements Traceability Matrix, RTM）就係用嚟答呢條問題嘅工具：將需求、設計、測試案例三者嘅連結記錄低，等你隨時可以追溯、分析影響、證明覆蓋——audit 同 change control 會議上，呢份嘢就係你嘅護身符。
傳統做法係用 Excel 手動維護，需求一多就失控：連結斷咗、缺口睇唔到、變更影響靠記憶。AI 嘅角色唔係取代你嘅判斷，而係幫你快速建立矩陣、偵測缺口、做影響分析——你呢個 BA 就負責判斷同驗證。呢篇文章行一次 5 步工作流，由一份乾淨嘅需求清單去到變更影響分析。
快速結論（TL;DR）
- 需求追蹤矩陣（RTM）將需求、設計同測試案例嘅連結記錄低，喺 audit 同 change control 會議上就係你嘅護身符。
- 5 步工作流係將 PRD 拆成結構化需求清單 → 連結 User Story 同 Acceptance Criteria → 對應 Test Case → 覆蓋率分析 → 變更影響分析。
- 覆蓋率分析要同時睇正向缺口、測試缺口同反向缺口（orphan tests）——冇需求支持嘅測試可能係廢 test，亦可能代表需求寫漏咗。
- 所有 AI 建議嘅連結都要你確認，呢個唔係可選步驟，而係 BA 嘅核心價值。
5 步工作流：由需求清單到變更影響分析
Step 1 — 將 PRD 變成結構化需求清單
一切由一份乾淨嘅需求清單開始。將 BRD/PRD 入面嘅功能需求同非功能需求拆成帶編號嘅條目（例如 FR-001、NFR-001），每條有唯一 ID、描述、優先級同來源（邊個會議、邊位 stakeholder 提出）。AI 可以幫你由 PRD 草稿抽取出需求條目——但一定要覆核：AI 有時會漏走隱含需求（例如「用戶要登入」隱含「登出」），或者將兩個唔同嘅需求合併埋一條。
以下係我哋 PRD 嘅內容。請幫我抽取出結構化需求清單：
1. 每條需求俾一個 ID（FR-001 / NFR-001 格式）
2. 每條包括：描述、優先級（Must/Should/Could）、來源
3. 區分功能需求同非功能需求
4. 標出你「唔肯定」嘅地方等我覆核
5. 特別留意隱含需求（例如「用戶要登入」隱含「登出」）
--- 貼上 PRD 內容 ---Step 2 — 建立 User Story 同 Acceptance Criteria 連結
將需求條目對應到 User Story：每條需求至少有一張 Story 承接，而 Story 嘅 Acceptance Criteria 就係需求嘅驗收證明。AI 可以根據語義相似度幫你生成建議對應——但最終連結一定要你確認，因為兩條需求睇落好似，實際可能係兩回事。呢個確認動作就係 BA 嘅判斷力所在，千祈唔好跳過。
以下係需求清單同 User Stories。請幫我建議對應：
1. 每條需求至少配一張承接嘅 Story
2. 列出「需求 → Story → Acceptance Criteria」嘅建議連結
3. 標出：冇 Story 承接嘅需求、同埋一張 Story 對應多條需求嘅情況（可能代表 Story 太大，要拆）
4. 解釋每個建議連結嘅理由，等我判斷
--- 需求清單 ---
--- User Stories ---Step 3 — 將 Test Case 同 UAT 腳本對應返需求
每個 Acceptance Criteria 至少有一個 Test Case，測試先算有真正覆蓋。AI 可以幫你由 Story 同 AC 生成測試案例，並自動建立「需求 → Story → Test Case」嘅三層連結；你嘅工作係檢查每個 Test Case 係咪真係驗證到嗰條需求——最怕出現「有測試，但測錯嘢」嘅情況。呢步同 8-08 嗰篇 test automation 文章互補：嗰篇講點樣生成測試，呢篇講點樣將測試綁返落需求。
以下係 User Stories 同 Acceptance Criteria。請幫我：
1. 為每個 Acceptance Criteria 生成對應嘅 Test Case（正/反向至少各一個）
2. 建立「需求 → Story → Test Case」三層連結
3. 標出你覺得測試案例「驗證唔到」原意嘅位置
4. 輸出格式：表格（需求 ID | Story ID | AC | Test Case | 驗證方法）
--- 貼上 User Stories ---Step 4 — 覆蓋率分析：搵出冇人測試嘅需求
矩陣建立之後，用 AI 做覆蓋率分析：邊啲需求冇 Story 承接（正向缺口）、邊啲 Story 冇 Test Case（測試缺口）、邊啲 Test Case 冇對應需求（反向缺口／orphan tests）。呢步最直接體現 AI 嘅價值——喺幾百行 Excel 入面搵缺口，人眼好易睇漏，AI 一秒搞掂。反向缺口特別重要：冇需求支持嘅測試可能係廢 test，亦可能代表需求本身寫漏咗。
以下係我嘅需求追蹤矩陣資料。請幫我做覆蓋率分析：
1. 邊啲需求冇 Story 承接（正向缺口）
2. 邊啲 Story 冇 Test Case（測試缺口）
3. 邊啲 Test Case 冇對應需求（反向缺口 / orphan tests）
4. 用表格輸出，並按影響程度排序
--- 貼上追蹤矩陣資料 ---Step 5 — 變更影響分析：需求改咗，邊啲嘢要跟住改
需求變更係 BA 嘅日常。當 FR-003 改咗，你要即刻答到：影響邊張 Story？邊啲 Test Case 要更新？邊個 module 嘅設計要改？AI 幫你由追蹤矩陣逆向追蹤，列出完整影響鏈，等你喺 change control board 會議上可以講得出：「呢個變更加埋要更新 5 個 Test Case，估計 2 日工作量」——有依據嘅影響分析，就係 BA 喺會議上嘅話語權。
以下係我嘅需求追蹤矩陣。需求 FR-003 啱啱變更咗，請幫我做影響分析：
1. 列出受影響嘅 User Stories 同 Acceptance Criteria
2. 列出需要更新嘅 Test Case（連埋估計更新工作量）
3. 列出相關嘅設計/文件
4. 輸出完整影響鏈：FR-003 → Story → AC → Test Case
--- 貼上追蹤矩陣資料 ---3 個常見陷阱
- 陷阱一：矩陣變咗「寫完就算」嘅文件。RTM 嘅價值喺持續維護——每次需求變更都要同步更新，否則三個月後就係一份唔準嘅古董。將矩陣更新寫入 Definition of Done，等佢變成每個 sprint 嘅例行公事。
- 陷阱二：完全信晒 AI 嘅對應建議。AI 嘅語義相似判斷會出錯——兩條需求睇落好似但其實係兩回事。所有 AI 建議嘅連結都要你確認，呢個唔係可選步驟，而係 BA 嘅核心價值。
- 陷阱三：淨係追「正向覆蓋」，唔理「反向覆蓋」。Orphan test case（冇需求支持嘅測試）一樣重要：佢可能係廢 test，亦可能代表需求寫漏咗——兩種情況都值得你追查。
總結
需求追蹤矩陣係 BA 最基本、又最易被忽略嘅 deliverable。AI 唔會取代你做判斷，但可以將建立同維護矩陣嘅時間由幾日壓縮到幾粒鐘，仲幫你睇到人眼睇唔到嘅缺口。當你喺下一個 audit 或者 change request 會議上，可以即刻拉出「需求 → 測試」嘅完整鏈，你就由「寫文件嘅 BA」升級做「管理需求生命週期嘅 BA」——呢個就係 AI 時代嘅競爭力。