*本文案例資料皆為示意，非真實專案資訊。

在高合規要求的專案裡，工程師大概都遇過這幾種情況：
壹、 驗收前一週，才有人說：「欸，這條需求當初不是這樣講吧？」
貳、 法遵突然跳出來問：「這個流程有對到哪一條規範？」
參、 測試報告寫得很厚，但大家仍然吵不完：「到底有沒有照需求做？」

身為 PM，我很早就發現：
如果沒有一份「可以往回追，也可以往前看」的文件，
PM、工程師、QA、法遵很難真正站在同一頁。

這篇想分享的是，我在專案裡常用的一個工具：
需求追溯矩陣（Requirements Traceability Matrix, RTM），
以及它怎麼在實務上幫忙 串起需求、設計、程式碼、測試與合規。

壹、 需求追溯矩陣是什麼？為什麼技術人也該在意？
簡單講，需求追溯矩陣是一張表，用來回答兩個問題：
一、 這條需求，從哪裡來、為什麼存在？
二、 為了滿足這條需求，系統做了什麼設計、寫了哪段程式、跑了哪些測試？
在高合規專案裡，這兩個問題再多一個維度：
(一) 這件事，跟哪一條法規／政策／SLA 有關？
(二) 對工程師來說，它不是 PM 的作業，而是一張：

1. 找需求來源
2. 找相關設計文件
3. 找相關 Test Case
4. 面對 Incident／Audit 時自保
   的快速索引表。

貳、 我在專案裡怎麼設計這張表？
以下是簡化後的欄位示意（內容為虛構案例）：
需求ID : REQ-101
需求描述 : 使用者跨行轉帳時需顯示「今日剩餘限額」
提出單位 : 業務部
合規依據 : 金管會電子支付規範 §15
系統設計ID : SYS-101
詳細設計ID : DES-201
模組ID : MOD-TRX-01
單元測試ID : UT-301
整合測試ID : IT-401
系統測試ID : ST-501

實務上，我會設計類似這幾欄：
一、 需求 ID / 需求描述: 基本款，讓大家有共同編號可以對話。
(一) 提出單位: 例：業務部、資訊部、法遵部、客服…
(二) 好處是日後有爭議時，不會變成「印象中好像是誰說的」。
二、 合規依據
(一) 例：

1. 金管會電子支付規範 §15
2. 金融消費者保護法 §7
3. ISO 27001 A-14
4. 內部資安政策 A-12
   這一欄讓大家知道：「這不是我想做，是不得不做。」
   三、 系統設計 ID（SYS-XXX）
   (一)、 對應到高階架構／系統設計文件。
   (二)、 架構師、SA 要 review 時，很方便 trace。
   四、 詳細設計 ID（DES-XXX）
   (一)、 對應到詳細設計文件或設計段落。
   (二) 日後要調整邏輯，可以直接找到設計來源。
   五、 模組 ID（MOD-XXX）
   (一)、 例：
5. MOD-TRX-01（轉帳流程）
6. MOD-PERF-02（效能優化）
7. MOD-LOG-03（Log 留存）
   方便工程師知道：「我現在改的這個模組，牽到哪些需求與條文。」
   六、 測試 ID（UT／IT／ST）
   (一)、 每一個 Test Case 都對應一條或多條需求。
   (二)、 驗收時就不會出現「測很多，但不知道測了什麼」的情況。

參、 工程師 & QA 在日常怎麼用？
一、 開發階段：找得到「為什麼要做」
當工程師拿到需求時，除了 user story / 需求文件，
可以在矩陣裡看到：
(一)、 這條需求的提出單位,
(二)、 背後的合規依據,
(三)、 跟自己負責的模組 ID
很多討論會從：「為什麼要這麼麻煩？」
變成：「如果法規要求是這樣，我們有沒有更好的實作方式？」
二、 測試階段：Test Case 不再「憑感覺」
(一)、 QA 在寫 Test Case 時，會反過來用矩陣：
(二)、 一條需求至少要有對應的測試 ID
驗收前可以快速檢查：
(一)、 哪些需求還沒有測？
(二)、 哪些是合規相關需求，需要特別加強？
三、 Incident／Audit：快速還原脈絡
遇到事件或稽核時，技術同仁最怕的就是：
(一)、 找不到當初決策的依據
(二)、 找不到設計／測試的證據
這時候矩陣可以直接回答：
(一)、 「哪條需求導致了這個行為？」
(二)、 「當初是誰提、基於哪條規範？」
(三)、 「當時怎麼設計、怎麼測試過？」
對技術人來說，這其實也是一種 風險管理與自保。

肆. 導入這張表時，我踩過的幾個坑
一、 一開始欄位太多，沒人想填
一開始我直接開滿一大堆欄位，結果：
(一)、 PM 覺得工作量爆炸
(二)、 工程師覺得這只是「PM 的 Excel」
(三)、 QA 也不太理
後來調整的做法是：先從最核心的欄位開始：
(一)、 需求 ID／需求描述
(二)、 提出單位
(三)、 合規依據／來源
(四)、 測試 ID（先從系統測試或 UAT 開始）
等大家習慣這個思維，再慢慢加上系統設計、模組等資訊。
二、 沒說好「誰負責維護」，最後變孤兒檔案
一開始大家都說好要用，但過一陣子就沒有人更新。
後來的作法：
(一)、 明確約定：
(1)、 需求新增／變更 → 由 PM 更新需求與合規欄位
(2)、 設計階段 → 由 SA／系統設計負責人補上設計 ID
(3)、 開發階段 → 主要開發者補上模組 ID
(4)、 測試階段 → QA 補上各測試 ID
(5)、 把這件事寫進專案流程（例如：沒有對應 ID 的需求，不能進 UAT）
三、 只放在檔案夾裡，沒嵌進日常會議
如果這張表只是躺在某個共享資料夾，大概沒人會打開。
我現在的做法是：
(一)、 需求訪談會 → 開會就直接共享這張表
(二)、 設計 Review → 用它當 agenda 的主軸
(三)、 測試規劃會 → 根據矩陣逐條確認 coverage
(四)、 驗收會／稽核 → 直接拿它當主畫面
讓大家習慣：有問題先看表，再開始討論。

伍、 給想嘗試的 PM／工程師一些小建議
如果你也在高合規環境（例如金融／政府／醫療等）做專案，可以考慮：
一、 先從一兩個專案試行，不用一次全公司 rollout。
二、 一開始欄位不要太貪心，先解決「最常吵的幾種問題」。
三、 讓工程師、QA 也參與欄位設計，而不是單向要求填資料。
在專案結束時，回頭檢討：
一、 這張表有沒有真的幫上忙？
二、 哪些欄位用不到，可以砍掉？
三、 哪些資訊值得變成組織級模板？

陸、 結語
需求追溯矩陣，對我來說不只是 PM 的文件，而是一種 mindset：
一、 把需求「掛上名字」與「掛上條文」
二、 讓設計與程式碼有脈絡可循
三、 讓測試與驗收可以說清楚、講明白
四、 在金融／政府這種高合規的場域裡，
它幫我少掉不少「印象流」的爭執，也讓工程師在面對變更與稽核時更有底氣。

如果你們團隊也有類似的做法（或是正處在「需求很亂、驗收很痛」的階段），
也歡迎在留言分享你們的經驗，我很樂意一起交流、互相成長 🙌