在介始用例方法之前，我們首先來看一下傳統的需求表述方式-"軟件需求規約"(Software Requirement Specification)。傳統的軟件需求規約基本上采用的是功能分解的方式來描述系統功能，在這種表述方式中，系統功能被分解到各個系統功能模塊中，我們通過描述細分的系統模塊的功能來達到描述整個系統功能的目的。一個典型的軟件需求規約可能具有以下形式：
采用這種方法來描述系統需求，非常容易混淆需求和設計的界限，這樣的表述實際上已經包含了部分的設計在內。由此常常導致這樣的迷惑：系統需求應該詳細到何種程度？一個極端就是需求可以詳細到概要設計，因為這樣的需求表述既包含了外部需求也包含了內部設計。在有些公司的開發流程中，這種需求被稱為"內部需求"，而對應于用戶的原始要求則被稱之為"外部需求"。
功能分解方法的另一個缺點是這種方法分割了各項系統功能的應用環境，從各項功能項入手，你很難了解到這些功能項是如何相互關聯來實現一個完成的系統服務的。所以在傳統的SRS文檔中，我們往往需要另外一些章節來描述系統的整體結構及各部分之間的相互關聯，這些內容使得SRS需求更象是一個設計文檔。
1.1 參與者和用例
從用戶的角度來看，他們并不想了解系統的內部結構和設計，他們所關心的是系統所能提供的服務，也就是被開發出來的系統將是如何被使用的，這就用例方法的基本思想。用例模型主要由以下模型元素構成：
- 參與者(Actor)
參與者是指存在于被定義系統外部并與該系統發生交互的人或其他系統，他們代表的是系統的使用者或使用環境。 - 用例(Use Case)
用例用于表示系統所提供的服務，它定義了系統是如何被參與者所使用的，它描述的是參與者為了使用系統所提供的某一完整功能而與系統之間發生的一段對話。 - 通訊關聯(Communication Association)
通訊關聯用于表示參與者和用例之間的對應關系，它表示參與者使用了系統中的哪些服務（用例），或者說系統所提供的服務（用例）是被哪些參與者所使用的。
這大三種模型元素在UML中的表述如下圖所示。
以銀行自動提款機(ATM)為例，它的主要功能可以由下面的用例圖來表示。ATM的主要使用者是銀行客戶，客戶主要使用自動提款機來進行銀行帳戶的查詢、提款和轉帳交易。
通訊關聯表示的是參與者和用例之間的關系，箭頭表示在這一關系中哪一方是對話的主動發起者，箭頭所指方是對話的被動接受者；如果你不想強調對話中的主動與被動關系，可以使用不帶箭頭的關聯實線。在參與者和用例之間的信息流不是由通訊關聯來表示的，該信息流是缺省存在的（用例本身描述的就是參與者和系統之間的對話），并且信息流向是雙向的，它與通訊關聯箭頭所指的方向亳無關系。
1.2 用例的內容
用例圖使我們對系統的功能有了一個整體的認知，我們可以知道有哪些參與者會與系統發生交互，每一個參與者需要系統為它提供什么樣的服務。用例描述的是參與者與系統之間的對話，但是這個對話的細節并沒有在用例圖中表述出來，針對每一個用例我們可以用事件流來描述這一對話的細節內容。如在ATM系統中的"提款"用例可以用事件流表述如下：
提款-基本事件流
1. 用戶插入信用卡
2. 輸入密碼
3. 輸入提款金額
4. 提取現金
5. 退出系統，取回信用卡
但是這只描述了提款用例中最順利的一種情況，作為一個實用的系統，我們還必須考慮可能發生的各種其他情況，如信用卡無效、輸入密碼錯、用戶帳號中的現金余額不夠等，所有這些可能發生的各種情況（包括正常的和異常的）被稱之為用例的場景(Scenario)，場景也被稱作是用例的實例(Instance)。在用例的各種場景中，最常見的場景是用基本流(Basic Flow)來描述的，其他的場景則是用備選流(Alternative Flow)來描述。對于ATM系統中的"提款"用例，我們可以得到如下一些備選流：
提款-備選事件流
備選流一：用戶可以在基本流中的任何一步選擇退出，轉至基本流步驟5。
備選流二：在基本流步驟1中，用戶插入無效信用卡，系統顯示錯誤并退出信用卡，用例結束。
備選流三：在基本流步驟２中，用戶輸入錯誤密碼，系統顯示錯誤并提示用戶重新輸入密碼，重新回到基本流步驟2；三次輸入密碼錯誤后，信用卡被系統沒收，用例結束。
…
通過基本流與備選流的組合，就可以將用例所有可能發生的各種場景全部描述清楚。我們在描述用例的事件流的時候，就是要盡可能地將所有可能的場景都描述出來，以保證需求的完備性。
1.3 用例方法的優點
用例方法完全是站在用戶的角度上（從系統的外部）來描述系統的功能的。在用例方法中，我們把被定義系統看作是一個黑箱，我們并不關心系統內部是如何完成它所提供的功能的。用例方法首先描述了被定義系統有哪些外部使用者（抽象成為Actor），這些使用者與被定義系統發生交互；針對每一參與者，用例方法又描述了系統為這些參與者提供了什么樣的服務（抽象成為Use Case），或者說系統是如何被這些參與者使用的。所以從用例圖中，我們可以得到對于被定義系統的一個總體印象。
與傳統的功能分解方式相比，用例方法完全是從外部來定義系統的功能，它把需求與設計完全分離開來。在面向對象的分析設計方法中，用例模型主要用于表述系統的功能性需求，系統的設計主要由對象模型來記錄表述。另外，用例定義了系統功能的使用環境與上下文，每一個用例描述的是一個完整的系統服務。用例方法比傳統的SRS更易于被用戶所理解，它可以作為開發人員和用戶之間針對系統需求進行溝通的一個有效手段。
在RUP中，用例被作為整個軟件開發流程的基礎，很多類型的開發活動都把用例作為一個主要的輸入工件(Artifact)，如項目管理、分析設計、測試等。根據用例來對目標系統進行測試，可以根據用例中所描述的環境和上下文來完整地測試一個系統服務，可以根據用例的各個場景(Scenario)來設計測試用例，完全地測試用例的各種場景可以保證測試的完備性。
2. 建立用例模型
使用用例的方法來描述系統的功能需求的過程就是用例建模，用例模型主要包括以下兩部分內容：
- 用例圖(Use Case Diagram)
確定系統中所包含的參與者、用例和兩者之間的對應關系，用例圖描述的是關于系統功能的一個概述。 - 用例規約(Use Case Specification)
針對每一個用例都應該有一個用例規約文檔與之相對應，該文檔描述用例的細節內容。
在用例建模的過程中，我們建議的步聚是先找出參與者，再根據參與者確定每個參與者相關的用例，最后再細化每一個用例的用例規約。
2.1 尋找參與者
所謂的參與者是指所有存在于系統外部并與系統進行交互的人或其他系統。通俗地講，參與者就是我們所要定義系統的使用者。尋找參與者可以從以下問題入手：
- 系統開發完成之后，有哪些人會使用這個系統？
- 系統需要從哪些人或其他系統中獲得數據？
- 系統會為哪些人或其他系統提供數據？
- 系統會與哪些其他系統相關聯？
- 系統是由誰來維護和管理的？
這些問題有助于我們抽象出系統的參與者。對于ATM機的例子，回答這些問題可以使我們找到更多的參與者：操作員負責維護和管理ATM機系統、ATM機也需要與后臺服務器進行通訊以獲得有關用戶帳號的相關信息。
 |
