用例名称 | 建议使用动名词,后跟一个直接宾语,有时候需要更全的信息 名称应始终以用户为中心,而不是以系统为中心。 | |||||
用例编号 | 有层次结构的编号方案,配合名称使用。 | |||||
编制人 | YangTom | 编制日期 | 2005-4-6 | |||
批准人 |
| 批准日期 |
| |||
批准人 |
| 批准日期 |
| |||
主要参与者 | 参与者通常在系统外部,与系统无关。真正重要的是参与者扮演的角色。 | |||||
次要参与者 | 参与者定义了用户在系统交互过程中扮演的角色 | |||||
简要描述 | 简要介绍该用例的作用和目的 | |||||
触发事件 | 用例必须是由某一个主角触发而产生的活动,即每个用例至少应该涉及一个主角。 | |||||
前置条件 | 指在用例启动时,参与者(Actor)与系统应置于什么状态,这个状态应该是系统能够检测到的、可观测的 | |||||
事件流 | 基本事件流是对用例中常规、预期路径的描述,也被称为Happy day场景,这时大部分时间所遇到的场景;它将体现系统的核心价值; | |||||
可选事件流 | 描述用例执行过程中异常的或偶尔发生的一些情况 | |||||
后置条件 | 用例结束时,系统应置于什么状态,这个状态也应该是系统能够检测得到的、可观测的 | |||||
非功能性需求 | 包括性能、可靠性、可用性和可扩展性等 | |||||
设计约束 | 所使用的操作系统、开发工具等 | |||||
业务规则 | 用例描述中最好不要包含这些规则,但应该以某种方式指定这些规则,以便使文档足够正确而能够使用。 | |||||
所有相关表证单书 |
| |||||
相关代码表 |
| |||||
权限范围 |
| |||||
修改历史 | ||||||
修改人 | 版本 | 说明 | 修改日期 | |||
|
|
|
| |||
用例模型主要包括以下两部分内容:
- 用例图(Use Case Diagram)
确定系统中所包含的参与者、用例和两者之间的对应关系,用例图描述的是关于系统功能的一个概述。 - 用例规约(Use Case Specification)
针对每一个用例都应该有一个用例规约文档与之相对应,该文档描述用例的细节内容。
用例图只是在总体上大致描述了系统所能提供的各种服务,让我们对于系统的功能有一个总体的认识。在面向对象的分析设计方法中,用例模型主要用于表述系统的功能性需求,用例描述才是用例分析技术的核心
用例模型完成之后,可以对用例模型进行检查,看看是否有遗漏或错误之处。主要可以从以下几个方面来进行检查:
- 功能需求的完备性
现有的用例模型是否完整地描述了系统功能,这也是我们判断用例建模工作是否结束的标志。如果发现还有系统功能没有被记录在现有的用例模型中,那么我们就需要抽象一些新的用例来记录这些需求,或是将他们归纳在一些现有的用例之中。 - 模型是否易于理解
用例模型最大的优点就在于它应该易于被不同的涉众所理解,因而用例建模最主要的指导原则就是它的可理解性。用例的粒度、个数以及模型元素之间的关系复杂程度都应该由该指导原则决定。 - 是否存在不一致性
系统的用例模型是由多个系统分析员协同完成的,模型本身也是由多个工件所组成的,所以我们要特别注意不同工件之前是否存在前后矛盾或冲突的地方,避免在模型内部产生不一致性。不一致性会直接影响到需求定义的准确性。 - 避免二义性语义
好的需求定义应该是无二义性的,即不同的人对于同一需求的理解应该是一致的。在用例规约的描述中,应该避免定义含义模糊的需求,即无二义性。
参考资料:1.用例建模指南