用例说明模板1(经典模板)-read.docVIP

用例说明模板1 经典模板 编者说明： 随着UML的日益普及，用例（Use case）分析技术也在需求实践中广泛被采用。但是也有许多团队在使用该技术时，只画出了用例图，而缺少了用例说明，其实这是一个严重的误区。而本模板就将指导你编写该说明。 1.用例名称 1.1? 简要说明 [简要说明用例的作用和目的。该小节的篇幅不要太长。] 2.上下文图 [在此小节中，有一个只包括本用例和所有与该用例相关的Actor和其它用例组成的，一个用例图的局部。] 3.?事件流 3.1?基本流 [当Actor采取行动时，用例也就随即开始。用例总是由Actor启动的，用例应说明Actor的行为及系统的响应，可按照Actor与系统进行对话的形式来逐步引入用例。] [要注意的是，用例描述应该说明系统内发生的事情，而不是事件发生的方式与原因。如果进行了信息交换，则需指出来回传递的具体信息。例如，只表述主角输入了客户信息就不够明确。最好明确地说主角输入了客户姓名和地址。当然你也可以通过项目词汇表来定义这些信息，使得用例中的内容被简化，从而不致于让用例描述陷入过多的细节内容。] [如果存在一些相对比较简单的备选流，只需少数几句话就可以说明清楚，那么也可以直接在这一部分中描述。但是如果比较复杂，还是应该单独放在备选流小节中描述。] [一幅图胜过千言万语，因此建议在这一小节中，除了叙述性文字之外，你还可以引用UML中的活动图、顺序图、协作图、状态图等手段，对其进行补充说明。] 3.2??备选流 3.2.1??第一备选流 [正如前面所述，对于较复杂的备选流应单独地说明。] 3.2.1.1? 备选支流 [如果能使表达更明确，备选流又可再分为多个支流。] 3.2.2??第二备选流 [在一个用例中很可能会有多个备选流。为了使表达更清晰，应将各个备选流分开说明。使用备选流可以提高用例的可读性，并防止将用例分解为过多的层次。应切记，用例只是文本说明，其主要目的是以清晰、简洁、易于理解的方式记录系统的行为。] 4.??非功能需求 [在这个小节中，主要对该用例所涉及的非功能性需求进行描述。由于其通常很难以在事件流中进行表述，因此单列为一小节进行阐述。这些需求通过包括法律法规、应用程序标准、质量属性（可用性、可靠性、性能、支持性等）、兼容性、可移植性，以及设计约束等方面的需求。在这些需求的描述方面，一定要注意使其可度量、可验证，否则就容易流于形式，形同摆设。] 5. 前置条件 [用例的前置条件是执行用例之前必须存在的系统状态。] 6. 后置条件 [用例的后置条件是用例一执行完毕系统可能处于的一组状态。] 7.?扩展点 [此用例的扩展点，通常是用例图中的extent关系。] 用例说明模板2 单列表格式 编者说明： 如果你觉得文本描述不够清晰，也可以采用如本文档模板所示的表格式的描述方式。 用例# [用例名应是一个动词短语，应让读者一目了然地从名字中就可以知道该用例的目标。] 使用语境 [用例目标，是一个较长的描述，甚至包括触发条件。] 范围 [用例的设计范围，在设计时将系统作为一个黑盒来考虑。] 级别 [概要、用户目标、子功能三者之一。] 主执行者 [也就是该用例的主Actor，在此应列出其名称，并简要描述。] 项目相关人员利益 项目相关人员 利益 [项目相关人员名称] [项目相关人员取得的利益] …… …… 前置条件 [也就是激发该用例，所应该满足的条件。] 后置条件 [也就是该用例完成之后，将执行什么动作。] 成功保证 [描述当目标完成后，环境的变化情况。] 触发事件 [什么引发用例，例如时间事件。] 描述 步骤 活动 1 [在这里写出触发事件到目标完成以及清除的步骤。] 2 [……] 3 扩展 步骤 分支动作 1a [引起分支的条件] [活动或子用例名称] 技术和数据变化 1 [变化列表] 用例说明模板3 双列表格式 编者说明： 本模板是对上一模板的补充，如果你想更好地捕捉系统的响应，那么就可以采用本表格所示的格式。 有时，为了更好地捕获系统的响应，对于场景描述（主成功场景、扩展场景）在上表的基础上变成如下表所示的双列： 步骤 用户 系统 用例说明模板4 文本式 编者说明： 相信用过用例分析技术的，对用例应该多少细有很大的疑问，而Alistair Cockburn率先将其进行分级：概要、用户目标、子功能，如果你对他的思想有认同，则该模板就适合于你。 1.用例名： [用例名应是一个动词短语，应让读者一目了然地从名字中就可以知道该用例的目标。] 2.使用语境： [用例目标，是一个较长的描述，甚至包括触发条件。] 3.范围： [用例的设计范围，在设计时将系统作为一个黑盒来考虑。] 4.级别： [用来表示该用例是在描述哪个