花店管理系統：產品開發藍圖

第一節：產品路線圖 (Product Roadmap)

1.1 產品願景 (Product Vision)

台灣花卉零售業長期依賴紙本作業與口頭溝通來管理訂單、配送與客戶關係，導致接單錯誤頻繁、訂單狀態不透明、財務對帳耗時費力。隨著消費者對服務品質的期待提升，花店業者迫切需要一套整合性的數位工具來提升營運效率與客戶體驗。

花店管理系統定位為多租戶 SaaS 平台，專為中小型花店提供從接單、設計、配送到簽收的端到端數位化工作流程。不同於通用型 ERP 或電商平台，本系統深入理解花卉產業的獨特需求 — 客製化商品報價、卡片訊息管理、簽收照片確認、企業月結帳單等 — 以產業專屬的解決方案取代通用但不合身的工具。

透過角色化的工作台設計（店員接單、設計師製作、配送員簽收），每位員工只看到與自己職責相關的任務，降低學習門檻的同時提升團隊協作效率。平台的多租戶架構讓每間花店擁有獨立的資料空間與自訂配置，在共享基礎設施的規模效益下，兼顧資料安全與營運彈性。

1.2 戰略主題 (Strategic Themes)

此路線圖是我們產品的戰略指南，確保所有開發工作都與核心業務目標緊密相連 1。它採用「目標導向」結合「Now-Next-Later」的框架，專注於成果而非僅是功能交付，並為產品的演進提供了靈活性 2。

• 戰略主題一：平台基礎與 MVP 驗證：建立一個可擴展、安全的多租戶平台，並透過最小可行性產品 (MVP) 驗證核心市場價值。

• 戰略主題二：卓越營運與流程自動化：為花店業者簡化從接單到簽收的核心工作流程，提升營運效率。

• 戰略主題三：優化客戶與企業旅程：為個人及企業客戶提供無縫的訂購與管理體驗，增加客戶黏著度。

• 戰略主題四：穩健的財務與報告引擎：精確管理複雜的支付情境，為商家提供清晰的財務洞察。

1.3 路線圖 (Roadmap)

表1：花店管理系統的目標導向產品路線圖

時間框架	戰略主題	業務/產品目標	關鍵功能/措施	成功指標 (KPIs)
Now (第一至二季度)	平台基礎與 MVP 驗證	建立一個可服務多租戶的核心平台，並讓首批客戶 (包含您的第一個客戶) 能完成核心訂單流程。	多租戶架構 (共享資料庫/結構描述)；核心訂單輸入與追蹤模組；基礎客戶資料庫；標準商品管理功能。	首批客戶成功上線數量；平均訂單處理時間。
Next (第三季度)	優化客戶與企業旅程	為企業客戶提供多帳戶管理功能，提升 B2B 客戶滿意度與擴展收入。	企業帳戶系統，支援多個訂花子帳戶；客戶歷史訂單查詢。	企業客戶續約率；客服關於帳戶問題的工單數量。
Next (第三季度)	穩健的財務與報告引擎	實現月結付款功能，簡化企業客戶的結算流程，降低商家收款難度。	月結帳單生成與支付模組（現金、匯款）；支援一次付款支付多張訂單。	月結帳單處理時間；逾期帳款率。
Later (第四季度及以後)	卓越營運與流程自動化	透過照片簽收流程，提升客戶信任度並減少交貨爭議。	整合照片上傳功能的簽收工作流程；客戶可查看簽收照片。	與交貨相關的客戶投訴數量。
Later (第四季度及以後)	平台基礎與 MVP 驗證	支援完全客製化的專案（如會場佈置），並利用過去案例進行提案，開拓高端市場。	客製化專案管理模組，整合過去案例照片作為提案素材。	產生客製化提案所需時間；客製化專案的成交率。

第二節：用戶角色與權限設計 (User Roles & Permissions Design)

在多租戶花店管理系統中，清晰的角色定義是確保系統安全性、易用性與功能完整性的基石。本節定義了系統中的八種核心用戶角色，並透過權限矩陣明確各角色的操作邊界。

2.1 角色分類架構

系統用戶分為兩大類：內部用戶（花店端） 與 外部用戶（客戶端）。

---

2.2 內部用戶角色 (Internal Roles)

角色 1: 系統管理員 (System Admin)

• 責任範疇：租戶層級的系統配置與維護
• 典型使用場景：
  • 為新花店創建租戶實例
  • 配置系統級設定（如第三方整合 API 金鑰）
  • 管理所有員工帳號並分配角色
• 多租戶考量：跨租戶操作權限（僅限平台營運商的超級管理員）

角色 2: 花店擁有者/管理者 (Shop Owner/Manager)

