下面是用例规格说明模板，包括了用例的原始特性。本文档可以用文字处理系统、需求管理工具或者其他建档工具创建。用例图表可以用视觉模型或制图工具来开发。
修订记录 | | | |
日期 | 修改 | 描述 | 作者 |
月/日/年 | x.x | 细节 | 作者名 |
| | | |
| | | |
| | | |
注意：修订记录可由需求管理或配置管理工具提供。
通常，用例的长度都不需要目录。但如果该用里带来规格说明查找的问题，则也可以使用目录。
用例名
简明描述
用例的作用和目的，对此描述一行就够了。
系统或子系统
给出用例应用的系统或子系统的名称。
事件流程
基本流程
当主角做某些事时用例开始，主角总是启动用例。用例描述主角做什么以及系统所做的响应。采用主角与系统之间的对话的方式描述用例。
用例描述系统内部发生的事情，但不描述原因和方式。如果有信息交换，要关注传递的是什么。例如，说主角输入客户信息不太准确，最好说主角输入客户的名字和地址。词汇表有助于把复杂度控制在可管理的范围内；你可能需要在其他地方定义客户信息，避免在用例中涉及过细的内容。
简单的替换可以在用例的文本中出现，如果只是几行就足以描述存在替换时所发生的事情，就直接在事件流部分完成。如果替换流程比较复杂，可以用一个单独的部分。例如，一个替换流程描述另一个更复杂的替换流程。
有时候一幅图胜过一千句话，尽管清楚明了的行文是无法替代的。如果用图可以提高清晰程度，可以在用例中随意增加对用户接口、过程流及其他的图形描述。如果技术性方法（如活动图等）有助于表示一个复杂的决策过程，那么尽量使用它们！类似地，对于状态相关行为来说，状态转移图往往比一页页的文字效果更好。对每个问题都选择最正确的表示介质，但注意使用观众能够理解的术语、表示或图表。记住，目的是使问题更明了，而不是更模糊。
替换流程
1.第一替换流程：更复杂的替换流程应该在一个单独的部分描述，我们称之为基本流程部分。把替换流程看成是一种替换行为；每个替换流程都代表一个替换行为（许多次，因为预期会在主流程中发生）。为了描述与替换行为相关的事件，替换流程的长度可以任意。当一个替换流程结束时，则恢复主事件流，除非有其他说明。
替换流程也可以分成几个部分。
2.第二替换流程：一个用例中可以有而且很可能有多个替换流程。为了名了，保持各个替
换流程的独立。利用替换流程来提高用户的可读性，避免把一个用例分解成用例层。记住，用例只是文字描述，它们主要目的是以清楚、准确、可理解的方式为系统行为建档。
特殊需求
特殊需求一般是一些非功能性需求，是用例专有的，但不太容易或不能直接在用例的事件流程中指定。这种特殊需求有法律和法规需求、应用程序标准以及要构建系统的质量属性（包括可用性、可靠性、性能和可支持性需求）。其他需求（如操作系统和环境、兼容性需求、设计约束等等）都应该在这一部分获取。
1. 特殊需求1
2. 特殊需求2
前置条件
用例的前置条件指在用例被执行之前系统必须处于的状态。
1. 前置条件1
2. 前置条件2
后置条件
用例的后置条件指在用例被执行之后可能处于的一组状态。
1. 后置条件1
2. 后置条件2
扩展点
扩展点被称为标记，用来参考用例的时间流程的位置或一组位置，并可在其间插入附加行为。
1. 扩展点1
2. 扩展点2
