跳至主要内容

User Stories 目錄

本目錄包含所有 User Story 層級的詳細文檔，按 Epic 分組。

什麼是 User Story？​

User Story 是從用戶視角描述的功能需求，遵循 INVEST 原則：

  • Independent: 獨立的（盡量減少依賴）
  • Negotiable: 可協商的（非合約，可調整）
  • Valuable: 有價值的（對用戶有明確價值）
  • Estimable: 可估算的（團隊能估算工作量）
  • Small: 小的（1-2 個 Sprint 內可完成）
  • Testable: 可測試的（有明確驗收標準）

User Stories 索引​

Epic 0: 平台基礎設施​

（尚無 User Stories）

Epic 1: 產品與作品集管理​

（尚無 User Stories）

Epic 2: 端到端訂單生命週期管理​

核心流程​

角色工作台​

Epic 3: 客戶與企業帳戶系統​

（尚無 User Stories）

Epic 4: 進階發票與支付管理​

（尚無 User Stories）

Epic 5: 數位資產與簽收工作流程​

（尚無 User Stories）

User Story 文檔模板​

創建新的 User Story 文檔時，請使用以下模板：

# US-XXX: {User Story 標題}

## User Story
**作為** {角色}
**我想要** {功能}
**以便** {業務價值}

## 驗收標準 (Acceptance Criteria)

使用 Given-When-Then 格式描述主要場景：

### Scenario 1: {場景名稱}
- **Given** {前置條件}
- **When** {執行操作}
- **Then** {預期結果}
- **And** {額外的預期結果}

### Scenario 2: {場景名稱}
- **Given** {前置條件}
- **When** {執行操作}
- **Then** {預期結果}

（列出 2-5 個主要場景）

## 業務規則 (Business Rules)
（重要的業務邏輯與限制條件）

1. 規則 1
2. 規則 2
3. ...

## UI/UX 需求 (UI/UX Requirements)
（介面設計要點）

- 介面元素描述
- 互動行為說明
- 錯誤訊息顯示
- 響應式設計要求

## 技術規格 (Technical Specifications)

### API 端點
- 端點: `POST /api/v1/{resource}`
- 權限要求: `ROLE_XXX`
- 多租戶隔離: 自動附加 `tenant_id`

### 數據模型
- 主要 Entity: `ResourceName`
- 關聯 Entity: `RelatedResource`

### 前端組件
- 使用框架組件: `@appfuse/appfuse-web` 的 XXX 組件
- 自定義組件: 位於 `src/components/XXX`

## SBE 場景 (Specification by Example)
（鏈接到 ../../sbe/epic-N/US-XXX/ 目錄的詳細場景）

- [Scenario 1: 場景名稱](../../sbe/epic-N/US-XXX/scenario-1-description.md)
- [Scenario 2: 場景名稱](../../sbe/epic-N/US-XXX/scenario-2-description.md)
- ...

## 估算 (Estimation)
- **Story Points**: X 點
- **預估工時**: X 天
- **複雜度**: 低 / 中 / 高

## 依賴 (Dependencies)
（依賴其他 User Stories 或外部系統）

- **前置條件**: US-XXX 必須先完成
- **並行開發**: 可與 US-XXX 同時進行
- **外部依賴**: 需要 XXX API 或服務

## 測試策略 (Testing Strategy)

### 單元測試
- 測試 XXX 邏輯
- 測試 YYY 計算

### 整合測試
- 測試 API 端點響應
- 測試數據庫操作

### E2E 測試
- 測試完整的用戶流程

## 完成定義 (Definition of Done)
- [ ] 代碼實作完成並通過 Code Review
- [ ] 單元測試覆蓋率 > 80%
- [ ] 整合測試通過
- [ ] E2E 測試通過（關鍵流程）
- [ ] API 文檔已更新
- [ ] UI 符合設計規範
- [ ] 多租戶隔離驗證通過
- [ ] 產品經理驗收通過

## 備註 (Notes)
（其他重要資訊或討論記錄）

命名規範​

User Story ID​

  • 格式: US-{Epic編號}{流水號}
  • 範例: US-201 (Epic 2 的第 1 個 User Story)
  • Epic 編號使用十位數（0, 1, 2, 3, 4, 5）
  • 流水號使用兩位數（01-99）

檔案名稱​

  • 格式: US-{ID}-{kebab-case-描述}.md
  • 範例: US-201-create-order.md

目錄結構​

user-stories/
├── epic-0/
│   ├── US-001-user-login.md
│   └── US-002-role-based-access.md
├── epic-2/
│   ├── US-201-create-order.md
│   └── US-202-order-state-transition.md
└── ...

撰寫指南​

1. User Story 格式​

遵循標準的 "As a... I want... So that..." 格式：

✅ 好的範例:

作為 店員
我想要 能夠為客戶創建訂單
以便 記錄客戶的購買需求並啟動訂單處理流程

❌ 不好的範例:

實作訂單創建功能

2. 驗收標準 - Given-When-Then​

使用 Gherkin 風格的 Given-When-Then 格式：

✅ 好的範例:

Given 我是已登入的店員
When 我選擇現有客戶並添加商品到訂單
And 我填寫配送地址與期望配送日期
And 我點擊「創建訂單」
Then 系統應創建訂單並自動分配訂單編號
And 訂單狀態應為「待確認」
And 我應看到訂單創建成功的通知

❌ 不好的範例:

訂單創建後應該成功

3. 業務規則要明確​

  • 列出所有重要的業務邏輯
  • 包含驗證規則
  • 說明異常處理規則

4. 技術規格要完整​

  • 明確列出 API 端點
  • 說明權限要求
  • 描述數據模型關聯

5. SBE 提供具體範例​

  • 每個 Scenario 都應有對應的 SBE 文檔
  • SBE 包含完整的請求/響應範例
  • SBE 包含邊界條件測試

Three Amigos 協作​

User Story 應由三方協作完成：

  1. 產品經理 (Product Owner)

    • 定義 User Story 與業務價值
    • 撰寫驗收標準
    • 明確業務規則

  2. 開發人員 (Developer)

    • 補充技術規格
    • 識別技術依賴
    • 估算工作量

  3. 測試人員 (QA)

    • 完善 SBE 場景
    • 定義測試策略
    • 確認完成定義

審查檢查清單​

提交 User Story 文檔前，請確認：

  • User Story 遵循 "As a... I want... So that..." 格式
  • 驗收標準使用 Given-When-Then 格式
  • 至少包含 2 個主要場景
  • 業務規則明確且完整
  • 技術規格包含 API、權限、數據模型
  • SBE 場景已建立並正確鏈接
  • Story Points 已估算
  • 依賴關係已明確
  • 完成定義已列出
  • 遵循 INVEST 原則
  • Markdown 鏈接正確無誤

參考資源​

最後更新: 2025-12-19