• 責任範疇：完整的業務運營與決策權
• 典型使用場景：
  • 查看所有財務報表與訂單統計
  • 設定商品價格與促銷規則
  • 管理員工帳號與績效評估
  • 配置店鋪資訊（營業時間、配送範圍）
• 多租戶考量：僅能訪問自己租戶的數據

角色 3: 店員/接單人員 (Sales Staff)

• 責任範疇：日常訂單處理與客戶服務
• 典型使用場景：
  • 接聽電話或接待客戶，創建訂單
  • 修改訂單詳情（如客戶要求變更卡片訊息）
  • 處理客戶查詢訂單狀態
  • 維護客戶聯絡資訊
• 權限限制：無法查看財務敏感數據（如成本、利潤）

角色 4: 花藝設計師 (Florist/Designer)

• 責任範疇：訂單的設計與製作
• 典型使用場景：
  • 查看分配給自己的訂單工作列表
  • 標記訂單狀態為「設計中」
  • 完成製作後上傳作品照片
  • 將訂單狀態變更為「待出貨」
• 權限限制：僅能查看與自己相關的訂單

角色 5: 送貨人員 (Delivery Personnel)

• 責任範疇：配送與簽收確認
• 典型使用場景：
  • 查看當日配送路線與訂單清單
  • 在客戶簽收時上傳現場照片
  • 更新訂單狀態為「已簽收」
  • 記錄配送異常（如客戶不在、拒收）
• 權限限制：無法修改訂單金額或客戶資料

---

2.3 外部用戶角色 (External Roles)

角色 6: 個人客戶 (Individual Customer)

• 責任範疇：管理個人訂單與資料
• 典型使用場景：
  • 查詢自己的歷史訂單
  • 查看訂單狀態與簽收照片
  • 更新個人聯絡資訊與常用配送地址
• 權限限制：僅能查看與自己相關的訂單

角色 7: 企業客戶管理員 (Corporate Account Admin)

• 責任範疇：管理企業帳戶與子帳戶
• 典型使用場景：
  • 為公司各部門創建子帳戶（如人資部、行銷部）
  • 查看企業所有部門的訂單記錄
  • 處理月結帳單與統一支付
  • 設定子帳戶的訂單額度限制
• 多租戶考量：企業帳戶內的子帳戶隔離

角色 8: 企業子帳戶用戶 (Corporate Sub-Account User)

• 責任範疇：為所屬部門/單位下訂單
• 典型使用場景：
  • 以部門名義下訂單（由企業主帳戶統一結算）
  • 查看自己部門的訂單歷史
  • 追蹤訂單狀態
• 權限限制：無法查看其他部門的訂單或財務資訊

---

2.4 權限矩陣 (Permission Matrix)

以下矩陣定義了各角色對核心功能模組的訪問權限（✓ = 完整權限，◐ = 部分權限，✗ = 無權限）。

功能模組	系統管理員	店主/管理者	店員	設計師	送貨員	個人客戶	企業管理員	企業子帳戶
租戶管理	✓	✗	✗	✗	✗	✗	✗	✗
員工帳號管理	✓	✓	✗	✗	✗	✗	✗	✗
商品目錄管理	✓	✓	◐	◐	✗	✗	✗	✗
商品價格設定	✓	✓	✗	✗	✗	✗	✗	✗
訂單創建	✓	✓	✓	✗	✗	✗	◐	◐
訂單修改	✓	✓	✓	◐	◐	✗	✗	✗
訂單查詢	✓	✓	✓	◐	◐	◐	◐	◐
訂單狀態更新	✓	✓	✓	◐	◐	✗	✗	✗
作品照片上傳	✓	✓	◐	✓	✗	✗	✗	✗
簽收照片上傳	✓	✓	◐	✗	✓	✗	✗	✗
簽收照片查看	✓	✓	✓	✗	✓	✓	✓	✓
客戶資料管理	✓	✓	✓	✗	✗	◐	◐	◐
子帳戶管理	✓	✓	✗	✗	✗	✗	✓	✗
財務報表	✓	✓	✗	✗	✗	✗	◐	✗
支付處理	✓	✓	✓	✗	✗	✗	✓	✗
月結帳單	✓	✓	◐	✗	✗	✗	✓	✗

權限圖例說明：

• ✓ 完整權限：可執行所有 CRUD 操作（創建、讀取、更新、刪除）
• ◐ 部分權限：受限於特定條件（如「僅查看自己的訂單」、「只能更新狀態」）
• ✗ 無權限：完全無法訪問該功能模組

---

2.5 權限設計原則

