描述用例規約
應該避免這樣一種誤解――認為由參與者和用例構成的用例圖就是用例模型，用例圖只是在總體上大致描述了系統所能提供的各種服務，讓我們對於系統的功能有乙個總體的認識。除此之外，我們還需要描述每乙個有例的詳細資訊，這些資訊包含在用例規約中，用例模型是由用例圖和每乙個用例的詳細描述――用例規約所組成的。rup中提供了用例規約的模板，每乙個用例的用例規約都應該包含以下內容：
簡要說明 (brief description)
簡要介紹該用例的作用和目的。
事件流 (flow of event)
包括基本流和備選流，事件流應該表示出所有的場景。
用例場景 (use-case scenario)
包括成功場景和失敗場景，場景主要是由基本流和備選流組合而成的。
特殊需求 (special requirement)
描述與該用例相關的非功能性需求（包括效能、可靠性、可用性和可擴充套件性等）和設計約束（所使用的作業系統、開發工具等）。
前置條件 (pre-condition)
執行用例之前系統必須所處的狀態。
後置條件 (post-condition)
用例執行完畢後系統可能處於的一組狀態。
用例規約基本上是用文字方式來表述的，為了更加清晰地描述事件流，也可以選擇使用狀態圖、活**或序列圖來輔助說明。只要有助於表達的簡潔明瞭，就可以在用例中任意貼上使用者介面和流程的圖形化顯示方式，或是其他圖形。如活**有助於描述複雜的決策流程，狀態轉移圖有助於描述與狀態相關的系統行為，序列圖適合於描述基於時間順序的訊息傳遞。
基本流
基本流描述的是該用例最正常的一種場景，在基本流中系統執行一系列活動步驟來響應參與者提出的服務請求。我們建議用以下格式來描述基本流：
1) 每乙個步驟都需要用數字編號以清楚地標明步驟的先後順序。
2) 用一句簡短的標題來概括每一步驟的主要內容，這樣閱讀者可以通過瀏覽標題來快速地了解用例的主要步驟。在用例建模的早期，我們也只需要描述到事件流步驟標題這一層，以免過早地陷入到用例描述的細節中去。
3) 當整個用例模型基本穩定之後，我們再針對每一步驟詳細描述參與者和系統之間所發生的互動。建議採用雙向(roundtrip)描述法來保證描述的完整性，即每一步驟都需要從正反兩個方面來描述:(1)參與者向系統提交了什麼資訊；(2)對此系統有什麼樣的響應。具體例子請參見附錄。
在描述參與者和系統之間的資訊交換時，需指出來回傳遞的具體資訊。例如，只表述參與者輸入了客戶資訊就不夠明確，最好明確地說參與者輸入了客戶姓名和位址。通常可以利用詞彙表讓用例的複雜性保持在可控範圍內，可以在詞彙表中定義客戶資訊等內容，使用例不至於陷入過多的細節。
備選流
備選流負責描述用例執行過程中異常的或偶爾發生的一些情況，備選流和基本流的組合應該能夠覆蓋該用例所有可能發生的場景。在描述備選流時，應該包括以下幾個要素：
1) 起點：該備選流從事件流的哪一步開始；
2) 條件：在什麼條件下會觸發該備選流；
3) 動作：系統在該備選流下會採取哪些動作；
4) 恢復：該備選流結束之後，該用例應如何繼續執行。
備選流的描述格式可以與基本流的格式一致，也需要編號並以標題概述其內容，編號前可以加以字母字首a(alternative)以示與基本流步驟相區別。
用例場景
用例在實際執行的時候會有很多的不同情況發生，稱之為用例場景；也可以說場景是用例的例項，我們在描述用例的時候要覆蓋所有的用例場景，否則就有可能導致需求的遺漏。在用例規約中，場景的描述可以由基本流和備選流的組合來表示。場景既可以幫助我們防止需求的遺漏，同時也可以對後續的開發工作起到很大的幫助：開發人員必須實現所有的場景、測試人員可以根據用例場景來設計測試用例。
特殊需求
特殊需求通常是非功能性需求，它為乙個用例所專有，但不適合在用例的事件流文字中進行說明。特殊需求的例子包括法律或法規方面的需求、應用程式標準和所構建系統的質量屬性（包括可用性、可靠性、效能或支援性需求等）。此外，其他一些設計約束，如作業系統及環境、相容性需求等，也可以在此節中記錄。
需要注意的是，這裡記錄的是專屬於該用例的特殊需求；對於一些全域性的非功能性需求和設計約束，它們並不是該用例所專有的，應把它們記錄在《補充規約》中。
前置和後置條件
前置條件是執行用例之前必須存在的系統狀態，後置條件是用例一執行完畢後系統可能處於的一組狀態。
檢查用例模型
用例模型完成之後，可以對用例模型進行檢查，看看是否有遺漏或錯誤之處。主要可以從以下幾個方面來進行檢查：
功能需求的完備性
現有的用例模型是否完整地描述了系統功能，這也是我們判斷用例建模工作是否結束的標誌。如果發現還有系統功能沒有被記錄在現有的用例模型中，那麼我們就需要抽象一些新的用例來記錄這些需求，或是將他們歸納在一些現有的用例之中。
模型是否易於理解
用例模型最大的優點就在於它應該易於被不同的涉眾所理解，因而用例建模最主要的指導原則就是它的可理解性。用例的粒度、個數以及模型元素之間的關係複雜程度都應該由該指導原則決定。
是否存在不一致性
系統的用例模型是由多個系統分析員協同完成的，模型本身也是由多個工件所組成的，所以我們要特別注意不同工件之前是否存在前後矛盾或衝突的地方，避免在模型內部產生不一致性。不一致性會直接影響到需求定義的準確性。
避免二義性語義
好的需求定義應該是無二義性的，即不同的人對於同一需求的理解應該是一致的。在用例規約的描述中，應該避免定義含義模糊的需求，即無二義性。
UML2用例描述以及需求用例規約文件生成
初學uml者，應該避免這樣一種誤解 認為就是由參與者和用例構成的用例圖就是用例模型，用例圖只是在總體上大致描述了系統所能提供的各種服務，讓我們對於系統的功能有乙個總體的認識。但用例圖並非如此，在用例圖中我們還需要針對每乙個用例描述它的詳細資訊，這些資訊包含在用例規約中，因此用例模型應該是由用例圖和每...
用例規約要細緻到萬無一失嗎？
在rup當中稱為用例示意板。在實際操作當中往往用介面原型進行描述，如您的產品以web為主，那麼使用靜態html配合用例規約就是比較適合的方法。在你所描述的情況當中，互動資訊 異常情況是應當盡量考慮清楚的，但是不論如何仔細，永遠都不可能做到事事具備。如果花費過於大的精力去描述用例的各個方面，把爭持認為...
需求用例分析之三 補充規約
補充規約在rup 中是記錄那些在用例模型的用例中不容易體現出來的系統需求。這些需求包括 補充規約是對用例模型的重要補充。補充規約和用例模型應該一起獲取對系統的一整套需求。通過以上文字可以知道，補充規約是全域性性的要求，與上述c文中的 全域性規則 極為接近。而中文中 補充規約 的說法讓不少人以為這是不...