本章討論 Use Cases（使用案例）在敏捷開發中的角色。核心觀點是：Use Cases 應該保持簡單，它們本質上是文字描述而非圖形，而且不應該被過度複雜化。

撰寫 Use Cases#

Use Case 是從使用者視角描述系統行為的文字敘述，只記錄使用者可見的事件。

基本結構#

一個 Use Case 包含：

• 主要流程（Primary Course）：描述正常情況下的操作步驟
• 替代流程（Alternate Courses）：描述例外狀況的處理方式

重點： Use Case 不是需求文件，而是即時需求（Just-in-Time Requirements）。不要試圖在專案初期就寫出所有的 Use Cases——它們應該隨著迭代逐步浮現與精煉。

撰寫原則#

• 從使用者的角度描述：只記錄使用者能看到的行為，不涉及系統內部實作
• 保持簡短：每個 Use Case 只描述一個完整的互動場景
• 使用口語化的語言：避免技術術語，讓業務人員也能理解
• 不要過度詳細：細節應該在後續迭代中逐步補充

替代流程（Alternate Courses）#

替代流程描述主要流程中可能出現的分支與例外。每個替代流程都以「在步驟 N，如果發生 X」的格式表述。

技巧： 替代流程不需要面面俱到。只記錄對使用者有意義的例外情況即可——系統內部的錯誤處理不屬於 Use Case 的範疇。

Use Case 圖#

Use Case 圖在 UML 中用橢圓形和小人（Actor）來表示。然而作者認為 Use Case 圖的價值非常有限：

• 系統邊界圖（System Boundary Diagram）偶爾有用——它顯示哪些 Actor 與系統互動
• 但 Use Case 之間的關係（如 <<extends>>、<<generalization>>）幾乎沒有實用價值

注意： 不要在 Use Case 之間繪製 <<extends>>、<<includes>> 或繼承關係。這些關係會讓 Use Case 圖變得過於複雜，而且帶來的價值幾乎為零。Use Case 的真正價值在於文字描述本身，而非圖形。

本章小結#

Use Cases 是收集需求的實用工具，但必須遵循以下原則：

• 保持簡單：Use Cases 是文字，不是精美的圖表
• 即時撰寫：不要試圖預先寫出所有 Use Cases
• 避免過度結構化：不要用 Use Case 之間的關係來建構複雜的層次結構
• 聚焦使用者視角：只描述使用者可見的行為