GOV-004　需求追溯矩陣（RTM）

1. 追溯模型

本專案採四問追溯——任一需求必須能回答：

1. 由哪個服務承作？（Who）
2. 在哪份設計文件被定義？（Where）
3. 由哪支 API 實作？（How）
4. 由哪個測試案例驗證？（Verify）

flowchart LR
  FR["客戶 FR 68 項"] --> SVC["微服務<br/>SAD-002"]
  FR --> DOC["設計文件<br/>SDD-000~007"]
  FR --> API["API 契約<br/>SDD-006"]
  FR --> TC["驗收測試<br/>TRP-001 / TRR-001"]
  SVC --> CODE["程式碼<br/>backend/services"]
  API --> CODE
  TC --> REP["測試報告<br/>TRR-001"]
  CODE --> REP

2. 覆蓋率統計

R0 之 15 項為流程／文件類需求（SYS-2.7 實績證明、SYS-9~9.13 測試流程），
由 TRP-001 與 BRD-001 承作，不產生程式碼，故不列程式覆蓋率分母。

3. 服務 × FR 對照

⚠️ dispute-service 之追溯缺口（2026-10-01 查明，HANDOVER #A-109）：
本矩陣原未列該服務。經查——不是漏列，是需求側本來就沒有對應 FR：
(i) BRD-002 之 FR 編號群中無任何爭議／拒付相關前綴（DEB-3.x 六項全為 DEBIT 卡：
卡片管理／請款／定價／報送／發卡帳務／發卡清算）；
(ii) BRD-001 僅於文字提及「爭議帳款」（R3 批次與功能說明），未賦予 FR 編號；
(iii) SCS-012 §1 早已自行揭露此缺口並建議補 DIS-*。
→ 本列以「0」如實呈現，不捏造歸屬。建議：由 SA 於 BRD-002 補 FR
（如 DIS-1 爭議受理、DIS-2 拒付表示、DIS-3 調單／仲裁）並回填 SCS-012 §1 與本矩陣。

4. POC × 服務對照

5. 交付批次 × 服務

6. 檢核結果

⚠️ 「服務數 17」與「有 FR 之服務數 16」之差額即 dispute-service——
這是四問追溯之第 1 問（由哪個服務承作）的缺口：該服務有契約、有實作、有實測，
但沒有可追溯的需求編號。不影響其功能，但影響可追溯性（GOV-005 之要求）。
建議列為需求側待辦（見 §3 註）。

7. 需求落地狀態評定（對映 Redmine）

需求議題之落地狀態由 ops/redmine/req_assess.py 依可查證事實評定（規則見 GOV-008 §16）：
FR 具名 API 以「契約＋實作＋測試」三重證據判定 Closed；橫切類以平台模組落地度判定；
NFR 一律 In Progress（設計已備 ≠ 已驗證）；POC 一律 In Progress（待逐情境 DEMO）；
GAPS 已揭露缺口一律 In Progress——即使三重證據齊備（CR-050 裁定，反假綠）。

評定結果（2026-10-17，CR-050 裁定後重跑）：Closed 51／In Progress 79／Feedback 15（合計 145）。
★ 原揭露 2 筆「契約 ↔ 追溯對映」漂移已依 CR-050 裁定完成對映誠實化：
ACQ-4.3（RFP FR §4.3 商店對帳單未承作——merchant-settlements 為 ACQ-4.2 請款語意，不可混用）、
ISS-2.4（改對映實際已交付之帳戶級端點；卡片級查詢待另立 CR）。兩筆狀態維持 In Progress（真實缺口）。
★ 評定為自動推導，細部逐案驗收測試之對應關係仍待 TRP-001 逐項核對——不宣稱已完成驗收。

8. 修訂記錄