CR #201 » GOV-005_To-Be-Scope與交付範疇.md
GOV-005 To-Be Scope 與交付範疇
| 項目 | 內容 |
|---|---|
| 文件編號 | GOV-005 |
| 版本 | 1.1 |
| 狀態 | 已核定 |
| 撰寫者 | SA / Tech Lead |
| 審查者 | BA / PM |
| 對應需求 | 客戶 RFP 之 FR 68 項、NFR 874 項（60 小節）、POC 17 項 |
| 關聯文件 |
BRD-001～BRD-004、GOV-004、SCS-000
|
0. 為何需要本文件（問題陳述）
2026-09-19 BEAM PMO 指出：現有文件只有架構層級（Conceptual Design），
沒有服務／程式層級的 Coding Spec，等於邊做邊想，追溯性會斷裂。
經盤點確認，缺口不在「需求端」也不在「程式端」，而在中間的設計規格層：
| 層級 | 文件 | 狀態 |
|---|---|---|
| 需求 |
BRD-002（FR 68）、BRD-003（NFR 60 小節）、BRD-004（POC 17） |
✅ 完整 |
| 追溯模型 |
GOV-004（服務×FR、POC×服務） |
✅ 完整 |
| 架構設計 |
SAD-001～006、SDD-000～007
|
✅ 完整 |
| 服務程式設計規格 | SCS（Service Coding Spec） |
❌ 完全空白 |
| 程式碼 | backend/services/* |
✅ 部分（3 服務） |
| 測試 |
TRP-001、TRR-001
|
✅ 部分 |
結論：BEAM PMO 的批評成立。 本文件據此調整交付方法。
1. 什麼是 To-Be Scope
To-Be Scope ＝ 我方對客戶 Proposal（RFP）之正式回覆內容，也就是「我們承諾要建置的系統樣貌」。
它不是願景，而是可追溯、可驗收的承諾清單，包含兩大部分：
| 部分 | 內容 | 來源 |
|---|---|---|
| 功能性（Functional） | 系統應提供的業務能力（發卡、授權、入帳、帳單、分期、點數、爭議、清算、報表…） | 客戶 FR 68 項，我方於建議書逐項回覆 |
| 非功能性（Non-Functional） | 效能、容量、可用性、資安、個資、維運、監控、備援、批次時效… | 客戶 NFR 874 項（60 小節），我方於建議書附錄 B 逐項回應 |
⚠️ To-Be Scope 的邊界由「我方回覆」界定，不是由客戶 RFP 全文界定。
客戶要求若我方回覆為「部分符合」或「替代方案」，則以我方回覆之範圍為準，
並於BRD-002/BRD-003註記差異，避免驗收時被以 RFP 全文究責。
2. 追溯模型（五層，補足缺口）
任一需求必須能回答五問；缺任一問視為追溯斷裂：
| # | 問題 | 回答文件 | 狀態 |
|---|---|---|---|
| 1 | 客戶要求什麼？ |
BRD-002/BRD-003（對應建議書章節） |
✅ |
| 2 | 由哪個服務承作？ |
GOV-004 §3、SAD-002
|
✅ |
| 3 | 這支程式如何設計？ | SCS-00x（本文件新增） |
❌→施工中 |
| 4 | 由哪支程式／類別實作？ |
SCS-00x §「程式結構」 + backend/
|
⚠️ 待 SCS 補齊 |
| 5 | 如何驗證？ |
TRP-001（計畫）、TRR-001（結果） |
✅ 部分 |
flowchart LR
RFP["客戶 RFP<br/>FR 68 / NFR 874"] --> PROP["我方建議書<br/>proposal_v2（To-Be Scope 源頭）"]
PROP --> BRD["BRD-002/003<br/>需求追蹤"]
BRD --> SAD["SAD/SDD<br/>架構設計"]
SAD --> SCS["SCS-00x<br/>服務程式設計規格"]
SCS --> CODE["backend/services<br/>程式碼"]
CODE --> TRR["TRR-001<br/>測試結果"]
BRD --> GOV4["GOV-004<br/>追溯矩陣"]
3. To-Be Scope 清單（功能性）
⛔ 本節之「狀態」欄已於 2026-09-19 廢止
本節建立於 2026-09-19 11:58，其狀態欄（🟢／🟡／⚪）自建立後即未再更新，已全面過時
（例如仍記載party-service「未開發」，實則當日 14:27 已完成）。任務與進度之追蹤，一律以
cardcore/HANDOVER.md之
「§📊 任務追蹤總表（Task Tracker）」為單一真實來源。本節**僅保留「服務 × FR 承作關係」**作為範疇界定之用；狀態請勿引用本節。
保留而非刪除之原因：本節記錄了 11:58 當下的認知，是「文件分層調整」之歷史證據。
依 GOV-004 §3 之服務×FR 對照，並標註目前實作狀態（2026-09-19 11:58 快照，已過時）：
| 服務 | 承作 FR | 狀態 | SCS |
|---|---|---|---|
authorization-service |
AUT-1.1、AUT-1.2、AUT-1.3 | 🟡 部分（授權主線完成，13 項檢核僅 6 項） | SCS-001 |
card-service |
ISS-2.2、DEB-3.1 | 🟡 部分（狀態查詢、生命週期轉換完成；發卡／快發快綁未做） | SCS-003 |
limit-service |
ISS-2.4 | 🟢 大部分（佔用／釋放／調整申請完成） | SCS-002 |
party-service |
ISS-2.1 | ⚪ 未開發 | 待編 |
product-service |
COM-6.1、COM-6.2 | ⚪ 未開發 | 待編 |
posting-service |
ACQ-4.5、ISS-2.3、ISS-2.12、DEB-3.2、DEB-3.5 | ⚪ 未開發 | 待編 |
payment-service |
ISS-2.6、ISS-2.9 | ⚪ 未開發 | 待編 |
statement-service |
ISS-2.8 | ⚪ 未開發 | 待編 |
pricing-service |
ISS-2.5、DEB-3.3 | ⚪ 未開發 | 待編 |
installment-service |
ISS-2.7 | ⚪ 未開發 | 待編 |
rewards-service |
RWD-5.1～5.3 | ⚪ 未開發 | 待編 |
notification-service |
ISS-2.10 | ⚪ 未開發 | 待編 |
report-service |
SYS-1、ACQ-4.4、ISS-2.11、DEB-3.4 | ⚪ 未開發 | 待編 |
migration-service |
SYS-2.8、SYS-3 | ⚪ 未開發 | 待編 |
clearing-service |
ACQ-4.6、ISS-2.13、DEB-3.6 | ⚪ 未開發 | 待編 |
dispute-service |
（見 GOV-004） | ⚪ 未開發 | 待編 |
merchant-service |
ACQ-4.1～4.3 | ⚪ 未開發 | 待編 |
platform/common |
SYS-2.1～2.6、2.9～2.12、SYS-5、SYS-6、SYS-9.14～9.15 | 🟡 部分（值物件、例外、事件、批次、Saga 完成） | 待編 |
platform/gateway |
SYS-4、SYS-7、SYS-8 | ⚪ 未開發（骨架） | 待編 |
cardcore-web |
授權作業台、額度調整申請 | 🟡 部分（2 頁） | SDD-007 |
圖例：🟢 大部分完成｜🟡 部分完成｜⚪ 未開發
4. To-Be Scope（非功能性）
NFR 以小節層級（60 小節）追蹤，歸屬與驗證方式詳見 BRD-003。
與程式直接相關者，須於 SCS 中說明「如何滿足」：
| NFR 主題 | 涉及設計 | 驗證方式 | 狀態 |
|---|---|---|---|
| 交易一致性 |
SDD-004（Saga／Outbox） |
TRR-001 閉環測試 |
🟡 部分（Saga 引擎完成，未上線驗證） |
| 個資保護 |
SAD-005（遮蔽／加密） |
單元測試 + 資料抽檢 | 🟢 已完成（common-security） |
| 可觀測性 | CSP-004 |
日誌／追蹤碼 | 🟡 部分（追蹤碼完成，監控未接） |
| 錯誤處理 |
CSP-003（錯誤碼） |
契約測試 | 🟢 已完成 |
| 批次時效 | common-batch |
批次測試 | 🟡 部分（框架完成，排程僅臨時額度到期） |
| 效能／容量 | 未設計 | 待壓測 | ⚪ 未處理 |
5. 新的開發節奏（據此調整，不再邊做邊想）
自 2026-09-19 起，任何服務／功能開發必須依序產出：
① 確認需求（BRD-002/003 之 FR/NFR 編號）
② 撰寫/更新 SCS-00x（服務程式設計規格） ← 新増，必備
③ 依 SCS 實作程式
④ 撰寫/更新測試（TRP-001）
⑤ 執行測試並更新 TRR-001
⑥ 更新追溯矩陣（GOV-004）
無 SCS 不寫程式——這是 Coding Gate 的一環（納入 GOV-003）。
6. SCS（Service Coding Spec）文件規範
SCS-00x 為服務／程式層級設計規格，命名 SCS-<NNN>_<服務名>服務程式設計規格.md，
存放 docs/07-scs/（新增目錄）。
必備章節：
| § | 章節 | 內容 |
|---|---|---|
| 1 | 對應需求 | FR/NFR 編號、建議書章節 |
| 2 | 服務職責與邊界 | 承作什麼、不做什麼（bounded context） |
| 3 | 領域模型 | 聚合、值物件、狀態機（含轉換表） |
| 4 | 程式結構 | 套件／類別清單與職責（對應實際檔案） |
| 5 | 資料模型 | 表、欄位、約束（實測值） |
| 6 | API 設計 | 端點、請求／回應、錯誤碼 |
| 7 | 關鍵邏輯 | 演算法、檢核順序、交易邊界 |
| 8 | 外部依賴與降級 | 呼叫誰、失敗怎麼辦（Stand-in） |
| 9 | 測試案例 | 對應 TRP-001 之編號 |
| 10 | 已知限制 | 誠實揭露未實作範圍 |
7. 已完成 vs 待補（追溯補正計畫）
本節已於 2026-09-19 更新完畢——原表所列「待編」項目皆已完成。
| 項 | 說明 | 狀態 |
|---|---|---|
| 盤點缺口 | 確認缺 SCS 層 | ✅ 完成 |
| 定義 To-Be Scope | 本文件 | ✅ 完成 |
SCS-000（總覽與模板） |
定義 SCS 寫法 | ✅ 已完成 |
SCS-001～003
|
已開發服務補規格（授權／額度／卡片） | ✅ 已完成（程式先行、規格後補，已標示） |
SCS-004～021
|
其餘領域與跨域服務 | ✅ 已完成（22 份全數開齊，2026-09-19 11:59–19:37） |
GOV-003 納入 SCS 為 Coding Gate |
流程調整 | ✅ 已完成（條件 9「無 SCS 不寫程式」） |
GOV-004 加入程式檔案層追溯 |
追溯補正 | ✅ 已完成（追加程式層說明） |
後續追蹤：範疇之執行進度請見 cardcore/HANDOVER.md →「§📊 任務追蹤總表」。
本文件自此只管範疇界定與追溯模型，不再承載進度資訊。
8. 修訂記錄
| 版本 | 說明 |
|---|---|
| 1.0 | 初版：依 BEAM PMO 2026-09-19 之指摘，盤點追溯斷裂並調整開發方法 |
| 1.1 | 2026-09-19：①**§3 狀態欄廢止**——該欄自 11:58 建立後未再更新、已全面過時，進度追蹤改由 HANDOVER.md「任務追蹤總表」承擔（避免兩處各說各話）；②**§7 更新**——原「待編」項目皆已完成（SCS 22 份全數開齊、Coding Gate 已納入、GOV-004 已補程式層）；③檔頭狀態由「草案」改為「已核定」 |