下面是用例規格說明模板，包括了用例的原始特性。本文檔可以用文字處理系統、需求管理工具或者其他建檔工具創建。用例圖表可以用視覺模型或制圖工具來開發。
修訂記錄 | | | |
日期 | 修改 | 描述 | 作者 |
月/日/年 | x.x | 細節 | 作者名 |
| | | |
| | | |
| | | |
注意：修訂記錄可由需求管理或配置管理工具提供。
通常，用例的長度都不需要目錄。但如果該用里帶來規格說明查找的問題，則也可以使用目錄。
用例名
簡明描述
用例的作用和目的，對此描述一行就夠了。
系統或子系統
給出用例應用的系統或子系統的名稱。
事件流程
基本流程
當主角做某些事時用例開始，主角總是啟動用例。用例描述主角做什么以及系統所做的響應。采用主角與系統之間的對話的方式描述用例。
用例描述系統內部發生的事情，但不描述原因和方式。如果有信息交換，要關注傳遞的是什么。例如，說主角輸入客戶信息不太準確，最好說主角輸入客戶的名字和地址。詞匯表有助于把復雜度控制在可管理的范圍內；你可能需要在其他地方定義客戶信息，避免在用例中涉及過細的內容。
簡單的替換可以在用例的文本中出現，如果只是幾行就足以描述存在替換時所發生的事情，就直接在事件流部分完成。如果替換流程比較復雜，可以用一個單獨的部分。例如，一個替換流程描述另一個更復雜的替換流程。
有時候一幅圖勝過一千句話，盡管清楚明了的行文是無法替代的。如果用圖可以提高清晰程度，可以在用例中隨意增加對用戶接口、過程流及其他的圖形描述。如果技術性方法（如活動圖等）有助于表示一個復雜的決策過程，那么盡量使用它們！類似地，對于狀態相關行為來說，狀態轉移圖往往比一頁頁的文字效果更好。對每個問題都選擇最正確的表示介質，但注意使用觀眾能夠理解的術語、表示或圖表。記住，目的是使問題更明了，而不是更模糊。
替換流程
1.第一替換流程：更復雜的替換流程應該在一個單獨的部分描述，我們稱之為基本流程部分。把替換流程看成是一種替換行為；每個替換流程都代表一個替換行為（許多次，因為預期會在主流程中發生）。為了描述與替換行為相關的事件，替換流程的長度可以任意。當一個替換流程結束時，則恢復主事件流，除非有其他說明。
替換流程也可以分成幾個部分。
2.第二替換流程：一個用例中可以有而且很可能有多個替換流程。為了名了，保持各個替
換流程的獨立。利用替換流程來提高用戶的可讀性，避免把一個用例分解成用例層。記住，用例只是文字描述，它們主要目的是以清楚、準確、可理解的方式為系統行為建檔。
特殊需求
特殊需求一般是一些非功能性需求，是用例專有的，但不太容易或不能直接在用例的事件流程中指定。這種特殊需求有法律和法規需求、應用程序標準以及要構建系統的質量屬性（包括可用性、可靠性、性能和可支持性需求）。其他需求（如操作系統和環境、兼容性需求、設計約束等等）都應該在這一部分獲取。
1. 特殊需求1
2. 特殊需求2
前置條件
用例的前置條件指在用例被執行之前系統必須處于的狀態。
1. 前置條件1
2. 前置條件2
后置條件
用例的后置條件指在用例被執行之后可能處于的一組狀態。
1. 后置條件1
2. 后置條件2
擴展點
擴展點被稱為標記，用來參考用例的時間流程的位置或一組位置，并可在其間插入附加行為。
1. 擴展點1
2. 擴展點2
