用例

用例（英語：use case），或譯使用案例、用况，是软件工程或系统工程中对系统如何反应外界请求的描述，每个用例提供了一个或多个场景，该场景说明了系统是如何和最终用户或其它系统互動，也就是谁可以用系统做什么，从而完成一个明确的业务目标。人們可以通过用户的使用场景来進行需求分析。编写用例时要避免使用技术术语，而应该用最终用户或者领域专家的语言。用例一般是由软件开发者和最终用户共同创作的。

在1986年，Ivar Jacobson，UML和瑞理统一过程的重要贡献者，提出了用例的概念。Jacobson的思想很有影响力，也很有发展力。之后在这个科目上又有很多贡献，在定义用例是什么和怎么有效的书写用例方面最重要，最有影响力也最全面的，是Alistair Cockburn，他写的书籍是《编写有效用例》。

用例迅速成为获取功能需求最常用的手段。用例最初是和面向对象一同提出的。但是它不止局限于面向对象系统，因为用例实质上不是面向对象。

由于不少测试工程师将测试用例简称为用例，为便于区分两者，将原来的Use case （页面存档备份，存于互联网档案馆）用例称为需求用例。

测试用例（对应英文Test case （页面存档备份，存于互联网档案馆））已经广为人知，没有歧义，但就文字表面而言，测试用例類似是属于用例，就像红富士苹果属于苹果一样，所以为了更容易区分，需求用例是个更清晰的称呼。

用例范围和目标

每个用例集中描述如何获得一个业务目标或任务。从传统的软件工程视角来看，用例只是描述了系统的一个特征。所以对大部分软件项目来说，这就意味着需要很多（有可能是数十个）用例来完整的描述新系统。一个特殊软件项目的正规度和项目的不同阶段将会影响每一用例需要的详细程度。

一个用例定义了外部执行者和被考虑的系统之间的交互来实现一个业务目标。执行者是在系统外部和系统交互的人；一个执行者可以是一类用户，用户可以扮演的角色或者其它系统。

用例把系统看作"黑盒"，同系统的交互，包括系统的响应都是可以在系统外部感知的。它是一个deliberate policy，因为它简化了需求的描 述，避免了对功能如何实现做出假设的陷阱。

用例应该：

• 描述了满足业务目标的业务活动
• 没有涉及特定的实现语言
• 要求合适的细节级别
• 足够短，使得在一次发布中能够被一个软件开发人员实现

用例图

主条目：用例图

An UML Use case diagram

用例图并不是画成了图形的用例。用例图包含一组用例。每一用例用椭圆表示，放置在矩形框中；矩形框表示整个系统。矩形框外画如图所示的小人，表示参与者。参与者不一定是人，可以是其他软件、硬件等等。某一参与者与某一用例用线连起来，表示该参与者和该用例有交互。

许多人通过UML认识了用例，UML定义为展现用例的图形符号。UML并没有为描述用例定义书写格式的标准，因此许多人误认为这些图形符号就是用例本身；然而，图形符号只能给出最简单的一个或一组用例的概要。

UML是用例图形符号最流行的标准。但是，还有一些其它的可选择的标准。

书写用例

细度

Alistair Cockburn在编写有效用例一书中确定了三种书写用例的细度。

摘要

摘要用例有很少的句子组成来总结的用例。它十分适合在电子表格中计划软件开发。一个摘要用例能够简单插入电子表格的单元格中并且用表格中的其它列记述业务优先级，技术复杂度，版本号等。

非正式

一个非正式的用例由文本段落组成，包括了上面提到的那些列，用总结或故事的形式详细的描述了用例。

完整正式

一个完整正式或者复杂的用例是一个以包含了不同部分的长模板为基础的正规的文档。该用例在下面的用例模板部分进行讨论。

适当使用

一些软件开发方法学只需要非正式的用例来定义需求。然而，开发方法学需要完整正式或详细的用例来定义需求。较大且较复杂的项目更需要使用完整正式的用例。

用例模板

编写详细的或完整的用例，尚无通用的模板（英語：template）。现在存在很多相互竞争的模板。同时，程序员们也被鼓励用那些适合于他们的工作或者他们所做项目的模板，相对于某个指定模板的细节来说，项目的标准化要重要的多，但是这些模板的关键部分都是大体相同的，所以，虽然在某些术语上或者其他一些方面上存在不同，但是这些用例从本质上来说，是大同小异的。

典型部分包括：

