�。�1）是否您已找到所有的參與者？也就是說，是否您已經對系統環境中的所有參與者都進行了說明和建模？
�。�2）每個參與者是否至少涉及到一個用例？
�。�3）您能否列出至少兩名可以作為特定參與者的人員？
�。�4）是否有參與者擔任與系統相關的相似參與者？如果有，您應該將他們合并到一個參與者中。
用例檢查的參考標準如下：
�。�1）用例模型的簡介部分簡明清晰地概述此系統的目的和功能；
�。�2）所有的用例已確定，這些用例共同說明所有的必要行為；
�。�3）所有的功能性需求都至少映射到一個用例；
�。�4）該用例模型不包含多余的行為，所有的用例都可回溯到某個功能性需求來證明其合理性。
用例圖從總體上大致描述了系統所能提供的各種服務，讓我們對于系統的功能有一個總體的認識，僅此還是不夠的，我們還需要描述每一個用例的詳細信息，即用例規約。用例模型正是由用例圖和每一個用例的詳細描述――用例規約所組成的。RUP中提供了用例規約的模板，包含以下內容：
�。�1）簡要說明 (Brief Description)：簡要介紹該用例的作用和目的；
�。�2）事件流 (Flow of Event)：包括基本流和備選流，事件流應該表示出所有的場景；
�。�3）用例場景 (Use-Case Scenario) ：包括成功場景和失敗場景，場景主要是由基本流和備選流組合而成的；
�。�4）特殊需求 (Special Requirement)：描述與該用例相關的非功能性需求（包括性能、可靠性、可用性和可擴展性等）和設計約束（所使用的操作系統、開發工具等）；
�。�5）前置條件 (Pre-Condition)：執行用例之前系統必須所處的狀態；
�。�6）后置條件 (Post-Condition)：用例執行完畢后系統可能處于的一組狀態。
用例規約基本上是用文本方式來表述的，為了更加清晰地描述事件流，也可以選擇使用狀態圖、活動圖或序列圖來輔助說明（狀態圖有助于描述與狀態相關的系統行為，活動圖有助于描述復雜的決策流程，序列圖適合于描述基于時間順序的消息傳遞）。另外，只要對簡潔明了地表達用例有幫助，我們就可以在用例中任意粘貼用戶界面、流程的圖形化顯示方式及其他圖形。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
