🏗️ 系統分析規格書 (System Analysis Document)

🎯 文件屬性：純系統分析文件 (SA) 專案簽約後，由**「系統分析師 (SA)」根據 PRD 獨立產出。負責將業務需求梳理為系統面的「資料實體」、「服務邏輯」與「角色權限」。 ⚠️ 注意：此文件完全不涉及**任何技術選型 (Next.js/DB)、資料庫型態 (Schema) 或 API 路由。技術實作細節將交由工程團隊在下一階段的「系統開發文件 (SD)」中決定。

---

一、需求來源與依據 (References)

💡 紀錄此系統分析所依據的源頭文件與設計。

• 依據之 PRD：[請填寫 PRD 連結]
• Figma 畫面動線設計：[請填寫 Figma 連結]

二、系統資料實體需求 (Data Entities)

💡 盤點系統需要儲存哪些「大項目」，以釐清業務範疇。具體欄位與結構由工程師後續設計。

• 會員資料 (User)：需要儲存使用者的基本登入資訊、註冊時間與狀態。
• 訂單資料 (Order)：需要紀錄購買的商品清單、對應的買家，以及當前的付款與物流狀態。
• 商品資料 (Product)：需要紀錄商品名稱、價格、庫存量與上下架狀態。

三、系統服務與功能需求 (Service Requirements)

💡 盤點系統需要提供哪些對外的「行為動作」。不需定義技術實作方式，只需列出功能清單。

服務模組	需要的行為動作	對應之商業目的
會員服務	註冊、登入、忘記密碼	讓使用者可以進入會員中心
訂單服務	建立訂單、更新付款狀態	讓使用者能成立訂單並紀錄金流
報表服務	匯出當月營收 CSV	供管理員每月作帳使用

四、開發里程碑與模組劃分 (Milestones & Modules)

💡 分析師在此定義出系統的大功能階段（Milestones）。後續交接給「工程團隊」時，由他們自行拆解為開發任務。

• [里程碑一] 基礎建設與會員系統 (預估排程：第 1~2 週)
  • 核心模組：資料庫建置、會員註冊與登入
  • 階段交付物：可供內部測試的登入頁面與後台雛形
• [里程碑二] 核心業務功能
  • ...
• [里程碑三] UAT 修正與上線
  • ...

五、核心業務邏輯與特殊流程 (Core Workflows)

💡 專門紀錄最複雜的「動態商業流程」（如金流驗證、訂單狀態機）。可用文字條列，避免工程師誤判商業邏輯。

• [範例流程：金流付款與扣庫存邏輯]：
  1. 使用者在前端點擊付款，導向第三方金流。
  2. 收到付款成功通知後，系統將訂單狀態改為「已付款」。
  3. 商業規則：必須在「確認付款」後才能扣除庫存，若庫存不足則須退款。
  4. 觸發寄送「付款成功通知信」給使用者。

六、角色與權限矩陣 (RBAC) 🛡️ 資安防線

💡 定義系統中的身份，以及他們在商業邏輯上能看到什麼、做什麼。

角色層級	描述	前台允許操作範圍	後台允許操作範圍
Guest (訪客)	未登入的使用者	瀏覽首頁、加入購物車、登入	無法進入後台
User (一般會員)	已註冊並登入	結帳、查看自己的歷史訂單	無法進入後台
Admin (管理員)	擁有最高權限	與訪客相同	可查看所有訂單、修改商品庫存

---

文件更新歷程

• [YYYY/MM/DD] - 依據 PRD 建立系統分析初版，準備交接給工程團隊。