---
source: ../../../../skills/requirement-assistant/requirement-checklist.md
source_version: 1.0.0
translation_version: 1.0.0
last_synced: 2025-12-25
status: current
---

# 需求完整性檢查清單

> **語言**: [English](../../../../skills/requirement-assistant/requirement-checklist.md) | 繁體中文

**版本**: 1.0.0
**最後更新**: 2025-12-24
**適用範圍**: Claude Code Skills

---

## 目的

本文件提供用於驗證需求完整性和品質的檢查清單。

---

## 快速檢查清單

在提交任何需求之前，請驗證以下要點:

| 項目 | 勾選 | 問題 |
|------|:-----:|----------|
| 問題 | [ ] | 我們要解決什麼問題？ |
| 使用者 | [ ] | 誰會從中受益？ |
| 價值 | [ ] | 為什麼這很重要？ |
| 範圍 | [ ] | 包含和排除什麼？ |
| 標準 | [ ] | 我們如何知道已完成？ |
| 優先級 | [ ] | 這有多緊急？ |

---

## 按需求類型的詳細檢查清單

### 功能需求檢查清單

#### 1. 問題定義

- [ ] 問題陳述清楚
- [ ] 識別目前的痛點
- [ ] 量化影響（如可能）
- [ ] 了解根本原因

#### 2. 使用者情境

- [ ] 識別目標使用者/角色
- [ ] 描述使用者目標
- [ ] 記錄目前的替代方案
- [ ] 繪製使用者旅程（如複雜）

#### 3. 解決方案描述

- [ ] 描述功能（非實作）
- [ ] 概述使用者互動
- [ ] 陳述預期結果
- [ ] 定義成功指標

#### 4. 驗收標準

- [ ] 所有標準都可測試
- [ ] 涵蓋正常路徑
- [ ] 定義錯誤情境
- [ ] 考慮邊界情況
- [ ] 效能標準（如適用）

#### 5. 範圍定義

- [ ] 列出範圍內項目
- [ ] 列出範圍外項目
- [ ] 注明未來考慮事項
- [ ] 識別依賴關係

#### 6. 優先級與時間表

- [ ] 分配優先級（P0-P3 或 MoSCoW）
- [ ] 提供業務理由
- [ ] 注明截止日期（如有）
- [ ] 識別發布目標

---

### 錯誤報告檢查清單

#### 1. 描述

- [ ] 標題清晰且具體
- [ ] 描述簡潔
- [ ] 陳述影響/嚴重性

#### 2. 重現

- [ ] 步驟已編號
- [ ] 步驟可重現
- [ ] 列出先決條件
- [ ] 提供測試資料（如需要）

#### 3. 行為

- [ ] 描述預期行為
- [ ] 描述實際行為
- [ ] 差異清楚

#### 4. 證據

- [ ] 附加截圖（如 UI）
- [ ] 包含錯誤日誌（如可用）
- [ ] 提供堆疊追蹤（如崩潰）

#### 5. 環境

- [ ] 作業系統和版本
- [ ] 瀏覽器和版本（如網頁）
- [ ] 應用程式版本
- [ ] 相關配置

#### 6. 分類

- [ ] 分配嚴重性
- [ ] 分配優先級
- [ ] 識別元件/區域
- [ ] 連結相關問題

---

### 技術任務檢查清單

#### 1. 情境

- [ ] 為什麼需要這個？
- [ ] 它解決什麼問題？
- [ ] 什麼觸發了這個任務？

#### 2. 技術細節

- [ ] 描述方法
- [ ] 列出受影響的元件
- [ ] 注明資料庫變更
- [ ] 注明 API 變更

#### 3. 範圍

- [ ] 將變更什麼？
- [ ] 將不會變更什麼？
- [ ] 處理向後相容性

#### 4. 標準

- [ ] 完成定義清楚
- [ ] 定義測試需求
- [ ] 識別文件需求

#### 5. 風險

- [ ] 識別技術風險
- [ ] 注明緩解策略
- [ ] 回滾計畫（如部署）

---

## INVEST 驗證

使用此方法驗證使用者故事:

### Independent（獨立）

