值得壹提的是，盡管RUP被視為重量級的軟件管理過程，但越來越多的軟件開發人員開始采用敏捷方法來應對不斷變化的需求。但是，作為壹種描述需求的方式，用例的概念和方法論仍然有助於我們分析需求。
從表達方式來看，用例比序列圖、流程圖等需求表達方式更面向對象、更面向設計。通常情況下，用例更容易被沒有經過專業訓練的人接受。用例可以作為向用戶或外部人員陳述需求的壹種方式。
用例是壹種描述需求的方法。用例描述了系統在不同條件下對參與者請求的響應。用例通常通過壹個參與者(誰？)向系統提出請求，系統根據參與者的請求(做什麽？)，在不同的條件下，執行壹定的行為序列(系統如何滿足？)。每個行為序列可以稱為壹個場景，壹個用例包含多個場景。壹個場景也可以被稱為壹個用例的實例。
正式用例應包括:用例名稱、概述、範圍、級別、主要參與者、項目相關人員和利益、前提條件、最低保證、成功保證、觸發事件、主要成功場景、擴展場景和相關信息等。
每個組件的含義如下:
用例可以用於不同的目的，例如:
不同的編寫目的導致用例的編寫過程中側重點不同。
不同團隊的情況也可能導致不同的用例。例如，在大型開發項目團隊中，需要嚴格按照用例實例進行描述，而在溝通頻繁的小型項目團隊中，可以采用相對簡單的描述方法。
上面提到的組件更常見。實際上，用例的格式並不是壹成不變的，必要時可以增加或減少其中的信息。具體用例中應該包含哪些信息？有不同的學校。有興趣的可以查壹下相關資料，這裏就不說了。
壹句話:妳的用例不是我的用例，只有合適的用例才是最好的。
這篇論文的主要觀點都來自於阿利斯泰爾·考克伯恩的《編寫有效的用例》。有興趣的可以看原文。
用例用於表達需求，但是有兩點需要註意:
用例名稱用於標識壹個用例，易於總結和閱讀。
規則:用主動語態的動賓短語來描述。
壹般情況下，建議使用主動語態的動賓短語來描述用例的目的。如:“查找商品”、“加入購物車”。在某些情況下，如果需要更準確地表達壹個用例，可以添加屬性對其進行修改，比如“用戶清空購物車”和“管理員清空購物車”。
規則:描述主要參與者。
用例的描述需要描述主要參與者，比如可以用“支付訂單”(針對主要參與者)，而不是“收取訂單費用”(針對系統)。
用例的範圍可以給我們壹個關於系統邊界和討論需求的基本背景。不同的設計範圍可能導致我們需要討論的不同參與者和場景。簡單來說，就是為我們討論的體系定義壹個範圍，確定我們討論的邊界。
例如，我們將討論壹個用戶的訂購行為。如果範圍是整個企業，項目的相關人員是用戶和第三方服務商(如快遞等。).但是，如果系統是範圍，項目相關人員還應包括系統管理員和企業內部的客戶服務人員。
所以在寫用例的時候，我們需要搞清楚我們用例的範圍是什麽，這樣才能對用例中討論的問題有* * *的認識。
在討論用例的設計範圍時，首先需要確定系統的功能範圍。考克伯恩推薦了壹個內部/外部列表來確定編寫有效用例的功能範圍。
確定功能範圍的好處是顯而易見的。比如系統外已經有壹個打印訂單系統。如果沒有明確區分系統的功能範圍，壹些開發人員可能會設計並實現打印訂單功能。其實這些功能都不需要設計。
定義功能範圍後，還可以確認系統的執行人。在上面的例子中，打印訂單系統將作為“打印訂單”用例的輔助執行者。
功能範圍確定後，設計範圍就完成了。設計範圍指的是我們在寫用例時討論的邊界和對象。我們在用例中所說的範圍是指設計範圍(不是功能範圍)，除非另有說明。
讓我們看壹個例子。ECom打算做壹個ESys系統，包括ESubSys等幾個子系統。
如果我們以ECom為設計範圍討論用例，我們關心的是用戶想從公司得到什麽，以及公司以什麽形式滿足用戶的要求。如果有外部公司，妳也要考慮外部公司之間的業務是什麽。
如果以ESys為設計範圍討論用例，我們更關心的是用戶對系統的請求以及系統對請求的響應。同時，如果以ESys為範圍，企業內部的員工也成為用例的執行者，我們也要考慮員工對系統的請求。
確定用例的範圍可以幫助我們知道我們要討論的問題是什麽，定義我們討論的範圍，給用例壹個語言環境。
規則:設計範圍是壹個簡單的專有名稱。
用例的範圍應該是簡單的專用名詞，並簡要說明用例討論的範圍邊界。比如上面例子中的範圍，可以直接用“ECom”、“ESys”、“ESubSys”來表示。
主執行人是系統相關人員中請求系統響應的人或事。主執行人是系統請求的發起者，但主執行人可能不是直接操作系統的相關人員。
在壹種情況下，主執行者通過另壹個系統操作者操作系統。例如，客戶打電話給客戶服務部門詢問異常訂單。客戶沒有直接通過系統查詢。
另壹種情況是在固定時間觸發任務。如果客戶希望系統定期執行壹項任務，那麽最終執行系統的相關人員就是系統本身。
雖然確定主執行人很重要，但有時候主執行人並沒有那麽重要。
寫用例的時候，確定主執行人，可以從執行人的角度充分梳理系統需求。我們還可以根據主執行者的特點來設計系統的交互。下表，主執行人匯總表:
在大多數情況下，在我們開始編寫用例之後，主執行者變得不那麽重要了。比如我們在設計查詢訂單的用例時，無論是管理員、經理、客服甚至其他公司崗位，查詢訂單的用例都沒有特別的區別。這個時候，主執行人是誰就不重要了。
規則:用例的主要執行者可以是執行者或者執行者角色。
在上述情況下，我們將概括壹些主要執行者，並創建壹個“角色-執行者對應表”。在上面的用例中，我們概括了管理員、經理等。變成壹個運營角色-訂單經理。當我們描述用例時，我們可以把角色作為主要執行者。
概述主要用於描述用例的目標，即用戶需要完成的目標。
規則:使用自然語言描述。
盡量用自然語言來解釋用戶想要完成目標時會怎麽做。
規則:描述用例實現了什麽，而不是系統步驟。
只要說清楚用例需要完成什麽就可以了，不需要描述系統步驟或者用戶的具體操作過程。
例如，“用戶選擇要購買的產品後，可以將該產品添加到購物車中，然後在購物車中提交訂單。用戶也可以不加入購物車，直接購買選中的商品。”概述不需要描述具體的系統操作，這裏也沒有“點擊按鈕加入購物車”等系統操作細節的描述。
項目相關人員是指在系統中有特定利益關系的參與者。相關人員不壹定是人，也可以是壹個外部系統、壹個組織等。
因此，有可能成為項目相關人員:
首席執行人
主要執行者是發起執行用例的相關人員。
輔助執行者
輔助執行器是為設計的系統執行服務的外部執行器。輔助執行者可以是另壹個系統或個人或組織。例如，打印機為系統打印各種賬單。再比如快遞公司，為系統提供快遞服務，提供物流信息。
內部執行者
內部執行者是體制內關註體制利益的相關人員。
設計系統
設計的系統本身有時對自己有特定的好處。
對於相關人員來說，有幾點需要說明:
規則:相關人員和利益以對應列表的形式寫入。
使用":& lt利益>”的方式來描述相關人員及其利益。
在編寫用例的過程中，我們有時會描述壹個用戶的需求(比如用戶購買商品)，有時會描述壹個系統的具體功能(比如用戶登錄)，有時會描述壹個過程(比如購買商品並獲得商品的過程)。在寫用例的時候，知道用例的位置，對我們寫和理解用例很有幫助。
我們將用例層次從總體到子層次分為三個層次:概要、用戶目標和子功能。
用戶目標是指主要執行者在使用系統時期望獲得的目標。用戶目標是我們用例編寫的重點。用戶目標描述了主要執行者通過系統“做”什麽，用戶做了之後能得到什麽好處。
用戶的目標應該是主執行者執行壹次從系統獲取利益的過程。所以，不是壹次執行就能達到的目標，或者用戶不能獲得利益的需求，不能稱為用戶目標。
比如購買壹件商品，從下單到快遞需要幾天的過程，就不能稱之為用戶目標。再比如，用戶登錄後得不到任何利益，所以不能稱為用戶目標。用戶下單的操作可以作為用戶目標。
摘要層次結構可以包含多個用戶目標，摘要目標的執行周期比用戶目標的執行周期長，可以是幾天、幾個月甚至更長的過程。概要目標有三個目的:
子功能層次是用戶的目標在執行過程中將達到的目標。例如，壹次登錄、壹次訂單打印等。也有可能多個用戶目標* * *使用壹個子功能，比如找商品、找訂單等。
子功能用例的存在是為了增加用戶目標用例的可讀性。在實際編寫過程中，除非萬不得已，不要設計子功能用例。
規則:層次結構中只有三個選項:摘要、用戶目標和子功能。
用例的級別只能是三個級別中的壹個:概要、用戶目標和子功能。
前提條件是在用例執行之前我們期望成功的條件。在編寫用例的過程中，可能不會檢查和討論這個條件。比如“下單”就必須依賴於“用戶已經登錄”這個前提條件。
規則:前提條件必須是在用例執行之前我們期望成功的條件。
要防止那些不必要的條件被寫進前置條件。例如，取消訂單並不取決於用戶訂單的成功與否。事實上，用戶可以取消不成功的訂單(如支付失敗)。需要在用例中檢查訂單是否成功的條件，並執行失敗的動作。
最低保證是保證用例執行無論成功與否都會被執行。雖然，不管用例執行成功與否，最低保證總會被執行。而最低保障更多的是在用例執行失敗時，提供給用例相關人員的利益保障。可以有多個最低保障。
最低保證的壹個常見例子是“系統將記錄用戶的執行”。即使用例執行失敗，用戶的操作也會被記錄在日誌中。
成功保障是指用例成功執行後，用戶能夠得到的利益保障。能否保證相關人員的利益是用例執行成功的判斷條件。可以有多個成功保證。
例如，在下訂單的用例中，用戶必須確保“訂單被創建並提交到後臺進行處理。”
觸發事件是指用例發起的事件，用例將通過觸發事件壹步步執行。
規則:觸發事件是與系統交互的第壹個操作。
以用戶下單的用例為例。用戶決定購買商品後，在系統中查找商品並下訂單。那麽“用戶決定購買商品”就不能作為用例的觸發事件。實際上，用戶更系統的交互是從“找貨”開始的，所以“用戶找貨”是用例的觸發事件。
當我們討論用戶與系統的交互時，我們還應該註意我們所討論的系統的範圍。特別是當主要執行人不是直接操作軟件系統時，應明確系統的範圍。比如“用戶打電話給客戶經理下單”的場景，我們的系統範圍就不能局限於軟件系統範圍，是系統範圍還是公司。所以“用戶調用客戶經理”是和我們系統交互的第壹步，所以可以是“觸發事件”。
主要的成功場景是用例從觸發事件開始，壹步壹步執行，最後滿足用例興趣的壹組步驟。
主要成功場景應包括以下信息:
實施這些步驟應該有壹些簡單的規則:
規則:使用簡單的語法。
使用簡單的語法結構:
例如:
規則:準確描述表演者之間的切換。
執行步驟需要準確描述步驟執行過程中執行者之間的切換。比如“用戶給客戶代表打電話”，我們就可以知道步驟已經從用戶切換到客戶代表了。
但有時在執行人明確的情況下，可能不會出現在句子中。比如“用戶輸入密碼”，我們也可以知道這壹步的執行人從用戶切換到了系統。我們不必使用“用戶將密碼輸入系統”這種多余的描述。
規則:從系統外部描述步驟。
不應該從系統內部考慮，或者全部從系統的角度考慮。相反，應該從系統外部描述這些步驟。
如果從系統內部描述步驟，可以寫成:
如果這些步驟是在系統之外描述的，它們被表達為:
規則:表明流程向前推進。
有些小步驟只能完成幾個任務，有時候這些任務並不能很好的描述前進的過程。例如，“用戶點擊了確定按鈕”。這壹步不能很好的描述前進的過程。用戶的真正目的是登錄系統。當用戶登錄到系統中時，用例步驟可以繼續執行。
規則:表現表演者的意圖，而不是動作。
執行者通常通過操作系統執行壹個動作，在描述用例時很容易將用戶的動作與執行者的意圖混淆。
例如:
1.系統要求用戶輸入身份信息。
2.用戶輸入用戶名和密碼。
3.用戶單擊“確定”按鈕
4.系統確認用戶身份信息。
……
太多的用例描述了系統的操作界面和用戶的動作，比如“要求用戶輸入身份信息”，這不僅是壹個交互動作，也是執行者的意圖。
我們可以減少描述用戶動作的步驟，並將示例改為:
規則:包含壹組合理的活動。
描述步驟時，沒有必要在每個步驟中都包含壹個活動。根據需要，可以將壹些活動組合成壹個步驟。
比如:
這個步驟也可以描述為兩個步驟:
用例的描述簡單有效，有時並不局限於特定的方式。事實上，很多開發團隊已經形成了自己的用例編寫規範。
規則:步驟描述的是成功的場景，而不是可能的失敗。
主成功場景中的步驟描述了成功的步驟。例如:
如果這樣寫步驟，我們會繼續考慮“如果判斷正確……”和“如果判斷失敗……”。但是，在主成功場景的步驟中，失敗的步驟沒有反映出來。因此，您需要將步驟更改為
系統驗證失敗怎麽辦？擴展中描述了這些信息。下面會詳細解釋，這裏就不展開了。
規則:當步驟不連續執行時，可以添加時間限制。
在大多數情況下，這些步驟是逐步進行的。在某種程度上，它可以描述如下:
規則:壹個步驟可以涉及多個相關人員。
我們有時需要啟動壹個從壹個系統到另壹個系統的執行動作，可以寫成:
規則:您可以重復執行壹個或多個步驟。
有時用戶會重復執行壹個或多個步驟，因此有必要對這些步驟進行壹定的描述。比如:
延伸是主成功場景的壹個分支，指的是主成功場景在壹些其他條件下將要完成的不同動作。請註意，用“擴展”代替“異常”或“錯誤”，其實擴展包括兩種可能的情況:成功和失敗。基本的邏輯是，如果系統...(檢測到事故)當執行主要成功場景時，然後...(做壹些事情)。
可能進行擴展的常見場景如下:
在這些場景出現後，我們應該描述這些場景在擴展中是如何處理的，然後返回到主成功場景或者退出用例。
擴展是針對主成功場景的，所以我們寫擴展的時候需要用數字來表示擴展的對應關系:
主要的成功場景如下:
展開如下:
如果是每壹步可能觸發的擴展，可以用“*”表示，比如:
或者如果某些步驟觸發* * *條件，妳可以添加步驟來表示，比如:
規則:從系統檢測的角度描述擴展條件。
擴展條件應該是系統可以檢測到的條件，而不是發生了什麽。比如用戶忘記密碼，系統是不可能檢測到用戶有密碼還是其他原因。從系統檢測的角度來說，系統只能檢測到用戶輸入了錯誤的密碼或者用戶輸入超時。
規則:合理化合並的擴張條件。
事實上，沒有必要列舉擴展條件的所有可能場景，在合理的範圍內，我們可以將壹些擴展條件組合成等價項。判斷等價有兩個標準:
比如密碼輸入這壹步，用戶可以忘記密碼輸入錯誤，或者手動輸入錯誤或者其他可能性，這些都是系統無法檢測到的情況。首先將這些條件轉化為系統可以測試的條件:密碼輸入不正確。轉換後，所有條件可以合並為壹個。
我們來看看系統可以完成的條件，比如密碼輸入錯誤、用戶名錯誤、用戶名不存在等。我們系統的處理是“提示用戶名或密碼錯誤或不存在”。這時妳可以把條件組合成“系統檢測到用戶名或密碼輸入錯誤”。
在另壹種情況下，如果擴展已經在低級用例(如子功能級)中得到充分描述，那麽在高級用例(如用戶目標級)中可以不重復多余的描述。例如，在子功能級用例“保存數據”中，保存過程中可能出現的各種擴展條件已經有了完整的描述，所以不必在其上級用例中描述。
-
用例也可以用用例圖來表示。本文主要通過用例的重點和用例的組成來討論壹個需求的描述，所以我就不介紹用例圖了。有興趣的讀者可以參考其他資料進行自己的理解。
在越來越推崇敏捷開發的今天，用例這種相對“重”的需求分析和表達模式，越來越少被使用。當我們研究用例的關註點和分析方法時，他們的很多思想在我們的日常需求分析中仍然可以借鑒。