1. 最小權限原則 (Principle of Least Privilege)：每個角色僅被授予完成其職責所需的最低權限。

2. 職責分離 (Separation of Duties)：敏感操作（如價格設定、財務查看）僅限於管理層角色。

3. 數據隔離：

   • 租戶層級：不同花店的數據完全隔離。
   • 角色層級：員工僅能訪問與自己職責相關的數據。
   • 客戶層級：個人客戶與企業客戶的數據訪問權限嚴格區分。

4. 可審計性：所有敏感操作（如訂單修改、支付處理）需記錄操作者身份與時間戳。

---

第三節：核心 Epics 解構 (Core Epics Deconstruction)

Epics 是將路線圖中的戰略主題轉化為具體功能模組的大型工作主體 3。以下是我們系統的六大核心 Epics，它們共同構成了產品的骨幹架構。

---

Epic 0: 平台基礎設施與橫切關注點 (Platform Infrastructure & Cross-Cutting Concerns)

• 目標 (Goal): 建立一個安全、可擴展、可審計的多租戶平台基礎設施，為所有業務功能提供統一的支撐服務。

• 範疇 (Scope):

  • 認證與授權 (Authentication & Authorization)：

    • 多租戶身份驗證：支援員工登入與客戶登入兩套獨立的認證流程。

    • JWT Token 管理：實現安全的 token 生成、刷新與撤銷機制。

    • 角色基礎訪問控制 (RBAC)：根據第二節定義的八種角色，實現細粒度的權限控制。

    • API 層級權限檢查：確保每個 API 端點都進行角色驗證。

  • 通知系統 (Notification System)：

    • 多通道支援：整合簡訊（SMS）、電子郵件、站內訊息三種通知方式。

    • 事件觸發通知：

      • 訂單狀態變更通知（如「設計完成」、「已出貨」、「已簽收」）

      • 支付提醒（月結帳單到期、逾期提醒）

      • 異常警報（配送失敗、庫存不足）

    • 通知偏好設定：允許用戶自定義接收哪些類型的通知。

  • 審計日誌 (Audit Logging)：

    • 關鍵操作記錄：

      • 訂單創建、修改、刪除

      • 價格調整

      • 支付處理

      • 權限變更

    • 日誌內容：記錄「誰（用戶 ID + 角色）」、「何時（時間戳）」、「做了什麼（操作類型）」、「對什麼（資源 ID）」、「結果（成功/失敗）」。

    • 合規性需求：日誌保留至少 3 年，支援財務審計查詢。

  • 全域搜尋與過濾 (Global Search & Filtering)：

    • 跨模組搜尋：支援在訂單、客戶、商品等模組中快速搜尋。

    • 高級過濾器：

      • 訂單：按狀態、日期範圍、金額區間、客戶類型過濾

      • 客戶：按類型（個人/企業）、註冊時間、訂單數量過濾

      • 商品：按類型、價格區間、庫存狀態過濾

    • 搜尋效能優化：考慮使用 Elasticsearch 或全文索引技術。

  • 系統配置管理 (System Configuration)：

    • 租戶層級配置：每個花店可自定義營業時間、配送範圍、稅率設定。

    • 第三方整合配置：集中管理 API 金鑰（如支付閘道、簡訊服務、雲端儲存）。

    • 功能開關 (Feature Flags)：允許為特定租戶啟用或停用某些功能（如月結付款）。

• 關鍵依賴性 (Key Dependencies):

  • 所有其他 Epics 都依賴於此 Epic 提供的認證、授權、通知與審計功能。

• 多租戶考量 (Multi-Tenancy Considerations):

  • 嚴格的數據隔離：所有服務（通知、日誌、搜尋）都必須遵守租戶隔離原則。

  • 配置隔離：每個租戶的配置獨立儲存，避免相互影響。

  • 效能隔離：單一租戶的大量操作（如批量發送通知）不應影響其他租戶的系統體驗。

• 安全性考量 (Security Considerations):

  • 密碼策略：強制密碼複雜度要求（最少 8 碼、包含大小寫字母與數字）。

  • 會話管理：Token 有效期設定（如 Access Token 15 分鐘，Refresh Token 7 天）。

  • 防範攻擊：實現速率限制 (Rate Limiting)、防止 CSRF 攻擊、SQL 注入防護。

  • 敏感資料加密：客戶個資、支付資訊使用 AES-256 加密儲存。

---

Epic 1: 產品與作品集管理 (Product & Portfolio Management)

• 目標 (Goal): 建立一個靈活的商品管理系統，讓花店能夠輕鬆管理從標準化到完全客製化的所有商品類型，並有效利用視覺素材進行銷售。