- [ ] 可以在沒有其他故事的情況下交付
- [ ] 沒有阻塞依賴關係
- [ ] 可以自由排定優先級

**如果否**: 考慮與依賴故事合併或重新定義範圍。

### Negotiable（可協商）

- [ ] 實作細節未鎖定
- [ ] 有技術討論空間
- [ ] 專注於「做什麼」，而非「如何做」

**如果否**: 移除實作細節，專注於結果。

### Valuable（有價值）

- [ ] 為使用者/利害關係人提供價值
- [ ] 解決真實問題
- [ ] 好處清楚

**如果否**: 重新考慮是否應該執行。

### Estimable（可估計）

- [ ] 團隊可以估計工作量
- [ ] 了解範圍
- [ ] 沒有重大未知數

**如果否**: 首先需要探索/研究任務。

### Small（小型）

- [ ] 可以在一個 sprint 內完成
- [ ] 通常 1-5 天的工作量
- [ ] 單一連貫的工作部分

**如果否**: 拆分成更小的故事。

### Testable（可測試）

- [ ] 清楚的驗收標準
- [ ] 可以編寫自動化測試
- [ ] 完成定義明確

**如果否**: 添加具體、可衡量的標準。

---

## 驗收標準品質檢查

對於每個驗收標準:

| 品質 | 勾選 | 範例 |
|---------|:-----:|---------|
| 具體 | [ ] | "登入按鈕為藍色 (#007bff)" 而非 "按鈕看起來不錯" |
| 可衡量 | [ ] | "回應 < 200ms" 而非 "快速回應" |
| 可達成 | [ ] | 技術上可行 |
| 相關 | [ ] | 與需求相關 |
| 可測試 | [ ] | 可以編寫測試案例 |

### 常見問題

| 問題 | 不良範例 | 良好範例 |
|-------|-------------|--------------|
| 過於模糊 | "系統運作良好" | "系統在 500ms 內回傳 200 OK" |
| 主觀 | "UI 使用者友善" | "使用者可以在 3 次點擊內完成結帳" |
| 缺少邊界情況 | "使用者可以上傳檔案" | "使用者可以上傳 1-10MB 檔案；較大檔案顯示錯誤" |
| 實作細節 | "使用 Redis 快取" | "儀表板在 1 秒內載入" |

---

## 最終審查檢查清單

在提交開發之前：

### 內容品質

- [ ] 標題清楚且具描述性
- [ ] 描述完整
- [ ] 沒有模糊的語言
- [ ] 沒有未陳述的假設
- [ ] 技術術語已解釋

### 完整性

- [ ] 所有必填欄位已填寫
- [ ] 驗收標準已定義
- [ ] 範圍邊界清楚
- [ ] 依賴項已列出
- [ ] 優先級已分配

### 一致性

- [ ] 遵循團隊範本
- [ ] 一致的術語
- [ ] 已連結到相關項目
- [ ] 標籤正確應用

### 準備開發

- [ ] 團隊可以估算工作量
- [ ] 沒有阻塞的問題
- [ ] 利害關係人批准（如果需要）
- [ ] 設計資產已準備（如果是 UI）

---

## 檢查結果

**需求標題**：___________________________

**檢查者**：___________________________

**日期**：___________________________

| 區段 | 完成 | 備註 |
|------|:----:|------|
| 問題定義 | [ ] | |
| 使用者情境 | [ ] | |
| 解決方案描述 | [ ] | |
| 驗收標準 | [ ] | |
| 範圍定義 | [ ] | |
| 優先級 | [ ] | |
| INVEST 驗證 | [ ] | |

**準備開發**：[ ] 是  [ ] 否

**行動項目**：
- ___________________________
- ___________________________

---

## 相關標準

- [需求撰寫指南](./requirement-writing.md)
- [規格驅動開發](../../core/spec-driven-development.md)

---

## 版本歷史

| 版本 | 日期 | 變更 |
|------|------|------|
| 1.0.0 | 2025-12-24 | 新增：標準區段（目的、相關標準、版本歷史、授權） |

---

## 授權

本文件以 [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/) 授權發布。

**來源**：[universal-dev-standards](https://github.com/AsiaOstrich/universal-dev-standards)
