# 日報服務——需求書（現況＋新增需求）

> 文件性質：既有系統現況說明＋業務端提出的新增需求，尚未經過技術端評估與拆解。
> 用途：作為 Day 17～Day 23 系列文章的共用案例素材，示範 ChatGPT／Codex 如何協助任務契約撰寫、大型重構拆解、CI／測試維運、遺留程式碼考古、除錯、文件補齊與安全品質把關。
> 版本：v0（現況為既有系統實際樣貌，新增需求為業務端原始描述，皆未經技術端確認）

## 一、專案基本資料

- **專案名稱**：日報服務
- **系統性質**：既有系統，已上線約兩年，目前仍在維運中
- **需求提出單位**：業務端（本次為新增需求）
- **提出日期**：2026-08-05
- **狀態**：新增需求待技術端評估，既有系統本身未排入改善計畫

## 二、既有系統現況

日報服務讓客戶針對大數據站台上的資料訂閱「每日報表」，系統會在固定時間（每日上午八點）產生 PDF 檔並以電子郵件寄出，信件內文包含幾項固定數值（例如前一日筆數、成長率）。系統上線後陸續由不同工程師接手維護，目前呈現以下現況：

- **排程與產製邏輯耦合**：報表產製（讀資料、算數值、排版）與寄信邏輯寫在同一個服務類別裡，沒有拆分成獨立步驟，難以單獨測試或替換其中一段。
- **PDF 產出方式陳舊**：使用一套三年前導入、目前已少有更新的 PDF 產生套件，樣式以字串拼接方式組版，若要新增格式或欄位需要改動大量既有程式碼。
- **測試覆蓋率低**：目前僅有少量單元測試，涵蓋部分數值計算邏輯，排程觸發、信件組裝與檔案產生流程沒有自動化測試，仰賴人工於正式環境觀察信件是否寄達。
- **文件與實際行為有落差**：專案說明檔記錄的仍是舊版啟動參數與設定檔位置，目前的排程觸發方式、環境變數與部署方式已經與文件描述不同。
- **已知但未排入處理的問題**：客戶數量成長後，曾出現接近發送時間才開始產生報表、導致部分信件延遲寄出的情形；另外套件更新紀錄中留有一筆尚未確認是否影響本系統的安全性通知，目前未有人處理。

以上現況為技術端內部觀察整理，尚未做過完整盤點，實際範圍與影響需要進一步確認。

## 三、本次新增需求（業務端原始描述）

> 「客戶可透過本公司提供的大數據站台，設定日、週、雙週、月報表服務，除了基本的信件內文有數值相關顯示外，客戶可以設定想要的檔案（PDF、WORD、EXCEL），並且會在每日指定發送時間前一小時開始製作。」

整理成條列：

1. 報表頻率由目前僅支援「每日」，擴增為日、週、雙週、月四種，客戶可自行設定。
2. 信件內文維持數值相關顯示，具體是否為既有數值欄位或需新增欄位，未說明。
3. 客戶可自行選擇產出檔案格式：PDF、WORD、EXCEL，目前系統僅支援 PDF。
4. 報表製作須於「每日指定發送時間前一小時」開始，而非在發送當下才開始產生。

## 四、新增需求對既有系統的初步影響推測（未經技術端確認）

- 排程機制需要從單一「每日固定時間觸發」，改為能依頻率（日、週、雙週、月）與提前量（發送前一小時）計算觸發時機，可能牽動既有排程模組的核心邏輯。
- 新增 WORD、EXCEL 格式，勢必要調整目前與 PDF 產生邏輯緊密耦合的程式結構，否則新格式的程式碼可能重複既有邏輯或難以維護。
- 週、雙週、月報表的數值計算範圍（例如成長率是否改為對比上一週期）尚未定義，可能影響既有數值計算邏輯是否可以直接沿用。
- 現有測試覆蓋率低，若直接在既有程式上疊加新功能，回歸風險難以掌握，可能需要先補足關鍵路徑測試再進行改動。

## 五、目前已知的空白與待確認事項

- 「日、週、雙週、月」是否可以同一客戶同時訂閱多種頻率？或每個客戶僅能選一種？
- 「發送前一小時開始製作」是否為硬性時限？若資料量大導致製作超過一小時，系統該如何處理（延後發送、寄出不完整報表、通知客戶）？
- WORD、EXCEL 格式的內容是否要與 PDF 完全一致，還是允許依格式特性呈現不同版面（例如 EXCEL 提供原始數據表）？
- 既有客戶（目前僅訂閱每日 PDF）在新功能上線後，是否需要自動轉移到新設定畫面，或維持原行為直到客戶主動調整？
- 已知的套件安全性通知是否與本次新增需求有關聯，是否要藉此機會一併處理？
- 現有測試不足與文件過時的技術債，是否包含在本次需求範圍內，或視為獨立的維運任務？

## 六、附註

本文件的「既有系統現況」段落為技術端內部觀察，尚未做過完整程式碼盤點與依賴清查；「新增需求」段落則為業務端原始描述，未經技術端評估可行性與工作量。後續系列文章會示範如何把這份文件轉成可以交給 Codex 執行的任務契約，並依序展開重構拆解、測試補強、遺留程式碼理解、除錯、文件更新與安全品質檢查。