通俗地讲，用例是文本形式的情节描述， 用以说明某参与者使用系统以实现某些目标。
注意：用例不是图形，而是文本。 用例初学者的常见错误就是注重于次要的UML用例图，而非重要的用例文本。
本质上，用例是通过编写使用系统实现用户目标的情节来发现和记录功能性需求 ，也就是使用的案例(cases of use)
定义：参与者、场景和用例
参与者 (actor)是某些具有行为的事物，可以是人(由角色标识)、计算机系统或者组织。例如：收银员
场景 (scenario)是参与者和系统之间的一系列特定的活动和交互，也称为用例实例 (use case instance)。场景是使用系统的一个特定情节或用例的一条执行路径。例如，使用现金成功购买商品的场景，或者由于信用开付款被拒绝造成的购买失败场景。
通俗地讲，用例 (use case)就是一组相关的成功和失败场景集合，用来描述参与者如何使用系统来实现其目标。
RUP对用例进行如下的定义:
用例和用例模型
UP在需求制品中定义了用例模型 (Use-Case Model)。首先，这是所有书面用例的集合；同时，它是系统功能性和环境的模型。
用例模型可以包含UML用例图，以显示用例和参与者的名称和其关系。UML用例图可以为系统及其环境提供良好的语境图 (context diagram)，也为按名称列出用例提供了快捷方式。
用例不是面向对象的，编写用例时也不会进行OO分析。但这并不妨碍其有效性，用例可以被广泛应用。也就是说，用例是经典OOA/D的关键需求输入 。
动机：为什么使用用例
在软件项目中，缺少用户参与是项目失败的主要原因之一。研究人员设计了他们自己能够理解的复杂分析方法，但是一般的业务人员却对此迷惑不解。因此，任何有利于用户参与的方法都是绝对值得的。
用例是一种优秀的方法，是领域专家或者需求提供者自己编写(或者参与编写用例)用例成为可能，使与用户沟通 的工作难度降低。
用例的另一个价值在于：强调了用户的目标和观点。
用例的优越性在于，能够根据需要，对复杂程度和形式化程度进行增减调整。
定义：用例是功能性需求
用例就是需求，主要是说明系统如何工作的功能性或行为性需求。按照"FURPS+"需求类型，用例强调了"F"(功能性或行为性)，但也可以用于其他类，特别是于用例紧密相关的那些类型。在UP和其他的现代方法中（XP，TDD），用例被推荐作为发现和定义需求的核心机制。
用例是真正的需求(尽管不是所有的需求)。用例的主要思想(通常)是：为功能性需求编写用例，从而降低详细的老式特性列表的重要性或减少这种列表的使用。
定义：参与者的三种类型
参与者 (actor)是任何具有行为的事物，在所讨论系统(System under Discussion, SuD)调用其他系统的服务时，还包括起本身。主要参与者和协助参与者会出现在用例文本的活动步骤中。相对于SuD,有三种参与者：
- 主要参与者 (primary actor)：具有用户目标，并通过使用SuD的服务完成。例如：收银员。为何要确定主要参与者？发现驱动用例的用户目标。
- 协助参与者 (supporting actor)：为SuD提供服务(例如，信息服务)。协助参与者一般是计算机系统，也可以是组织或者人。为何要确定协助参与者？为了明确外不接口和协议。
- 幕后参与者 (offstage actor)：在用例行为中具有影响或者利益，但不是主要或者协助参与者。如，政府税收机构。为何要确定幕后参与者？这是为了确保确定并满足所有必要的重要事物。如果不明确地对幕后参与者进行命名，则有时容易忽略其影响活利益。
用例的三种常用表示法
用例能够以不同形式化程度或格式进行编写：
- 摘要——简洁的一段式概要，通常用于主成功场景。用于早期需求分析过程中，为了快速了解主题和范围。
- 非正式——非正式的段落格式。用几个段落覆盖不同场景。同样，用于早期需求分析过程中，为了快速了解主题和范围。
- 详述——详细编写所有步骤及各种变化，同时具有补充部分，如前置条件和成功保证。何时使用?确定并以摘要形式编写了大量用例后，在第一次需求讨论会中，详细的编写其中少量(例如：10％)的具有重要架构意义和高价值的用例。
1490
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
