一、需求分析與用例：
需求：就是系統必須提供的能力和必須遵從的條件，包括：功能需求和非功能的需求（性能要求）。
需求分析：重要手段是確定和編寫用例。
用例：是文本形式的情節描述，用於需求的發現和記錄。用例會影響后續的OOA/D工作。
- 參與者（Actor）：某些具有行為的事物，可以是人（由角色標識）、計算機系統或組織，例如收銀員。
- 場景（Scenario）：是參與者和系統（我們要開發的系統）之間的一系列特定的活動和交互。包括主成功場景和交替場景（主成功場景表示正常功能….；交替場景是如果….）
- 系統邊界：
二、用例的目的與形式：
用例編寫的形式：
- 摘要—需求分析早期使用，通常用於主成功場景（如上方描述的“管理員向系統提交用戶名和密碼。系統進行認證。系統向管理員顯示功能登錄信息”）
- 非正式—需求分析早期使用，可覆蓋不同的場景
- 詳述—詳細編寫所有步驟及各種變化（見用例文檔）
Tip1:用命的名稱應使用動詞開頭（動詞或動詞+名詞）
Tip2:編寫用命的時候應盡量使用行業的專業名稱，而不是計算機專業術語。因為用例是跟用戶溝通的重要文檔，所以從用戶的觀點編寫用例。
三、用例編寫的格式：
- 用例編號
- 用命名
- 用命描述
- 參與者
- 前置條件 //必須滿足條件
- 后置條件 //用例做完后，對系統的影響
- 基本路徑 //最重要，主功能場景，只描述正常成功的場景，不要出現如果….;參與者動作，系統響應
- 擴展點 //最重要，
- 補充說明 //對基本路徑和擴展點的未盡事宜進行描述
四、如何發現用例：
- 選擇系統邊界
- 確定主要參與者
- 確定每個主要參與者的目標
- 定義滿足用戶目標的用例，根據其目標對用例命名
Tip：在真實項目中發現用例，請遵循如下思維習慣：調研需求時最先弄清楚有多少部門，多少崗位（參與者），然后找到每一個崗位的業務代表，問他們類似的問題：你平時都做什么？（參與者目標）這件事是誰交辦的 ？做完了你需要通知或傳達給認證嗎？做這件事情你都需要填寫些什么表格嗎？
五、用例關聯及一些術語
用例彼此之間可能具有聯系，比如：處理信用卡支付用例可傾向於為處理銷售、處理租金等常見用例的一部分。
注意：別花過多時間爭論在用例圖中如何關聯用例，而不關注更重要的工作：編寫用例文本
- 包含關系：主要目的是避免用例文本的重復編寫，比如：處理銷售、處理租金用例可包含處理信用卡支付用命。
- 擴展關系：可以將可選路徑中的場景抽象為擴展關系（但通常都是不必要的）
- 泛化關系：兩個或更多用例在行為、結構、目的等方面存在共性時，可使用泛化關系。
