1. 基本概念
一個用例就是與參與者（actor）交互的，並且給參與者提供可觀測的有意義的結果的一系列活動的集合。
所謂的用例就是一件事情，要完成這件事情需要做一系列的活動；而做一件事情可以有很多不同的辦法和步驟，也可能會遇到各種各樣的意外情況，因此這件事情是由很多不同情況的集合構成的，在UML中稱之為用例場景，一個場景就是一個用例的實例。
要啟動用例是有條件的，這是啟動用例的前提（前置條件）；用例執行完了會有一個結果，成為后置條件。
綜上所述，一個完整的用例由參與者、前置條件、場景、后置條件構成。
2. 用例的特征
- 用例之間是相互獨立的
- 用例的執行結果對參與者來說是可觀測且有意義的
- 不存在沒有參與者的用例，參與者啟動用例（用例不應該自動啟動，也不應該主動啟動另一個用例）
- 用例必然是以動賓短語形式出現的（構成一個完整的事件，例如喝水而不是喝）
- 一個用例就是一個需求單元、分析單元、設計單元、開發單元、測試單元，甚至部署單元
3. 用例的粒度（如何細分/尺度的確定）
- 業務建模階段：一個用例可以描述一項完整的業務流程（這有助於明確需求范圍）
- 概念建模階段：一個用例能描述一個完整的事件流（一項完整業務中的一個步驟）
- 系統建模階段：一個用例能描述操作者與計算機的一次交互
總結：粒度選擇問題本質上由邊界的認定不同而產生，原則是在同一個需求階段，所有用例的粒度應該是同一個量級的。
4. 用例的獲得
用例的定義就是：由參與者（actor）驅動的，並給其提供可觀測的有意義的結果的一系列活動的集合。
所以用例的來源就是：參與者（actor）對系統的期望。
所以發現用例的前提條件就是：發現參與者；而確定參與者的同時就確定了系統邊界。
接下來通過以下問題引導業務代表，並從訪談結果中找出用例：
- 您對系統有什么期望？（一件可以做的事，而不僅僅是一個主觀願望）
- 您打算在這個系統里做些什么事情？
- 您做這件事的目的是什么？
- 您做完這件事希望有一個什么樣的結果？
應當確保： - 一個明確的有效目標才是一個用例的來源
- 一個真實的目標應當完備地表達主角的期望
- 一個有效的目標應當在系統邊界內，由主角發動，並具有明確的后果
如果發現有些業務總是說不清，應當考慮重新進行訪談，並考慮以下策略： - 調整系統邊界和主角
- 擴大或縮小系統邊界
- 變更主角
- 然后重新開始
5. 用例的實現
完整叫法是系統用例的實現，不過系統二字可以省略。用例實現是連接用例模型和系統實現之間的橋梁，也是實現對象追溯到需求的一個重要環節。