• 範疇 (Scope):

  • 商品類型管理：支援「盆花」、「束花」、「高架」、「花籃」、「盒花」等標準化商品類型。

  • 客製化專案管理：支援「會場」等完全客製化的專案類型。

  • 定價規則：

    • 標準化商品需有參考價格。

    • 系統需允許在訂單層級對價格進行調整（例如，因應客戶要求增加花材）。

    • 客製化專案無固定價格。

  • 照片與作品集：

    • 每項商品都需關聯參考照片。

    • 客製化專案可關聯至過去的案例照片，作為提案素材。

• 關鍵依賴性 (Key Dependencies):

  • 依賴 Epic 5 (數位資產管理) 來儲存與管理所有商品及案例照片。

• 多租戶考量 (Multi-Tenancy Considerations):

  • 每個租戶（花店）擁有獨立的產品目錄。

  • 商品資料表必須包含 Tenant_ID 欄位，以確保資料隔離。

---

Epic 2: 端到端訂單生命週期管理 (End-to-End Order Lifecycle Management)

• 目標 (Goal): 打造一個清晰、高效的訂單處理工作流程，涵蓋從接單到完成簽收的每一個環節，最大化地減少人工錯誤，並確保所有利害關係人都能即時掌握訂單狀態。

• 範疇 (Scope):

  • 訂單狀態機 (Order State Machine)：

    訂單狀態流轉如下：

    待確認 → 已確認 → 設計中 → 待出貨 → 配送中 → 已簽收 → 已完成
                 ↓           ↓         ↓         ↓
               已取消      已取消    已取消    配送失敗

    狀態定義：

    • 待確認 (Pending Confirmation)：訂單剛創建，等待客戶或店員確認細節。
    • 已確認 (Confirmed)：訂單已確認，等待分配給設計師。
    • 設計中 (In Production)：設計師正在製作商品。
    • 待出貨 (Ready for Delivery)：商品完成，等待送貨員取貨配送。
    • 配送中 (Out for Delivery)：送貨員正在配送途中。
    • 已簽收 (Delivered)：客戶已簽收，簽收照片已上傳。
    • 已完成 (Completed)：訂單完全結束（已支付 + 已簽收）。
    • 已取消 (Cancelled)：訂單在任何階段被取消（需記錄取消原因）。
    • 配送失敗 (Delivery Failed)：配送時客戶不在或拒收（需記錄失敗原因）。

    狀態流轉規則：

    • 「待確認」→「已確認」：需店員/管理者手動確認。
    • 「已確認」→「設計中」：系統自動分配或管理者手動分配給設計師。
    • 「設計中」→「待出貨」：設計師標記為完成並上傳作品照片。
    • 「待出貨」→「配送中」：送貨員接單並開始配送。
    • 「配送中」→「已簽收」：送貨員上傳簽收照片並標記完成。
    • 「已簽收」→「已完成」：系統檢查支付狀態，若已支付則自動轉為「已完成」。
    • 任何狀態 → 「已取消」：管理者/店主可在「已簽收」前取消訂單。

  • 訂單創建 (Order Creation)：

    • 必填資訊：

      • 客戶資訊（選擇現有客戶或創建新客戶）
      • 商品列表（可選擇多個商品）
      • 配送地址與聯絡電話
      • 期望配送日期與時段
      • 卡片訊息（可選）

    • 可選資訊：

      • 特殊要求（如「不要百合」、「多加玫瑰」）
      • 收件人資訊（如與訂購客戶不同）
      • 訂單備註（內部使用）

    • 價格計算：

      • 系統根據選擇的商品自動計算小計
      • 店員可手動調整最終價格（需記錄調整原因）
      • 自動計算稅額（根據租戶設定的稅率）

  • 訂單客製化 (Order Customization)：

    • 在創建訂單時，能夠記錄客戶的特殊要求並調整最終價格。
    • 支援「完全客製化」訂單（如會場佈置），無需選擇商品，直接輸入需求描述。

  • 訂單分配 (Order Assignment)：

    • 設計師分配：

      • 管理者可手動將「已確認」訂單分配給特定設計師。
      • 或設定自動分配規則（如輪流分配、負載平衡）。

    • 送貨員分配：

      • 管理者可手動將「待出貨」訂單分配給送貨員。
      • 或送貨員自行從「待出貨」列表中接單。
      • 支援批量分配（如將同一區域的訂單分配給同一送貨員）。

  • 訂單修改與取消 (Order Modification & Cancellation)：

    • 訂單修改：

      • 「待確認」和「已確認」階段可完整修改訂單內容。
      • 「設計中」之後僅可修改配送資訊與卡片訊息。
      • 所有修改需記錄審計日誌。

    • 訂單取消：

      • 「已簽收」之前可取消訂單。
      • 取消時需選擇原因（如「客戶要求」、「無法聯繫客戶」、「庫存不足」）。
      • 若已支付，自動觸發退款流程（整合 Epic 4）。

  • 訂單搜尋與過濾 (Order Search & Filtering)：

    • 搜尋條件：訂單編號、客戶姓名、電話、配送地址。
    • 過濾條件：
      • 狀態（可多選）
      • 日期範圍（創建日期、配送日期）
      • 金額區間
      • 分配的設計師/送貨員

  • 訂單通知 (Order Notifications)：

    • 整合 Epic 0 通知系統，在關鍵狀態變更時發送通知：
      • 訂單確認後 → 通知客戶
      • 設計完成後 → 通知客戶與送貨員
      • 配送中 → 通知客戶預計送達時間
      • 已簽收 → 通知客戶查看簽收照片

