在软件开发和产品管理领域，用例（Use Case）是一种常用的需求分析和描述方法。它通过描述用户与系统之间的交互来定义系统的功能和行为。这篇文章，我们来学习一下。

用例（Use Case）是一种描述需求的方法。运用用例这种方法来描述需求称之为用例建模。用例也是UML规范中的一种标准化的需求表达方式，其中比较有名的RUP（Rational Unified Process，统一软件开发过程）就是以用例来驱动的。

值得一提的是，虽然RUP被认为是一种重量级的软件管理过程，而越来越多的软件开发开始采用敏捷方法来响应瞬息万变的需求变化。但是用例作为一种描述需求的方式，其理念和方法论对我们分析需求还是有一定的帮助。

从表达方式上看，用例相对时序图、流程图等需求表达方式，更加面向对象和面向设计。通常情况下，用例比较容易让没有受过专业培训的人员接受。用例可以作为一种跟用户或者行外人员陈述需求的方式。

用例是一种描述需求的方法，用例描述了在不同的条件下，系统对参与者的请求做出的响应。用例通常通过一个参与者（Actor）（谁？）向系统做出请求（要做什么？），系统根据参与者的请求，在不同的条件下，执行某一行为序列（系统怎么满足？）。每一个行为序列可以称之为一个场景（Scenario），一个用例包含多个场景。场景也可以称之为用例的一个实例（Instance）。

正式的用例应该包括：用例名、概述、范围、级别、主参与者、项目相关人员和利益、前置条件、最小保证、成功保证、触发事件、主成功场景、扩展场景和相关信息等等。

各个组成部分的意义如下：

用例可以用于不同的目的，如：

不同的编写目的导致了用例在编写过程中有可能出现不同的侧重点。

在不同的团队情况也可能导致用例书写的不一样。比如在一个大型的开发项目组里，就需要严格的按照用例范例进行描述，而在一个小型的沟通频繁的项目组里，则可以采用一种比较简单的描述方式。

上文提到的是比较常见的组成部分。事实上，用例的格式并没有硬性规定，在必要时可以增减里面的信息。具体用例需要包括哪些信息，有不同的流派。有兴趣可以查看相关资料，这里不展开讲。

一句话概括： 你的用例不是我的用例，只有适合的用例才是最好的。

用例用于表述需求，但是有两点要注意的：

用例名用于标识一个用例，便于汇总和阅读。

规则：使用主动语态的动宾短语来描述。

一般情况下，建议使用主动语态的动宾短语来描述用例的目标。如：“查找商品”、“加入购物车”。在某些情况下，如需要更准确的表示出一个用例，可以加入定语进行修饰，如：“用户清除购物车”、“管理员清除购物车”。

规则：以主参与者为对象进行描述。

用例的描述需要以主参与者为对象进行描述，如可以使用“支付订单”（以主参与者为对象），而不是“收取订单费用”(以系统为对象)。

【举例】

用例1：购买商品

……

用例的范围能让我们对系统的边界和讨论的需求有一个基础的语境，不同的设计范围可能会导致我们需要讨论的参与者、场景都会不一样。简单来讲，就是为我们讨论的系统划定一个范围确定我们讨论的界线。

例如我们要讨论一个用户的下单行为。如果以整个企业为范围，其项目的相关人员为用户、第三方服务者（如快递等）。但如果以系统为范围，其项目相关人员还应该包括企业内部的系统管理员、客服等。

所以，在编写用例时需要搞清楚，我们的用例的范围是什么，这样可以对用例讨论的问题达成一个共识。

1）功能范围

在讨论用例的设计范围时，需要先确定系统的功能范围。Cockburn在《编写有效用例》里面推荐了一个确定功能范围的方式“内/外列表”。

确定功能范围的好处是显而易见。如，系统外部已经有了一个打印订单的系统，如果不明确区分系统的功能范围，部分开发人员有可能会对打印订单功能进行设计和实现。而事实上，这些功能是不需要设计的。

