用例

用例（英語：use case），或譯使用案例、用況，是軟件工程或系統工程中對系統如何反應外界請求的描述，每個用例提供了一個或多個場景，該場景說明了系統是如何和最終用戶或其它系統互動，也就是誰可以用系統做什麼，從而完成一個明確的業務目標。人們可以通過用戶的使用場景來進行需求分析。編寫用例時要避免使用技術術語，而應該用最終用戶或者領域專家的語言。用例一般是由軟件開發者和最終用戶共同創作的。

在1986年，Ivar Jacobson，UML和瑞理統一過程的重要貢獻者，提出了用例的概念。Jacobson的思想很有影響力，也很有發展力。之後在這個科目上又有很多貢獻，在定義用例是什麼和怎麼有效的書寫用例方面最重要，最有影響力也最全面的，是Alistair Cockburn，他寫的書籍是《編寫有效用例》。

用例迅速成為獲取功能需求最常用的手段。用例最初是和面向對象一同提出的。但是它不止局限於面向對象系統，因為用例實質上不是面向對象。

由於不少測試工程師將測試用例簡稱為用例，為便於區分兩者，將原來的Use case （頁面存檔備份，存於網際網路檔案館）用例稱為需求用例。

測試用例（對應英文Test case （頁面存檔備份，存於網際網路檔案館））已經廣為人知，沒有歧義，但就文字表面而言，測試用例類似是屬於用例，就像紅富士蘋果屬於蘋果一樣，所以為了更容易區分，需求用例是個更清晰的稱呼。

用例範圍和目標

每個用例集中描述如何獲得一個業務目標或任務。從傳統的軟件工程視角來看，用例只是描述了系統的一個特徵。所以對大部分軟件項目來說，這就意味着需要很多（有可能是數十個）用例來完整的描述新系統。一個特殊軟件項目的正規度和項目的不同階段將會影響每一用例需要的詳細程度。

一個用例定義了外部執行者和被考慮的系統之間的交互來實現一個業務目標。執行者是在系統外部和系統交互的人；一個執行者可以是一類用戶，用戶可以扮演的角色或者其它系統。

用例把系統看作"黑盒"，同系統的交互，包括系統的響應都是可以在系統外部感知的。它是一個deliberate policy，因為它簡化了需求的描 述，避免了對功能如何實現做出假設的陷阱。

用例應該：

• 描述了滿足業務目標的業務活動
• 沒有涉及特定的實現語言
• 要求合適的細節級別
• 足夠短，使得在一次發布中能夠被一個軟件開發人員實現

用例圖

主條目：用例圖

An UML Use case diagram

用例圖並不是畫成了圖形的用例。用例圖包含一組用例。每一用例用橢圓表示，放置在矩形框中；矩形框表示整個系統。矩形框外畫如圖所示的小人，表示參與者。參與者不一定是人，可以是其他軟件、硬件等等。某一參與者與某一用例用線連起來，表示該參與者和該用例有交互。

許多人通過UML認識了用例，UML定義為展現用例的圖形符號。UML並沒有為描述用例定義書寫格式的標準，因此許多人誤認為這些圖形符號就是用例本身；然而，圖形符號只能給出最簡單的一個或一組用例的概要。

UML是用例圖形符號最流行的標準。但是，還有一些其它的可選擇的標準。

書寫用例

細度

Alistair Cockburn在編寫有效用例一書中確定了三種書寫用例的細度。

摘要

摘要用例有很少的句子組成來總結的用例。它十分適合在電子表格中計劃軟件開發。一個摘要用例能夠簡單插入電子表格的單元格中並且用表格中的其它列記述業務優先級，技術複雜度，版本號等。

非正式

一個非正式的用例由文本段落組成，包括了上面提到的那些列，用總結或故事的形式詳細的描述了用例。

完整正式

一個完整正式或者複雜的用例是一個以包含了不同部分的長模板為基礎的正規的文檔。該用例在下面的用例模板部分進行討論。

適當使用

一些軟件開發方法學只需要非正式的用例來定義需求。然而，開發方法學需要完整正式或詳細的用例來定義需求。較大且較複雜的項目更需要使用完整正式的用例。

用例模板

編寫詳細的或完整的用例，尚無通用的模板（英語：template）。現在存在很多相互競爭的模板。同時，程序員們也被鼓勵用那些適合於他們的工作或者他們所做項目的模板，相對於某個指定模板的細節來說，項目的標準化要重要的多，但是這些模板的關鍵部分都是大體相同的，所以，雖然在某些術語上或者其他一些方面上存在不同，但是這些用例從本質上來說，是大同小異的。

典型部分包括：