• 關鍵依賴性 (Key Dependencies):

  • 依賴 Epic 1 (產品管理) 獲取商品資訊。

  • 依賴 Epic 3 (客戶管理) 關聯訂購客戶。

  • 依賴 Epic 5 (數位資產管理) 在「簽收」環節上傳照片。

  • 依賴 Epic 0 (通知系統) 發送狀態變更通知。

  • 依賴 Epic 4 (支付管理) 處理取消訂單的退款。

• 多租戶考量 (Multi-Tenancy Considerations):

  • 所有訂單資料都必須與一個 Tenant_ID 綁定。

  • 訂單編號系統建議採用租戶層級獨立編號（如格式：{Tenant_Prefix}-{YYYYMMDD}-{序號}，例如 ABC-20250126-0001）。

  • 訂單分配僅能分配給同一租戶的員工。

---

Epic 3: 客戶與企業帳戶系統 (Customer & Corporate Account System - CRM)

• 目標 (Goal): 提供一個全面的客戶關係管理系統，能夠無差別地服務個人客戶，並為企業客戶提供強大的多帳戶管理功能。

• 範疇 (Scope):

  • 客戶類型：系統需區分「個人」與「企業」兩種客戶類型。

  • 個人客戶：管理單一帳戶，包含聯絡資訊與訂單歷史。

  • 企業客戶：

    • 支援父子帳戶結構，一個企業主帳戶下可掛載多個部門或員工的子帳戶。

    • 允許企業主帳戶統一管理與結算。

• 關鍵依賴性 (Key Dependencies):

  • Epic 4 (支付管理) 需要查詢客戶的結算方式（例如，是否為月結客戶）。

• 多租戶考量 (Multi-Tenancy Considerations):

  • 每個租戶擁有自己獨立的客戶資料庫。

  • 客戶資料表必須包含 Tenant_ID 欄位。

---

Epic 4: 進階發票與支付管理 (Advanced Invoicing & Payment Gateway)

• 目標 (Goal): 建立一個穩健且靈活的財務系統，能夠處理多樣化的支付方式與複雜的結算規則，確保金流的準確性與合規性。

• 範疇 (Scope):

  • 支付方式：

    • 一般付款：支援記錄「現金」、「匯款」、「信用卡」支付。

    • 月結付款：支援記錄「現金」、「匯款」支付。

    • 部分支付：允許客戶分期支付訂單金額（如訂金 + 尾款）。

  • 發票生成與管理：

    • 自動發票生成：訂單完成時自動生成發票，包含：

      • 發票編號（租戶層級唯一）
      • 開立日期與到期日
      • 商品明細與金額分項
      • 稅額計算（支援可配置的稅率，如 5% 營業稅）

    • 發票格式：支援匯出 PDF 格式發票，包含店家 Logo 與完整地址。

    • 發票狀態追蹤：「已開立」、「已支付」、「已作廢」、「已逾期」。

    • 作廢與重開機制：允許管理者作廢錯誤發票並重新開立（需記錄審計日誌）。

  • 多對多映射：

    • 支援「一次付款」結清「多張訂單」（適用於月結客戶統一支付）。

    • 支援「一次請款」針對「多張訂單」生成合併帳單。

  • 月結帳單管理：

    • 帳單生成規則：每月自動生成上月所有未付訂單的合併帳單。

    • 帳單內容：

      • 帳單期間（如 2025-01-01 至 2025-01-31）
      • 訂單明細列表（訂單編號、日期、金額）
      • 小計、稅額、總計

    • 到期提醒：到期前 3 天、到期當天、逾期 3 天自動發送提醒通知（整合 Epic 0 通知系統）。

    • 逾期處理：

      • 逾期 7 天：標記為「逾期」狀態，發送催款通知。
      • 逾期 30 天：升級為「嚴重逾期」，通知店主/管理者。
      • 逾期 60 天：考慮暫停該客戶的月結權限，改為預付款。

  • 退款機制：

    • 退款觸發場景：

      • 訂單取消（全額退款）
      • 商品問題（部分或全額退款）
      • 重複支付（退還多付金額）

    • 退款流程：

      1. 店員/管理者發起退款申請（需註明原因）。
      2. 管理者審核批准（金額 > $1000 需雙重審核）。
      3. 系統記錄退款交易（原支付方式原路退回）。
      4. 通知客戶退款完成（整合 Epic 0 通知系統）。

    • 退款記錄：所有退款需記錄審計日誌，包含操作者、時間、原因、金額。

  • 支付對帳功能：

    • 日結報表：每日自動生成當日收款匯總（按支付方式分類）。

    • 差異檢測：比對系統記錄與實際銀行入帳，標記差異項目。

    • 財務報表：提供月度、季度、年度的收入分析報表。