• 用例名称
• 角色
• 描述
• 前置条件
• 事件流
  • 基本流
  • 备选流
• 后置条件
• 扩展点
• 业务规则
• 特别要求
• 迭代

不同的模板经常有其它部分，如，假设，异常流，建议，技术要求。也会有行业细节部分。

用例名称

用例名称为用例提供了一个唯一标识。它要用动/宾格式书写，并且要充分，达到最终用户能够明白用例中描述的是什么。

迭代

迭代部分通常需要告知读者用例完成的阶段。最初，为业务分析和确定范围的用例和用于软件开发的用例肯定会有许多不同。老版本的用例可能还在当前文档中，因为它们对不同的用户群可能会有价值。

描述

描述部分用于在主体完成之前捕获基本场景。它提供了快速的总结，避免了读者浏览全部内容，能够很快的理解该用例的用途。

前置条件

前置条件部分用来表达当用户开始用例时某些条件必须为真。但是它们不是启动用例的触发器。

基本流

最低限度，每一个用例都需要描述一个主场景或者典型事件流。主事件流一般是一组有编号的步骤，如：

1. 系统提示用户登录。
2. 用户输入他的名字和密码。
3. 系统验证用户信息。
4. 系统使该用户登录入系统

……其他

备选流

用例可能包含第二条路径，或者和主题不同的备选场景。异常或当出错时会发生什么事情也需要描述出来，这种描述可以在备选路径中或者在它本身的部分。备选路径使用基本事件流中的序号来标示在哪一点上同基本场景不同，并且如果合适它从哪一点回到基本场景中。目的是避免不必要的重复信息。

备选流的例子：

1. 系统识别用户机器上的cookie
2. 到步骤4（基本流）

异常路径的例子：

1. 系统不能识别用户登录信息
2. 到步骤1（基本流）

后置条件

后置条件部分总结了在场景结束后事务的状态。

业务规则

业务规则是一些成文的或未成文的规则，对于用例来说它决定了一个组织是如何执行业务的。业务规则是一个特殊种类的假定。它可能适用于某一个用例或者整个用例，甚至整个业务。

特别要求

说明对于本用例的非功能性要求，典型的是并发情况下的响应时间要求，还有易用性要求等等

用例的效益

用例是一个较新的，比较敏捷的捕获软件需求的形式。用例经常和大的，统一的文档形成对比。这些大文档想要在新系统开始构成前，完整的表达出所有可能的需求，但这种做法通常都是失败的。

用例的几点优势：

• 用例已经证实更容易被业务用户理解，因此它也是开发人员和最终用户的很好的沟通桥梁。
• 用例对于确定范围很有用。用例使分阶段交付从而一步步完成项目变得容易；它们能够在优先度变化时相对较容易的添加或从软件项目移去。
• 用例可跟踪。
• 用例能够作为估计，制定进度和验证成果的基础。
• 用例防止了不成熟的设计。
• 用例不使用特定语言。
• 用例允许我们去讲故事。能够容易的采用将需求转换为故事或场景这一具体的方法来描述用例。
• 用例在项目中可复用。用例在每一次迭代中都能进一步演化，用例可以用于捕获需求，成为程序员的开发依据，发展为测试用例，到最后成为用户手册。
• 用例与用户和系统交互相关。它们使软件开发者在开发之前或当中就能够开始用户接口设计。
• 用例将需求置于上下文中，它们能够清楚地描述业务活动间的关系。

用例的局限性

用例不是没有局限性：

• 用例在捕获系统功能需求上表现很优秀，但是它们并不适合方便的捕获非功能性需求，需要其它的方法去捕获非功能性需求。
• 用例模板不能自动保证清晰。清晰要依靠书写者的技巧。
• 用例并不像支持者说的那样易于理解。There is a learning curve involved in learning to interpret them correctly for end users and programmers alike.（如何正确地向最终用户和程序员解释这些用例是一个需要花费时间学习的事情。）
• 极限编程的说明者通常认为用例是没用的文档，他们更喜欢用较简单的用户故事这一方法。
• 可用性设计人员批评用例在开发过程中过早的引入了用户接口设计。他们指出用例描述用户和系统之间的交互，很显然它和用户接口设计重叠了。不好的用例描述将过细的，专断的用户接口设计包含于交互的描述中，即使用例的一个原则是不要加入实现的细节。

用例指南

• 用例 （页面存档备份，存于互联网档案馆）