明确了功能范围后，还可以确认系统的执行人员。如上面的例子，打印订单系统将作为“打印订单”用例的辅助执行者。

2）设计范围

设计范围是在功能范围确定了之后做的。设计范围指的是我们在编写用例时讨论问题的边界和对象。我们在用例里面说的范围（Scope）如果没有特殊说明指的就是设计范围（而不是功能范围）。

下面来看一个例子，ECom公司打算做一个ESys的系统，系统里面包括了ESubSys等多个子系统。

设计范围的大小

如果以ECom为设计范围来讨论用例，我们关心的是用户对公司的需求是什么，公司以什么样的形式满足用户的请求。如果有外部公司，则还要考虑外部公司与公司之间往来的业务是什么。

如果以ESys为设计范围来讨论用例，我们更关心用户向系统发起的请求和系统对请求的响应。同时，如果以ESys做范围的时候，企业内部的员工也成了用例的执行者，我们还应该考虑员工对系统的请求。

确定用例范围，能很好的对其我们要讨论的问题是什么，界定我们讨论问题的范围，给用例一个语言环境。

规则：设计范围是一个简单的专有名称。

用例的范围应该是一个简单的专用名词，简单说明一下用例讨论的范围界线。如，上面的例子中范围可以直接用“ECom”、“ESys”、“ESubSys”来表示。

【举例】

用例1：购买商品

范围:电商系统

……

主执行者是系统相关人员中，请求系统做出响应的人或物。主执行者是对系统请求的发起者，主执行者可以不是直接操作系统的相关人员。

其中一种情况下是主执行者通过另一个系统操作相关人员对系统进行操作。如，客户致电客服查询异常订单的场景。客户并没有直接通过系统进行查询。

另一种情况是定时触发任务。如客户希望系统定时执行一个任务，那么最终执行系统的相关人员是系统本身。

虽然识别出主执行者很重要，可是在有些时候主执行者也没那么重要。

在编写用例时，识别出主执行者，可以从执行者角度出发，充分梳理系统需求。我们还可以主执行者的特点来设计系统的交互。如下表，主执行者概括表：

在多数情况下，我们开始编写用例开始后，主执行者就变得没那么重要了。例如，当我们在设计查询订单用例时，无论是管理员、经理、客服甚至是其他的公司职位，在查询订单这个用例上并没有特别的差异。这个时候，主执行者具体是谁已经不重要了。

规则：用例的主执行者可以是执行者或者执行者角色。

在上述情况下，我们会将部分主执行者一般化的方式，创建一个“角色-执行者对应表”。在上述用例里，我们将管理员、经理等一般化为一个操作角色——订单管理者。我们在描写用例时，以角色作为主执行者即可。

【举例】

用例1：购买商品

主执行者：用户

范围：电商系统 ……

概述主要用于描述用例的目标，也就是用户需要完成的目标。

规则：使用自然语言描述。

尽量使用自然的语言阐述用户要完成目标时，用户会做什么事情。

规则：描述用例实现什么，而不描述系统步骤。

只需要讲清楚用例需要完成的事情即可，这里不需要描述系统步骤或者用户的具体操作流程。

如：“用户选择一件需要购买的商品后，可以将商品加入购物车，然后在购物车里面提交订单。用户也可以不需要加入购物车，直接购买选中的商品。”概述并不需要描述具体的系统操作，在这里并没有描述“点击加入购物车按钮”等系统的操作细节。

【举例】

用例1：购买商品

主执行者：用户

概述：用户选中商品后，通过系统下订单购买商品并支付货款。不包括管理员处理订单。 范围：电商系统 ……

项目的相关人员是指对系统有特定利益的参与者。相关人员不一定是人，也可以是一个外部系统、一个组织等。

所以能成为项目相关人员的有可能是：

1）主执行者

主执行者是发起执行用例的相关人员。

2）辅助执行者