• 關鍵依賴性 (Key Dependencies):

  • 與 Epic 2 (訂單管理) 和 Epic 3 (客戶管理) 緊密耦合，以處理帳單與支付。

  • 依賴 Epic 0 (通知系統) 發送支付提醒與逾期通知。

• 多租戶考量 (Multi-Tenancy Considerations):

  • 所有交易、支付、發票記錄都必須與 Tenant_ID 關聯。

  • 發票編號系統需以租戶為單位獨立編號（避免跨租戶號碼衝突）。

  • 若整合第三方支付閘道，需為每個租戶配置獨立的 API 金鑰。

• 合規性考量 (Compliance Considerations):

  • 稅務合規：發票格式需符合台灣稅法規定（如統一編號、營業稅計算）。

  • 電子發票：未來可考慮整合政府電子發票系統（如財政部電子發票整合服務平台）。

  • 金流安全：信用卡號碼需遵循 PCI DSS 規範（僅儲存末四碼，完整卡號由第三方支付處理）。

---

Epic 5: 數位資產與簽收工作流程 (Digital Asset & Sign-off Workflow)

• 目標 (Goal): 建立一個高效能、可擴展的數位資產管理系統，無縫整合到產品展示、生產和交付確認的各個環節中，提升透明度與客戶滿意度。

• 範疇 (Scope):

  • 商品照片展示：

    • 照片類型：商品目錄展示圖片（支援多圖展示，如不同角度）。

    • 圖片規格：建議最低解析度 800x800px，支援 JPEG/PNG/WebP 格式。

    • 圖片管理：允許管理者為每個商品上傳、排序、刪除照片，並設定主圖。

  • 生產成果記錄：

    • 作品上傳：允許設計師在訂單完成後上傳完成品照片（最多 10 張）。

    • 照片標記：照片可被標記為「公開作品集」，用於未來客戶提案或官網展示。

    • 水印功能：系統自動為作品集照片添加店家 Logo 水印（防止盜圖）。

    • EXIF 資料保留：保留拍攝時間等元資料，便於追蹤作品創作時間。

  • 照片簽收：

    • 簽收照片上傳：送貨人員在現場使用行動裝置上傳簽收照片（最多 3 張）。

    • GPS 定位記錄：自動記錄上傳照片的地理位置（可選，需用戶授權）。

    • 時間戳記：照片自動附帶不可竄改的時間戳（確保證明效力）。

    • 客戶查看：客戶可透過訂單頁面查看簽收照片，增加信任度。

  • 儲存策略與架構：

    • 雲端儲存選擇：

      • AWS S3 / Google Cloud Storage / Azure Blob Storage（推薦 S3，生態系統完善）
      • 考慮成本因素，可選擇較便宜的區域（如 ap-northeast-1 東京）

    • 資料夾結構（租戶隔離）：

      /{bucket-name}/
        ├── tenant-{tenant_id}/
        │   ├── products/           # 商品照片
        │   │   ├── {product_id}/
        │   │   │   ├── main.jpg
        │   │   │   ├── thumb_main.jpg
        │   │   │   └── gallery_1.jpg
        │   ├── portfolios/         # 作品集照片
        │   │   ├── {order_id}/
        │   │   │   ├── finished_1.jpg
        │   │   │   └── watermarked_finished_1.jpg
        │   └── sign-offs/          # 簽收照片
        │       ├── {order_id}/
        │       │   ├── delivered_1.jpg
        │       │   └── delivered_2.jpg

    • 檔案命名規則：使用 UUID + 原始檔名（避免檔名衝突）。

  • 圖片優化與處理：

    • 自動壓縮：

      • 原圖保留（用於高清下載）
      • 自動生成壓縮版（Web 顯示，品質 85%，大小縮減 60-70%）
      • 自動生成縮圖（列表顯示，尺寸 200x200px）

    • 格式轉換：

      • 自動轉換為 WebP 格式（相同品質下體積比 JPEG 小 25-35%）
      • 保留原始格式作為備份

    • 響應式圖片：使用 srcset 技術，根據裝置螢幕大小載入適當尺寸的圖片。

    • 延遲載入 (Lazy Loading)：圖片在滾動到可見區域時才載入，提升頁面效能。

  • 檔案限制與驗證：

    • 檔案大小限制：

      • 商品照片：單張最大 10MB
      • 作品集照片：單張最大 10MB
      • 簽收照片：單張最大 5MB（考慮行動網路上傳速度）

    • 格式限制：僅支援 JPEG、PNG、WebP（拒絕 GIF、BMP 等格式）。

    • 安全驗證：

      • 檢查檔案 MIME 類型（防止偽造副檔名）
      • 掃描惡意檔案（整合病毒掃描 API）
      • 阻擋過小的圖片（< 100KB 可能是無效圖片）

  • CDN 分發策略：

    • CDN 整合：使用 CloudFront (AWS) / Cloud CDN (GCP) 加速全球訪問。

    • 快取策略：

      • 商品照片：長期快取（Cache-Control: max-age=2592000，30 天）
      • 簽收照片：短期快取（Cache-Control: max-age=86400，1 天）

    • 失效機制：商品照片更新時自動清除 CDN 快取。

  • 存取權限控制：

    • 公開訪問：商品照片可公開訪問（用於官網展示）。

    • 私密訪問：簽收照片僅客戶與花店員工可查看（使用預簽名 URL，有效期 1 小時）。

    • 作品集照片：僅標記為「公開」的照片可被非客戶訪問。

