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