“UML應用實作細節”（by Think, UMLChina）複習筆記(4)——通過用例組織需求

 通過用例組織需求
 首先，最最重要的是，我們必須有一份願景：一家企業的願景就是里程碑似的戰略目標（Microsoft：讓每個桌面都有一臺電腦），同樣，開發一個軟件系統的願景也是它的戰略目標。識別願景的時候，可以問3個問題：
 1.爲什麼要開發這個系統
 2.誰出錢買這個系統
 3.怎樣纔會覺得值
 這些問題不但要提給自己，更要以各種方式提給客戶，來求證他們心目中期待的軟件給他們帶來的價值。這並不意味着客戶說什麼是什麼，他們嘴裏說的和潛意識中期望的往往並不一樣。比如提出要把信息電子化的人，真正想要的可能是快捷的查詢和可靠的保存。因此不要讓虛假的願景矇蔽了，注意，真正的願景目標必須是可度量的（否則以後怎麼判斷是否達到了這個目標？）
 確立了願景之後，我們就可以着手識別和組織需求了。用例是一種有效的表達需求的手段，它幫助甚至是”強迫“我們從用戶的視角來思考問題，使需求真正體現對用戶的價值。用例本身提供了形式化的表示規範，這個規範體現了需求的組織層次：
 
 在這種形式下，所有的需求都是圍繞用例來組織的。
 
 
 通過用例組織需求可以分爲以下幾個步驟：
 1.識別執行者：這一步的關鍵在於確認”邊界“——執行者一定要在邊界之外，並且這個邊界是從責任上劃分的，不是從物理上劃分的；另外要注意的一點就是要避免“不甘心”心理——由於執行者直接與系統交互，他們往往是一些打工者，或者代辦人，例如銀行的職員，而直接顧客或者老闆卻不是執行者（注意這裏與業務建模時的區別），這是正常現象。
 2.識別用例：這一步的關鍵是“價值”——已經反覆強調過了，只有爲執行者提供了完整的價值動作，才能提取爲用例；而且，這一價值必須是由軟件系統提供的，而不僅僅是用戶要求的。識別用例常犯的錯誤是把操作步驟當用例，特別是把“增刪改查”操作統統當成用例來看，事實上，這些CRUD操作很有可能不足以構成用例（不足以向執行者提供價值），即使能構成用例，用一個“管理××”的用例來表示也足夠了。
 3.書寫用例文檔：用例文檔不等於用例圖，用例圖只是總的組織結構。一份標準的用例文檔應當包含以下內容：
  
  描述用例時要考慮到涉衆利益，並且需要平衡涉衆利益。經典定義：“Cockburn：用例是涉衆之間達成的契約，以執行者爲達成特定目標和系統交互的方式演繹“—— 這句寫得實在太精彩了！
“ 4.通過關係整理用例：特別注意不要濫用用例之間的關係，越簡單易理解越好。
 5.用例的排序和分包：通過對用例進行排序，可以確定以後迭代開發的次序