• 關鍵依賴性 (Key Dependencies):

  • 為 Epic 1 (產品管理) 和 Epic 2 (訂單管理) 提供核心的照片管理功能。

  • 依賴 Epic 0 (系統配置管理) 儲存雲端儲存 API 金鑰與 CDN 配置。

• 多租戶考量 (Multi-Tenancy Considerations):

  • 所有數位資產（圖片）必須透過 Tenant_ID 進行嚴格隔離，確保一個花店的資產絕不會被另一家看到或使用。

  • 儲存路徑必須包含 tenant_id，API 層級需驗證用戶是否有權限訪問該租戶的資產。

  • 儲存配額管理：每個租戶分配儲存空間配額（如基礎方案 50GB，進階方案 200GB）。

• 效能與成本考量 (Performance & Cost Considerations):

  • 儲存成本估算：

    • 假設單租戶平均儲存 10GB 圖片
    • S3 標準儲存：約 $0.023/GB/月 = $0.23/月/租戶
    • 100 個租戶約 $23/月

  • 傳輸成本：

    • 使用 CDN 可減少 S3 出站流量費用（CDN 費率較低）

  • 效能優化：

    • 圖片處理使用非同步佇列（如 AWS SQS + Lambda），避免阻塞主應用程式。
    • 大量上傳場景使用直傳 S3（前端直接上傳到 S3，減輕後端負擔）。

---

第四節：非功能性需求 (Non-Functional Requirements)

非功能性需求定義了系統在效能、安全性、可用性等方面的品質標準，確保產品不僅「能用」，更「好用」且「可靠」。

4.1 效能需求 (Performance Requirements)

指標	目標	衡量方式
API 響應時間	95% 的請求在 500ms 內完成	使用 APM 工具（如 New Relic）監控
訂單處理時間	從創建到儲存完成 < 2 秒	後端日誌記錄處理時長
頁面載入時間	首次內容渲染 (FCP) < 1.5 秒	Lighthouse 效能評分 > 90
圖片上傳	5MB 圖片上傳 < 10 秒	前端上傳進度監控
搜尋查詢	全文搜尋結果返回 < 1 秒	搜尋引擎效能測試
並發用戶	單租戶支援 50 個並發用戶	負載測試（如 JMeter）
數據庫查詢	複雜查詢（如財務報表）< 3 秒	慢查詢日誌分析

優化策略：

• 實現 Redis 快取層，緩存熱門商品與客戶資料
• 圖片採用 CDN 分發，並自動生成縮圖
• 資料庫索引優化（特別是 Tenant_ID 與 OrderDate 欄位）
• 前端實現虛擬滾動（Virtualization）處理大型列表

---

4.2 可用性與可靠性 (Availability & Reliability)

