許多專案在上線前看起來一切正常：需求文件有了、開發任務關閉了、測試報告也顯示大多通過。但真正上線後，需求方卻說「這不是我要的」，測試團隊說「文件沒有寫」，開發團隊則說「我們照任務做了」。

問題往往不是大家沒有做事，而是中間缺少一條可以回查的關係鏈。

這就是需求追溯矩陣的用途。

需求追溯矩陣不是另一張進度表

一般進度表回答的是：誰在做、做到哪裡、何時完成。

需求追溯矩陣回答的是：

• 這項功能源自哪個正式需求？
• 誰在什麼版本核准？
• 哪份設計與開發項目負責實現？
• 哪些測試案例證明符合驗收條件？
• 若曾有缺陷，在哪個版本修正與回歸？
• 最後以什麼證據進入發布版本？

因此，RTM 的核心不是表格格式，而是雙向可回查。

一條完整的追溯鏈應包含什麼？

最基本的追溯鏈可以寫成：

原始來源 → 核准需求 → 設計 → 開發 → 測試案例 → 執行結果 → 缺陷／回歸 → 發布證據

其中任何一段斷掉，都可能形成風險。

例如，開發任務找不到核准需求，可能代表團隊做了未授權範圍；測試案例沒有對應驗收條件，可能只是測了畫面，而沒有驗證真正的商業規則。

AI 最有價值的工作：找出四種孤兒

AI 很適合比對大量文件、任務與案例，找出以下四類問題：

1. 孤兒需求：已核准，卻沒有設計、開發或測試。
2. 孤兒開發：功能做了，卻找不到正式需求來源。
3. 孤兒測試：測了很多，但無法說明在驗哪項需求。
4. 孤兒缺陷：問題修了，卻不知道影響哪項需求與哪些回歸範圍。

這些孤兒項目比單純的完成百分比更能揭露上線風險。

文字相似，不等於正式對應

使用 AI 建立追溯矩陣時，最常見的錯誤是把名稱相似當成同一件事。

「權限到期」可能指到期前提醒、到期自動停權，或到期後禁止登入。即使句子看起來相似，驗收條件可能完全不同。

因此，每條 AI 建議的關聯都應標示為直接證據、間接證據、文字相似候選或無法確認。候選關聯必須由人工核對後，才能成為正式矩陣。

測試案例存在，不代表需求已驗證通過

需求覆蓋至少要檢查三件事：

1. 有沒有對應的測試案例？
2. 測試是否真的執行？
3. 執行證據是否屬於目前版本？

如果案例建立了但沒有執行，不能算通過；如果測試在需求變更前完成，也不能直接沿用。

需求變更時，矩陣應告訴你要重做什麼

好的 RTM 不只用來驗收，也能支援變更影響分析。

當一項需求從「臨時權限最多 30 天」改成「最多 7 天」時，矩陣應立即指出：欄位驗證、後端規則、提示文字、既有資料、邊界測試、排程與操作文件都可能需要更新。

這比只改一張任務卡更能避免漏項。

最後不要只報一個完成率

「完成 95%」看起來簡潔，卻可能把關鍵風險藏起來。

更可信的摘要應同時呈現：已核准需求、已實作、已執行、通過、失敗、阻塞、未執行、證據可能失效與待決策。

主管需要的不是漂亮百分比，而是知道還缺什麼、誰能決定，以及不處理會影響什麼。

結語

需求追溯矩陣不是為了增加文件負擔，而是讓團隊在發生爭議時，可以快速回到共同證據。

AI 可以加速比對與找缺口；但核准、驗收與風險接受，仍必須由有權限的人完成。

如果一項功能無法回答「為什麼做、怎麼做、如何證明」，它就還沒有真正進入可控狀態。

逐步實作教學

第 1 步：先定義追溯範圍

確認本次要追溯的產品、版本、模組與日期，不要把歷史所有需求一次混在同一張表。

第 2 步：蒐集原始來源

保留 Email、會議紀錄、正式需求書、變更單、設計稿、任務卡、測試報告與驗收紀錄的來源名稱、版本、日期與連結。

第 3 步：為需求建立唯一編號

每項需求使用穩定 ID，例如 REQ-LOGIN-001。標題可以調整，ID 不應因措辭變更而重編。

第 4 步：拆成可驗收的原子需求

一句需求只表達一個可驗證結果。將「查詢、修改、匯出並寄信」拆成不同需求或明確子項。

第 5 步：記錄版本與狀態

至少區分草案、待確認、已核准、已取代、已取消與已上線。舊版本不能直接刪除。

第 6 步：建立需求到設計的對應

記錄每項需求由哪份流程、畫面、資料欄位、API 或權限設計實現；沒有設計證據就標記缺口。

第 7 步：建立需求到開發項目的對應

連結任務卡、分支、版本或交付物。禁止只靠任務名稱猜測對應關係。

