需求分析與規格
從模糊的「我想要一個功能」，走到可以開發與驗收的工作定義
從模糊的「我想要一個功能」，走到可以開發與驗收的工作定義
需求從哪裡來？
- 使用者遇到的問題與工作流程
- 業務目標、法規、政策或組織要求
- 舊系統的限制、缺陷與技術債
- 上線後的數據、事故與客服回饋
- 外部服務、資料格式或標準的變更
先區分問題、解法與需求
| 層次 | 問法 |
|---|---|
| 問題 | 現在誰在什麼情境下受到什麼影響？ |
| 目標 | 改善後希望出現什麼結果？ |
| 解法 | 可以用哪些方式達成？ |
| 需求 | 系統必須具備哪些行為與限制？ |
不要一聽到解法，就跳過真正的問題。
Stakeholder 與需求訪談
- 誰使用、誰付費、誰維運、誰承擔風險？
- 現在的流程怎麼做？哪裡最常失敗？
- 哪些是明講的需求，哪些是隱藏規則？
- 不同角色的目標是否互相衝突？
- 哪些說法需要用資料或現場操作查證？
User Story 與 Use Case
User Story：
身為＿＿，我希望＿＿，以便＿＿。
Use Case：
前置條件 → 主要流程 → 替代流程 → 例外流程 → 後置狀態Story 表達價值；Use Case 展開互動與例外。
功能需求與非功能需求
| Functional Requirement | Non-functional Requirement |
|---|---|
| 系統要做什麼 | 系統要做到什麼程度 |
| 查詢、修改、通知、匯出 | 效能、可用性、安全、相容性 |
| 可以用操作結果驗證 | 通常需要明確指標與條件 |
Domain Knowledge 與共同語言
- 定義領域名詞，避免同一個字各自解讀
- 找出 entity、value、event、rule 與狀態
- 把公式、規範、資料來源與例外正式記錄
- 確認哪些規則是法律要求、組織慣例或暫時做法
- 建立 glossary，讓文件、Code 與畫面使用一致名稱
Acceptance Criteria：怎樣算完成？
Given 已知的前置狀態
When 使用者或系統執行某個行為
Then 應該觀察到的結果要包含正常、邊界、錯誤、權限與資料狀態。
Scope、Constraint 與 Assumption
- In scope：這一輪確定要完成什麼
- Out of scope：刻意不處理什麼
- Constraint：時間、預算、技術、法規、環境限制
- Assumption：目前尚未證實但先依賴的條件
- Dependency：需要等待的團隊、資料或外部系統
Backlog 與優先順序
- Epic → feature → story → task
- 用價值、風險、成本與相依性排序
- 定義 Definition of Ready 與 Definition of Done
- 保留尚未決定的問題，不假裝規格已經完整
- 每次迭代重新檢查優先順序
需求變更不是例外
提出變更 → 說明原因 → 分析影響範圍
→ 更新規格與驗收 → 調整優先順序
→ 實作、測試、發布 → 留下紀錄關鍵字：change request、impact analysis、traceability。
一個需求進入開發前的產物
- 問題與目標敘述
- Stakeholder 與使用情境
- 流程、story、use case 與 domain glossary
- Functional／non-functional requirements
- Acceptance criteria、scope、constraint、assumption
- Backlog item、優先順序與 owner
看到 Agent 整理需求時
要能辨認它是在補 story、use case、NFR，
還是在改變 scope、assumption 或 acceptance criteria。