• 用例名稱
• 角色
• 描述
• 前置條件
• 事件流
  • 基本流
  • 備選流
• 後置條件
• 擴展點
• 業務規則
• 特別要求
• 迭代

不同的模板經常有其它部分，如，假設，異常流，建議，技術要求。也會有行業細節部分。

用例名稱

用例名稱為用例提供了一個唯一標識。它要用動/賓格式書寫，並且要充分，達到最終用戶能夠明白用例中描述的是什麼。

迭代

迭代部分通常需要告知讀者用例完成的階段。最初，為業務分析和確定範圍的用例和用於軟件開發的用例肯定會有許多不同。老版本的用例可能還在當前文檔中，因為它們對不同的用戶群可能會有價值。

描述

描述部分用於在主體完成之前捕獲基本場景。它提供了快速的總結，避免了讀者瀏覽全部內容，能夠很快的理解該用例的用途。

前置條件

前置條件部分用來表達當用戶開始用例時某些條件必須為真。但是它們不是啟動用例的觸發器。

基本流

最低限度，每一個用例都需要描述一個主場景或者典型事件流。主事件流一般是一組有編號的步驟，如：

1. 系統提示用戶登錄。
2. 用戶輸入他的名字和密碼。
3. 系統驗證用戶信息。
4. 系統使該用戶登錄入系統

……其他

備選流

用例可能包含第二條路徑，或者和主題不同的備選場景。異常或當出錯時會發生什麼事情也需要描述出來，這種描述可以在備選路徑中或者在它本身的部分。備選路徑使用基本事件流中的序號來標示在哪一點上同基本場景不同，並且如果合適它從哪一點回到基本場景中。目的是避免不必要的重複信息。

備選流的例子：

1. 系統識別用戶機器上的cookie
2. 到步驟4（基本流）

異常路徑的例子：

1. 系統不能識別用戶登錄信息
2. 到步驟1（基本流）

後置條件

後置條件部分總結了在場景結束後事務的狀態。

業務規則

業務規則是一些成文的或未成文的規則，對於用例來說它決定了一個組織是如何執行業務的。業務規則是一個特殊種類的假定。它可能適用於某一個用例或者整個用例，甚至整個業務。

特別要求

說明對於本用例的非功能性要求，典型的是並發情況下的響應時間要求，還有易用性要求等等

用例的效益

用例是一個較新的，比較敏捷的捕獲軟件需求的形式。用例經常和大的，統一的文檔形成對比。這些大文檔想要在新系統開始構成前，完整的表達出所有可能的需求，但這種做法通常都是失敗的。

用例的幾點優勢：

• 用例已經證實更容易被業務用戶理解，因此它也是開發人員和最終用戶的很好的溝通橋梁。
• 用例對於確定範圍很有用。用例使分階段交付從而一步步完成項目變得容易；它們能夠在優先度變化時相對較容易的添加或從軟件項目移去。
• 用例可跟蹤。
• 用例能夠作為估計，制定進度和驗證成果的基礎。
• 用例防止了不成熟的設計。
• 用例不使用特定語言。
• 用例允許我們去講故事。能夠容易的採用將需求轉換為故事或場景這一具體的方法來描述用例。
• 用例在項目中可復用。用例在每一次迭代中都能進一步演化，用例可以用於捕獲需求，成為程序員的開發依據，發展為測試用例，到最後成為用戶手冊。
• 用例與用戶和系統交互相關。它們使軟件開發者在開發之前或當中就能夠開始用戶接口設計。
• 用例將需求置於上下文中，它們能夠清楚地描述業務活動間的關係。

用例的局限性

用例不是沒有局限性：

• 用例在捕獲系統功能需求上表現很優秀，但是它們並不適合方便的捕獲非功能性需求，需要其它的方法去捕獲非功能性需求。
• 用例模板不能自動保證清晰。清晰要依靠書寫者的技巧。
• 用例並不像支持者說的那樣易於理解。There is a learning curve involved in learning to interpret them correctly for end users and programmers alike.（如何正確地向最終用戶和程序員解釋這些用例是一個需要花費時間學習的事情。）
• 極限編程的說明者通常認為用例是沒用的文檔，他們更喜歡用較簡單的用戶故事這一方法。
• 可用性設計人員批評用例在開發過程中過早的引入了用戶接口設計。他們指出用例描述用戶和系統之間的交互，很顯然它和用戶接口設計重疊了。不好的用例描述將過細的，專斷的用戶接口設計包含於交互的描述中，即使用例的一個原則是不要加入實現的細節。

用例指南

• 用例 （頁面存檔備份，存於網際網路檔案館）