指標	目標	實現方式
系統可用率	99.5% (每月停機 < 3.6 小時)	多節點部署 + 負載均衡
資料備份	每日自動備份，保留 30 天	自動化備份腳本 + 雲端儲存
災難恢復 (RTO)	恢復時間目標 < 4 小時	熱備份資料庫 + 部署腳本
數據持久性 (RPO)	恢復點目標 < 1 小時	增量備份 + 交易日誌
錯誤處理	所有 API 錯誤有明確的錯誤碼與訊息	統一異常處理機制

監控與警報：

• 實現健康檢查端點 (/health)，監控服務狀態
• 設定關鍵指標警報（CPU > 80%、記憶體 > 85%、磁碟 > 90%）
• 使用 Sentry 或類似工具追蹤前端錯誤

---

4.3 安全性需求 (Security Requirements)

領域	要求	實現方式
身份驗證	強制密碼複雜度（8 碼、大小寫+數字）	前端驗證 + 後端正則檢查
會話管理	Access Token 15 分鐘，Refresh Token 7 天	JWT 實現 + Token 刷新機制
數據加密	敏感資料（密碼、支付資訊）加密儲存	bcrypt 密碼雜湊 + AES-256 數據加密
傳輸安全	所有 API 通訊使用 HTTPS/TLS 1.3	SSL 憑證 + HSTS Header
防範攻擊	防止 SQL 注入、XSS、CSRF	參數化查詢 + CSP Header + CSRF Token
速率限制	每個 IP 每分鐘最多 100 個請求	API Gateway 或 Nginx 限流
權限控制	所有 API 端點進行角色驗證	中介軟體層級的權限檢查

合規性：

• 遵循 OWASP Top 10 安全標準
• 如服務歐盟客戶，需考慮 GDPR 合規（如「被遺忘權」）
• 定期進行安全掃描與滲透測試

---

4.4 擴展性需求 (Scalability Requirements)

維度	目標	架構策略
租戶擴展	支援至少 100 個活躍租戶	共享資料庫多租戶架構
數據量	單租戶 10 萬筆訂單查詢效能不衰減	資料表分區（Partitioning）
垂直擴展	支援從 2 核 4GB 擴展至 8 核 32GB	雲端虛擬機器彈性配置
水平擴展	API 服務支援多實例部署	無狀態設計 + Load Balancer
儲存擴展	圖片儲存支援 TB 級別	雲端物件儲存（如 AWS S3）

未來考量：

• 如租戶數量超過 500，考慮遷移至「獨立資料庫」多租戶模式
• 訂單歷史數據可歸檔至冷儲存（如超過 3 年的訂單）

---

4.5 可維護性需求 (Maintainability Requirements)

領域	要求	實踐方式
程式碼品質	測試覆蓋率 > 80%	單元測試 + 整合測試
文檔完整性	所有 API 有 OpenAPI 文檔	Swagger/OpenAPI 規範
日誌記錄	結構化日誌，支援快速查詢	JSON 格式日誌 + ELK Stack
版本控制	API 支援版本管理（如 /api/v1/）	URL 或 Header 版本控制
持續整合	每次提交自動執行測試與建構	GitHub Actions/GitLab CI
部署策略	支援零停機部署	藍綠部署或滾動更新

開發規範：

• 採用統一的編碼風格（如 ESLint + Prettier）
• Code Review 機制（至少一人審查後才能合併）
• 關鍵變更需附帶變更日誌（CHANGELOG.md）

---

4.6 可用性與無障礙性 (Usability & Accessibility)

領域	要求	實現方式
響應式設計	支援桌面、平板、手機三種螢幕尺寸	CSS Grid/Flexbox + 媒體查詢
瀏覽器相容	支援 Chrome/Edge/Safari/Firefox 最新兩個版本	Babel 轉譯 + Polyfills
國際化 (i18n)	介面支援繁體中文、簡體中文、英文	React-i18next 或類似方案
無障礙性 (A11y)	符合 WCAG 2.1 AA 標準	語意化 HTML + ARIA 標籤
操作回饋	所有操作有即時反饋（載入動畫、成功/失敗訊息）	Toast 通知 + Loading 狀態

用戶體驗目標：

• 新用戶無需培訓即可完成「創建訂單」操作（目標：5 分鐘內完成）
• 關鍵操作（如支付）需有二次確認機制

---

4.7 合規性與業務連續性 (Compliance & Business Continuity)

領域	要求
資料保留	財務數據保留 7 年（符合稅務規定）
審計追蹤	所有訂單修改與支付操作可回溯
服務等級協議 (SLA)	與租戶簽訂明確的可用率與支援響應時間承諾
業務連續性計畫	制定關鍵服務中斷時的應急流程（如手動訂單處理）