# GOV-004 需求追溯矩陣（RTM）
| 項目 | 內容 |
|---|---|
| 文件編號 | GOV-004 |
| 版本 | 1.3 |
| 狀態 | 已核定 |
| 撰寫者 | BA |
| 審查者 | SA / QA Lead |
| 對應需求 | 客戶 FR 68 項、NFR、POC 17 項 |
---
## 1. 追溯模型
本專案採**四問追溯**——任一需求必須能回答：
1. **由哪個服務承作？**（Who）
2. **在哪份設計文件被定義？**（Where）
3. **由哪支 API 實作？**（How）
4. **由哪個測試案例驗證？**（Verify）
```mermaid
flowchart LR
FR["客戶 FR 68 項"] --> SVC["微服務
SAD-002"]
FR --> DOC["設計文件
SDD-000~007"]
FR --> API["API 契約
SDD-006"]
FR --> TC["驗收測試
TRP-001 / TRR-001"]
SVC --> CODE["程式碼
backend/services"]
API --> CODE
TC --> REP["測試報告
TRR-001"]
CODE --> REP
```
## 2. 覆蓋率統計
| 指標 | 分子 | 分母 | 覆蓋率 |
|---|---:|---:|---:|
| FR 有承作服務且有驗收測試 | 52 | 68 | 76.5% |
| FR 有程式承作（排除 R0 文件類） | 53 | 68 | 77.9% |
| POC 情境有對應 FR 與測試 | 17 | 17 | 100.0% |
> **R0 之 15 項**為流程／文件類需求（SYS-2.7 實績證明、SYS-9~9.13 測試流程），
> 由 `TRP-001` 與 `BRD-001` 承作，不產生程式碼，故不列程式覆蓋率分母。
## 3. 服務 × FR 對照
| 服務 | 承作 FR 數 | FR 清單 |
|---|---:|---|
| `—` | 15 | SYS-2.7, SYS-9, SYS-9.1, SYS-9.2, SYS-9.3, SYS-9.4, SYS-9.5, SYS-9.6, SYS-9.7, SYS-9.8, SYS-9.9, SYS-9.10, SYS-9.11, SYS-9.12, SYS-9.13 |
| `platform/common` | 14 | SYS-2.1, SYS-2.2, SYS-2.3, SYS-2.4, SYS-2.5, SYS-2.6, SYS-2.9, SYS-2.10, SYS-2.11, SYS-2.12, SYS-5, SYS-6, SYS-9.14, SYS-9.15 |
| `posting-service` | 5 | ACQ-4.5, ISS-2.3, ISS-2.12, DEB-3.2, DEB-3.5 |
| `report-service` | 4 | SYS-1, ACQ-4.4, ISS-2.11, DEB-3.4 |
| `authorization-service` | 3 | AUT-1.1, AUT-1.2, AUT-1.3 |
| `clearing-service` | 3 | ACQ-4.6, ISS-2.13, DEB-3.6 |
| `merchant-service` | 3 | ACQ-4.1, ACQ-4.2, ACQ-4.3 |
| `platform/gateway` | 3 | SYS-4, SYS-7, SYS-8 |
| `rewards-service` | 3 | RWD-5.1, RWD-5.2, RWD-5.3 |
| `card-service` | 2 | ISS-2.2, DEB-3.1 |
| `migration-service` | 2 | SYS-2.8, SYS-3 |
| `payment-service` | 2 | ISS-2.6, ISS-2.9 |
| `pricing-service` | 2 | ISS-2.5, DEB-3.3 |
| `product-service` | 2 | COM-6.1, COM-6.2 |
| `installment-service` | 1 | ISS-2.7 |
| `limit-service` | 1 | ISS-2.4 |
| `notification-service` | 1 | ISS-2.10 |
| `party-service` | 1 | ISS-2.1 |
| `statement-service` | 1 | ISS-2.8 |
| **`dispute-service`** | **0** | **（無 FR 編號——⚠️ 需求側缺口，見 §6 檢核結果）** |
> ⚠️ **`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 × 服務對照
| POC | 項目 | 對應 FR | 涉及服務 |
|---:|---|---|---|
| 1 | 利息 & 違約金計算及查詢 | ISS-2.5 | `pricing-service` |
| 2 | 點數 | RWD-5.1~5.3 | `rewards-service` |
| 3 | 收單 | ACQ-4.1~4.6 | `merchant-service`、`report-service`、`posting-service`、`clearing-service` |
| 4 | ONLINE REDEEM | RWD-5.2 | `rewards-service` |
| 5 | 分期 | ISS-2.7 | `installment-service` |
| 6 | 信用卡快發快綁 | ISS-2.2 | `card-service` |
| 7 | 消費通知 | ISS-2.10 | `notification-service` |
| 8 | 專用額度 | ISS-2.4 | `limit-service` |
| 9 | 錯帳沖正、重覆入帳防範 | ISS-2.3 / ISS-2.12 | `posting-service` |
| 10 | 市區停車 | ISS-2.1 | `party-service` |
| 11 | 繳款即時恢復額度 | ISS-2.6 | `payment-service` |
| 12 | 系統功能 | SYS-2.x / SYS-4 / SYS-5 | `platform/common`、`migration-service`、`platform/gateway` |
| 13 | 收單授權分流 | AUT-1.2 / AUT-1.3 | `authorization-service` |
| 14 | 授權額度更新 | SYS-2.1 / ISS-2.4 | `platform/common`、`limit-service` |
| 15 | 信用卡國際組織 compliance | SYS-5 / AUT-1.3 | `platform/common`、`authorization-service` |
| 16 | 帳單批次執行 | ISS-2.8 | `statement-service` |
| 17 | 瞬間大量交易 | SYS-2.11 / AUT-1.1 | `platform/common`、`authorization-service` |
## 5. 交付批次 × 服務
| 批次 | 服務 | 說明 |
|---|---|---|
| R1 | authorization / card / party / product / limit / posting / payment / platform | 授權—帳務主線（垂直切片，可端到端驗證） |
| R2 | statement / pricing / installment / rewards / notification / report / migration | 帳單—分期—點數—通知 |
| R3 | clearing / dispute / merchant | 清算—爭議—收單 |
---
## 6. 檢核結果
| 檢核項 | 標準 | 結果 |
|---|---|---|
| FR 全數納入矩陣 | 68 | 68 ✅ |
| 四問可回答（排除 R0） | 53 | 53 ✅ |
| POC 全數納入 | 17 | 17 ✅ |
| 服務名稱與 SDD-006 一致 | 100% | 由同源腳本保證 ✅ |
| **17 個領域服務皆納入矩陣** | 17 | **16 ✅ ＋ 1 ⚠️**（`dispute-service` **有服務、無 FR**——**需求側缺口**，見 §3 註） |
> ⚠️ **「服務數 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. 修訂記錄
| 版本 | 日期 | 修訂者 | 說明 |
|---|---|---|---|
| **1.3** | 2026-10-17 | WorkBuddy AI | BEAM PMO 裁定：`GAPS` 缺口改指向**`CR-051`**（商店對帳單 S-1～S-7）／**`CR-052`**（卡片級 C-1～C-6）；`GOV-006 2.4.4` 定性更正為「RFP 已列（FR §2.4(1)）、語意待凍結」 |
| 1.2 | 2026-10-17 | WorkBuddy AI | **`CR-050` 裁定落實**：`ACQ-4.3` 對映誠實化（商店對帳單未承作，待另立 CR）、`ISS-2.4` 改對映帳戶級端點＋卡片級缺口註記；評定規則新增 `GAPS` 缺口機制（§7）。★ 本檔改由產生器**完整**產出——原手工加註之 §3 `dispute-service` 列與註記、§6 檢核列、修訂記錄、評定節已**全部移植入產生器**，重跑不再遺失 |
| 1.1 | 2026-10-01 | WorkBuddy AI | §3 補 `dispute-service` 列（`HANDOVER #A-109`、`TRR-001 U-01`）。★ 查明「未列」之原因為**需求側缺口，非漏列**：`BRD-002` 無任何爭議／拒付之 FR 編號、`BRD-001` 僅文字提及、`SCS-012 §1` 早已自行揭露。**→ 以「0」如實呈現，不捏造歸屬**；併於 §6 新增「17 服務皆納入矩陣」之檢核列 |
| 1.0 | — | BA | 初版 |