辅助执行者是为被设计的系统执行服务的的外部执行人员。辅助执行者可以是另外一个系统、也可以是一个人或组织。如，一台打印机，为系统打印各种票据。再如，快递公司，为系统提供快递服务，并提供物流信息。

3）内部执行者

内部执行者是在系统内部关注系统利益的相关人员。

4）被设计的系统

被设计的系统本身有时候对自己也是有特定利益的。

对于相关人员，有几点需要说明：

规则：相关人员和利益用以对应列表的方式书写。

使用”：”的方式，描写相关人员和其关注的利益。

【举例】

用例1：购买商品

主执行者：用户

概述：用户选中商品后，通过系统下订单购买商品并支付货款。不包括管理员处理订单。 范围：电商系统

……

项目相关人员和利益：

用户：希望通过系统下订单购买需要他需要的商品。

系统：记录用户购买的订单，以便给订单管理员处理。

……

在编写用例过程中，我们有时会具体描述一个用户的需求（如用户购买商品），有时候会描述一个系统的具体功能（如用户登陆），有时候会描述一个流程（如购买商品并获得商品的流程）。在编写用例的时候，知道用例所处的位置，对我们编写和理解用例有很大的帮助。

我们将用例级别从总到分划分成了三个层次：概要、用户目标、子功能。

1) 用户目标

用户目标是指主执行者使用系统期望获得的目标。用户目标是我们编写用例的重点。用户目标描述了主执行者通过系统“做一件什么事”，以及做完这件事后“用户能获取什么利益”。

用户目标应该是主执行者一次执行系统获取利益的过程。所以，不是一次执行所能完成的目标，或者用户不能获得利益的需求不能称为用户目标。

如，购买一个商品的流程，这个从下订单到快递需要几天的过程，所以不能称为一个用户目标。再如，用户登陆，用户登陆并不能获取什么利益，所以也不能称为一个用户目标。用户下单这个操作，可以作为一个用户目标。

2) 概要

概要层次可以包含多个用户目标，概要目标执行周期比用户目标更长，可以是一个几天、几个月甚至更长的过程。概要目标有三个目的：

3) 子功能

子功能层次是用户目标在执行过程中会执行到的目标。如，一次登陆，一次订单打印等。也有可能存在多个用户目标共用一个子功能，如查找商品、查找订单等。

子功能用例的存在是为了用户目标用例增加可读性而存在的。在实际编写过程中，不到迫不得已，不要设计子功能层出用例。

规则：层次只有三个选项：概要、用户目标、子功能。

用例的层次只能是概要、用户目标、子功能三个之中的一个层次。

【举例】

用例1：购买商品

主执行者：用户

概述：用户选中商品后，通过系统下订单购买商品并支付货款。不包括管理员处理订单。 范围：电商系统

级别：用户目标

项目相关人员和利益：

用户：希望通过系统下订单购买需要他需要的商品。

系统：记录用户购买的订单，以便给订单管理员处理。

……

前置条件是我们在用例执行之前期望必须成功的条件。在用例编写过程中，可以不对该条件进行检查和讨论。如，“下订单”必须依赖于“用户已经登陆”这个前置条件。

规则：前置条件必须是用例执行前我们期望一定成功的条件。

要预防将那些并不是必须条件的条件写入前置条件。如，取消订单并不依赖于用户下单成功，事实上，用户可以将下单不成功（例如支付失败）的订单取消掉。而订单下单是否成功这个条件是需要在用例里面对这个条件进行检查并执行不通过动作的。

【举例】

用例1：购买商品

主执行者：用户

概述：用户选中商品后，通过系统下订单购买商品并支付货款。不包括管理员处理订单。 范围：电商系统

级别：用户目标

项目相关人员和利益：

用户：希望通过系统下订单购买需要他需要的商品。

系统：记录用户购买的订单，以便给订单管理员处理。

前置条件：用户已经登陆系统。

……

最小保证是用例执行无论是否成功都会被执行的保证。虽然，用例无论执行成功与否，最小保证总会被执行。但是，最小保证