用例模板

用例名称		建议使用动名词，后跟一个直接宾语，有时候需要更全的信息 名称应始终以用户为中心，而不是以系统为中心。
用例编号		有层次结构的编号方案，配合名称使用。
编制人		YangTom		编制日期	2005-4-6
批准人				批准日期
批准人				批准日期
主要参与者		参与者通常在系统外部，与系统无关。真正重要的是参与者扮演的角色。
次要参与者		参与者定义了用户在系统交互过程中扮演的角色
简要描述		简要介绍该用例的作用和目的
触发事件		用例必须是由某一个主角触发而产生的活动，即每个用例至少应该涉及一个主角。
前置条件		指在用例启动时，参与者（Actor）与系统应置于什么状态，这个状态应该是系统能够检测到的、可观测的
事件流		基本事件流是对用例中常规、预期路径的描述，也被称为Happy day场景，这时大部分时间所遇到的场景；它将体现系统的核心价值；
可选事件流		描述用例执行过程中异常的或偶尔发生的一些情况
后置条件		用例结束时，系统应置于什么状态，这个状态也应该是系统能够检测得到的、可观测的
非功能性需求		包括性能、可靠性、可用性和可扩展性等
设计约束		所使用的操作系统、开发工具等
业务规则		用例描述中最好不要包含这些规则，但应该以某种方式指定这些规则，以便使文档足够正确而能够使用。
所有相关表证单书
相关代码表
权限范围
修改历史
修改人	版本		说明			修改日期

用例模型主要包括以下两部分内容：

• 用例图(Use Case Diagram)
  确定系统中所包含的参与者、用例和两者之间的对应关系，用例图描述的是关于系统功能的一个概述。

• 用例规约(Use Case Specification)
  针对每一个用例都应该有一个用例规约文档与之相对应，该文档描述用例的细节内容。

用例图只是在总体上大致描述了系统所能提供的各种服务，让我们对于系统的功能有一个总体的认识。在面向对象的分析设计方法中，用例模型主要用于表述系统的功能性需求，用例描述才是用例分析技术的核心

 

用例模型完成之后，可以对用例模型进行检查，看看是否有遗漏或错误之处。主要可以从以下几个方面来进行检查：

• 功能需求的完备性
  现有的用例模型是否完整地描述了系统功能，这也是我们判断用例建模工作是否结束的标志。如果发现还有系统功能没有被记录在现有的用例模型中，那么我们就需要抽象一些新的用例来记录这些需求，或是将他们归纳在一些现有的用例之中。

• 模型是否易于理解
  用例模型最大的优点就在于它应该易于被不同的涉众所理解，因而用例建模最主要的指导原则就是它的可理解性。用例的粒度、个数以及模型元素之间的关系复杂程度都应该由该指导原则决定。

• 是否存在不一致性
  系统的用例模型是由多个系统分析员协同完成的，模型本身也是由多个工件所组成的，所以我们要特别注意不同工件之前是否存在前后矛盾或冲突的地方，避免在模型内部产生不一致性。不一致性会直接影响到需求定义的准确性。

• 避免二义性语义
  好的需求定义应该是无二义性的，即不同的人对于同一需求的理解应该是一致的。在用例规约的描述中，应该避免定义含义模糊的需求，即无二义性。

参考资料：1.用例建模指南