1、需求分析本章內容UML用例圖用例描述的功能建模用例如何適用于業務建模 非功能性需求及其記錄方式如何描述用例業務環境是生成用例的一個前提用例適合業務的過程，找到用例的最好方法是理解這些業務過程。同時，也應考慮那些非功能需求，它們也是系統設計的一個重要方面需求分析需求分析階段，系統的外部行為得到初始定義，并鏈接到業務環境中，這是開發團隊與項目相關者之的合同。合同的意思并不是簽名公證過的書面文檔，而是開發過程中各個部門間達成的共識需求分析需求分析需求分析的重點：用例用例：是與計算機系統的一次”有意義的交互”。如果你有網 上購物的經歷，用例的一個例子就是從在線目錄中選抒一些商品另一個例子則是支付貨款關

2、于用例的大小和范圍存在多種爭議。本書中用例的意思是一個能夠自我獨立、并可以在與計算機系統的一次會話中完成的事務 。與計算機系統的一次 會話可能激活大量用例其中有 些互相關聯。用例與開發用例的概念是許多主流開發方法的核心標識用例確定它們與外部的交互設計一組對象來實現這個用例系統分析與設計成為“細化用例的過程”進一步改善用例，以使計算機編程人員來實現程序用例分析用例建模是需求定義與系統分析的核心在高層次 上，一組用例圖定義了系統描述，這是與系統的項目相關者（如用戶和發起人）進行討論的極好工具。在更為具體的層次上，可以使用用例對系統外部功能進行全而詳細的說明。并且用例將成為從事系統構建的設計人員，構

3、架和開發的起點用例分析用例圖指出系統做什么，用例細節分析講述“系統在某一環境中是怎樣運轉的”。它并不講述系統內部是“怎樣”構架來提供該行為的。在計算機系統開發中 ,這一分離經常被強調在確定系統如何運轉之前，需要先確定它做 什么9.1 UML用例模型活動者：使用計算機系統的人或者事物用例：計算機提供的有意義的功能塊關系：活動者與用例之 間存在鏈接。活動者使用用例，用例也可以使用其他用例；9.1 UML用例模型箭頭：表示發起對話，不表示信息的交流方向，可能存在雙向的信息流動包含與擴展一個用例可以使用另一個用例。如果有定義好的功能塊，在任何可能的情況下使用這個功能塊是有意義的。用例有兩種關聯方式。第

4、一種是一個用例“包含”另一個用例。這種情況下，第二個用例總是作為第一個用例的一部分被喚醒比如：訂貨用例中的信用檢查包含與擴展有時，一個用例只是偶爾被另一個用例調用。從用例的劇本分析中可以看出，這種關聯通常支持替代路線和異常。用一個指向相反的箭頭來表示這種關聯包含與擴展分析的第一階段是映射業務，使用：高層的過程圖，將一項業務分解成簡單的業務過程層次結構業務過程的劇本分析，使用主要路線與替代路線分析從劇本分析中得出的業務過程 工作流的構建，用 UML 活動圖描述。911尋找用例911尋找用例一旦業務過程完全定義好了，就要遍歷主要路線、替代路線以及異常的所有步驟：此時，會詢問一個簡單的問題：“此處是

5、否有計算機系統的潛在應用？” ，有時，業務過程的某項活功中可能不需要系統支持；有時，可能只需要一個用例；而有時，特定的業務活動需要多個用例。一個分析方法：從業務場所出發，較為具體地描述業務。然后，應該開始考慮計算機系統將用在何處。首先要考慮的是系統做什么，以及它怎樣適合 業務，而不是系統在具體技術是如何實現業務的用例細節分析現在，我們知道系統給各種各樣的用戶（或活動者）帶來了什 么，并且需要極其精確地定義交互是“如何”進行的。用例被定義為行為的細節序列。與展開一項業務過程完全相同的方法可以用來細化用例，把序列組織成主要路線和替代路線。客服中心為客戶更正帳單問題的主要路線為：用例細節分析1 輸入

6、顧客號 2 顯示顧客詳細信息（姓名、地址等） 3 核實顧客密碼并點擊“生效”鍵 4 查詢顧客的最后賬單 5 滾動至顧客正在詢問的項 6 代理決定支付貸款，所以按“信用顧客”鍵 7 輸入貸款金額 8 點擊“確認”鍵用例細節分析7 . 1 貸款金額超出代理的允許限度，故：7 . 1 . 1 顯示請求經理授權碼的界面 7 . 1 . 2 代理呼叫經理7 . 1 . 3 經理輸入授權碼 7 . 1 . 4 授權碼被接受，繼續 8用例描述格式需求分析的輸出目標分析項目相關者分析業務過程圖業務領域詳細的劇本分析描述業務過程的活動圖一組頂層用例圖 一組詳細的用例描述一組用戶接口原型化學制品案例電話訂貨過程用例選擇用例圖用例描述驗證顧客用例描述訂單細節ICANDO零售汽油銷售過程目標在促銷計劃里注冊一個客戶。提供給顧客一張卡和一個歡迎包。必要的前置條件無。過程緊急程度對于聲譽而言，這一過程的可靠運行十分重要。然