第 8 步：建立驗收條件

每項需求至少有一個正常條件；必要時加入邊界、錯誤、權限、資料與復原條件。

第 9 步：連結測試案例與結果

記錄測試案例 ID、執行版本、日期、結果與證據。只建立案例但尚未執行，不能算已驗證通過。

第 10 步：連結缺陷與回歸測試

缺陷應連回受影響需求與測試案例。修正後必須有對應版本和回歸結果。

第 11 步：處理變更與取代關係

新需求若取代舊需求，要記錄變更原因、核准人、生效版本、受影響設計及需重測項目。

第 12 步：找出四種孤兒

• 孤兒需求：沒有設計、開發或測試
• 孤兒開發：找不到核准需求
• 孤兒測試：沒有對應需求或驗收條件
• 孤兒缺陷：修正了問題，卻不知道影響哪項需求

第 13 步：檢查證據是否仍有效

需求、程式或資料規則變更後，舊測試可能失效。必須核對證據使用的版本與環境。

第 14 步：產生上線覆蓋摘要

呈現已核准需求總數、已實作、已測試、通過、失敗、阻塞、未執行與待決策，而不是只給一個「完成率」。

第 15 步：設定維護責任

規定誰建立需求 ID、誰維護連結、何時更新矩陣，以及哪些變更會觸發重新驗證。

完整提示詞與輸入格式

可替換欄位

• [專案／產品名稱]
• [本次版本]
• [需求來源資料]
• [設計與開發資料]
• [測試與缺陷資料]
• [變更與決議資料]
• [狀態定義]
• [核准規則]
• [資料隱私限制]
• [輸出語氣]

完整提示詞

你是一位「需求追溯與驗收證據分析員」。請協助我把需求、設計、開發、測試、缺陷、變更決議與上線證據整理成可回查的需求追溯矩陣。你不能替任何人核准需求、宣告完成或接受風險。

【專案／產品名稱】
[專案／產品名稱]

【本次版本】
[本次版本]

【狀態定義】
[狀態定義]

【核准規則】
[核准規則]

【需求來源資料】
[需求來源資料]

【設計與開發資料】
[設計與開發資料]

【測試與缺陷資料】
[測試與缺陷資料]

【變更與決議資料】
[變更與決議資料]

【資料隱私限制】
[資料隱私限制]

【任務】
1. 保留每項資料的來源、版本、日期、作者／角色與連結。
2. 將需求拆成單一、可驗收的原子項目，建立候選唯一 ID。
3. 區分草案、待確認、已核准、已取代、已取消與已上線需求。
4. 為每項需求建立：原始來源→核准需求→設計→開發→測試→缺陷／回歸→發布證據的關聯。
5. 每一條關聯標示直接證據、間接證據、文字相似候選或無法確認。
6. 找出孤兒需求、孤兒開發、孤兒測試與孤兒缺陷。
7. 檢查每項驗收條件是否有測試案例、執行結果與有效版本證據。
8. 檢查需求變更後，哪些設計、程式、測試與文件需要更新或重跑。
9. 區分已建立測試、已執行、通過、失敗、阻塞與未執行。
10. 產生上線覆蓋摘要、缺口優先順序與人工確認清單。

【限制】
1. 不得因文字相似就宣告正式對應；只能列為候選並說明依據。
2. 會議中提及、原則同意或無人反對，不等於正式核准。
3. 任務標記完成，不等於需求已驗收。
4. 建立測試案例，不等於測試已執行或通過。
5. 缺陷標記已修正，不等於回歸測試已完成。
6. 不得自行新增需求、核准人、測試結果、版本或發布狀態。
7. 已取代與已取消需求不得直接刪除，須保留原因與生效版本。
8. 若證據版本早於最後一次需求或程式變更，標記為可能失效。
9. 涉及個資、客戶資料、帳密、內部連結時，依[資料隱私限制]遮罩。
10. 使用繁體中文，語氣為[輸出語氣]。

【輸出格式】
1. 一分鐘主管摘要：核准需求數、完整追溯數、主要缺口與待決策事項。
2. 需求主清單：需求 ID｜標題｜版本｜狀態｜來源｜核准證據｜驗收條件。
3. 追溯矩陣：需求 ID｜設計｜開發｜測試案例｜結果｜缺陷／回歸｜發布證據｜信心。
4. 孤兒清單：類型｜項目｜缺少關聯｜影響｜建議確認人。
5. 覆蓋缺口：需求／條件｜目前證據｜缺口｜風險｜最小補救行動。
6. 變更影響表：變更｜舊版｜新版｜受影響項目｜需重測｜生效條件。
7. 上線覆蓋摘要：已核准／已實作／已執行／通過／失敗／阻塞／未執行。
8. 必須人工確認事項。
9. 維護規則：負責角色、更新時機、重新驗證觸發條件。