Story 不是 IEEE 830 需求規格#
傳統的 IEEE 830 軟體需求規格（SRS）試圖在開發之前就完整記錄所有需求。User Story 與此根本不同：
- SRS 追求完整性，Story 追求恰到好處
- SRS 是分析活動的產物，Story 是對話的起點
- SRS 假設我們能預先知道一切，Story 承認不確定性是常態
無論我們多麼認真地思考和分析，都不可能在專案初期就完美地規格化一個非平凡的系統。使用者會在看到軟體後改變想法——這是正常的。
Story 不是 Use Case#
Story 和 Use Case 看似相似，但有重要差異：
| 面向 | Use Case | User Story |
|---|---|---|
| 範圍 | 通常較大，包含多個 Story | 通常較小，聚焦單一功能 |
| 完整度 | 追求完整描述 | 只記錄足夠引發對話的資訊 |
| 生命週期 | 永久的專案文件 | 用完即可丟棄 |
| 目的 | 記錄客戶與開發者的共識 | 促進發布規劃和對話 |
| UI 假設 | 容易包含 UI 細節 | 盡量避免 UI 假設 |
Figure 12.1: A sample use case for pay for a job posting
Constantine 和 Lockwood 提出的 Essential Use Case（本質用例）移除了技術和實作的假設，其中的「使用者意圖」可以直接被解讀為 User Story。
Use Case Brief#
Cockburn 提到的 Use Case Brief（用例簡述）介於 Use Case 和 Story 之間：
- 範圍仍等同於 Use Case（比單一 Story 大）
- 以非結構化的文字撰寫
- 是永久的文件，而 Story 是暫時的
Story 不是情境（Scenario）#
互動設計中的 Scenario（情境）是對使用者與系統互動的詳細敘述，通常比 Use Case 更大、更詳細：
- 情境包含設定（setting）、角色（actors）、目標和情節
- 一個情境通常涵蓋多個 Story
- 情境強調細節和寫實感，Story 強調簡潔
重點不在於思考使用者屬性的清單，而在於思考使用者的目標。從目標出發，更容易寫出有意義的 Story。
關鍵啟示#
- 不同的需求方法各有優勢，Story 不是萬靈丹
- 比起追求「完美的需求文件」，更應該追求足夠好的 Story 加上頻繁的對話
- 使用者和開發者之間的早期且頻繁的回饋循環，遠比完美的前期規格更有價值