📄 03. 正式需求規格書 (Final PRD)
🎯 使用時機： 內部評估完成後，整理出這份乾淨的「合約級」文件給客戶簽收。 重點原則： 白紙黑字，作為未來驗收與請款的唯一標準。若客戶不滿意，則回到「內部評估」階段重新調整範圍。
一、第一期交付範圍 (Phase 1 Features)
💡 經過評估與預算考量，確定會在本次合約中開發的核心功能。
| 優先順序 | 功能模組 | 使用情境與操作動線 | 預期結果 |
|---|---|---|---|
| 絕對必備 | 會員登入 | 作為一般使用者，點擊按鈕後可使用 Google 帳號授權登入 | 成功登入並跳轉至首頁 |
| 絕對必備 | 報表匯出 | 作為管理員，在後台清單頁面點擊「匯出」 | 成功下載 .csv 格式的訂單資料 |
二、未來擴充計畫 (Phase 2 & Beyond)
💡 客戶於訪談中提出，但因技術限制或預算考量，建議延後至未來階段開發的願望清單。這能確保客戶的聲音被聽見，同時界定本次合約的邊界。
| 預計階段 | 功能模組 | 延後原因與未來規劃 |
|---|---|---|
| 第二期 | AI 聊天機器人 | 需較長工時串接外部 API。建議第一期先求穩（核心功能上線），第二期再求好（導入 AI）。 |
| 評估中 | 精美 PDF 報表匯出 | 優先確保數據營運，第一期以 Excel 匯出為主，未來若有固定版面需求再行開發。 |
三、驗收標準 (Acceptance Criteria) 🛑 極度重要
💡 後續所有階段 DEMO 的調整與最終付款，皆以此標準為最高指導原則。
- 系統穩定性：[例如：所有「第一期交付範圍」的功能皆可順暢走完流程，無導致系統崩潰之嚴重錯誤。]
- 防禦條款：若後續在 DEMO 或測試階段提出與上述「交付範圍」無關之全新功能，將另行啟動追加報價流程，不涵蓋於本次驗收與付款範圍內。
三、客戶應配合提供之資源 (Client Dependencies)
💡 防禦「卡在客戶」的陷阱。
- 需提供之項目與期限：
- [例：品牌 Logo 原始檔與色彩規範 - 於開工後 3 日內提供]
- [例：第三方金流的正式 API Key - 於第二階段開發前提供]
- 防禦條款：若因上述資源提供延宕導致時程延誤，不屬於開發方責任，專案驗收與尾款支付時程將順延。
四、專案時程與里程碑 (Milestones)
| 里程碑階段 | 預計時間 | 產出物與雙方動作 |
|---|---|---|
| 第一站：需求確認與開工 | T+0 | 雙方確認並簽署此規格文件，正式起算工期 |
| 第二站：畫面與動線確認 | T+2 週 | 開發方提供視覺 DEMO，客戶確認無誤後開始寫程式 |
| 第三站：階段性功能確認 | T+5 週 | 第一期核心功能開發完畢，客戶進行初步功能操作 |
| 第四站：上機驗收與正式上線 | T+7 週 | 系統部署至測試網址進行 UAT，驗收通過後正式上線結案 |
文件更新歷程
- [YYYY/MM/DD] - 建立初版並與客戶確認簽收