2.1.1 系統邊界決定了參與者
參與者是由系統的邊界所決定的，如果我們所要定義的系統邊界僅限于ATM機本身，那么后臺服務器就是一個外部的系統，可以抽象為一個參與者。
 |
如果我們所要定義的系統邊界擴大至整個銀行系統，ATM機和后臺服務器都是整個銀行系統的一部分，這時候后臺服務器就不再被抽象成為一個參與者。
 |
值得注意的是，用例建模時不要將一些系統的組成結構作為參與者來進行抽象，如在ATM機系統中，打印機只是系統的一個組成部分，不應將它抽象成一個獨立的參與者；在一個MIS管理系統中，數據庫系統往往只作為系統的一個組成部分，一般不將其單獨抽象成一個參與者。
2.1.2 特殊的參與者――系統時鐘
有時候我們需要在系統內部定時地執行一些操作，如檢測系統資源使用情況、定期地生成統計報表等等。從表面上看，這些操作并不是由外部的人或系統觸發的，應該怎樣用用例方法來表述這一類功能需求呢？對于這種情況，我們可以抽象出一個系統時鐘或定時器參與者，利用該參與者來觸發這一類定時操作。從邏輯上，這一參與者應該被理解成是系統外部的，由它來觸發系統所提供的用例對話。
 |
2.2 確定用例
找到參與者之后，我們就可以根據參與者來確定系統的用例，主要是看各參與者需要系統提供什么樣的服務，或者說參與者是如何使用系統的。尋找用例可以從以下問題入手（針對每一個參與者）：
- 參與者為什么要使用該系統？
- 參與者是否會在系統中創建、修改、刪除、訪問、存儲數據？如果是的話，參與者又是如何來完成這些操作的？
- 參與者是否會將外部的某些事件通知給該系統？
- 系統是否會將內部的某些事件通知該參與者？
綜合以上所述，ATM系統的用例圖可表示如下，
 |
在用例的抽取過程中，必須注意：用例必須是由某一個主角觸發而產生的活動，即每個用例至少應該涉及一個主角。如果存在與主角不進行交互的用例，就可以考慮將其并入其他用例；或者是檢查該用例相對應的參與者是否被遺漏，如果是，則補上該參與者。反之，每個參與者也必須至少涉及到一個用例，如果發現有不與任何用例相關聯的參與者存在，就應該考慮該參與者是如何與系統發生對話的，或者由參與者確定一個新的用例，或者該參與者是一個多余的模型元素，應該將其刪除。
可視化建模的主要目的之一就是要增強團隊的溝通，用例模型必須是易于理解的。用例建模往往是一個團隊開發的過程，系統分析員在建模過程中必須注意參與者和用例的名稱應該符合一定的命名約定，這樣整個用例模型才能夠符合一定的風格。如參與者的名稱一般都是名詞，用例名稱一般都是動賓詞組等。
對于同一個系統，不同的人對于 參與者和用例都可能有不同的抽象結果，因而得到不同的用例模型。我們需要在多個用例模型方案中選擇一種"最佳"（或"較佳"）的結果，一個好的用例模型應該能夠容易被不同的涉眾所理解，并且不同的涉眾對于同一用例模型的理解應該是一致的。
文章來源于領測軟件測試網 http://www.kjueaiud.com/