一 为什么要分层

在用例图的绘制中，我们知道用例是有包含关系的。通过一层层的包含关系，我们可以将用例分层。

如果不分层，随意去写用例，会感觉用例没有层次和顺序，会导致遗漏一些需求，也不利于研发人员理解需求。

就算我们可以凭经验来梳理用例，但是内容仍然很多，也缺少层次，所以，我们需要将用例分层。

二 用例层级概述

可以把用例分为三个层级：目标层用例、实现层用例、步骤层用例。

以用户订外卖为例，来说明用例的分层。

• 目标层用例：用户订外卖。
• 实现层用例：为完成用户订外卖的目标，可以有用户在网上订外卖，或者打电话订外卖两个实现层用例。
• 步骤层用例：如果用户选择了网上订外卖，就要进行操作，其步骤是选择菜品、下订单和支付，这三个用例就是步骤层用例。

三个层级就是在梳理用户的操作目标、该目标的实现方案、该方案的操作步骤。

三 目标层用例

既然称为目标层用例，那么该事务既是目标也是用例。

按照这个定义，用户的目标可以是订外卖、退货，或者存款。这些目标就是用户登录网站的原因，也是期望要做的事情。

1 目标层用例的判定

用户想做的事情很多，但符合目标层用例的事情并不多。目标是用户登录网站的理由，所以只要不是用户登录网站的理由，就不算目标层用例。

a 用户在做完一件是后能满意离开

用户在做完一件事后就满意离开，不需要做其他事，那么做这件事就是目标层用例。

订外卖：订完后，满意了吗？满意了。

退货物：退货完满意了吗？满意了。

银行存钱：存完钱后满意了吗？满意了。

这三个都满意了，是目标层用例。

设置收货地址：用户填完后，就走了，用户无法完成购买，用户是不满意的，所以它不是目标层用例。

b 员工的工作职责就是目标层用例

员工的目标层用例往往就是员工的工作职责。比如，员工的工作职责可以是在用户订购货物后及时发货、在库存缺货时及时补货、当用户存款时高效办理存款。

**c 表达目标，而不是具体实现 **

能够让用户满意离开的事情是目标层用例，但应注意不应体现具体实现。

2 梳理时的注意事项

a 目标层用例可以分层

目标层用例可分层表述，即可拆分成大目标和小目标。比如，用户目标是订外卖，订外卖可以拆分成订外卖和退货两个目标层用例。但在实战中，直接列出订外卖和退货两个目标层用例，不分层也是可以的。原因是目标层用例并不多，只要保证能列全就可以了。

b 注册和登录的特殊处理

注册是目标层用例，而登录不是目标层用例，但在实战中不用区别。

如果产品经理已经能理清楚登录和注册的功能，那么就不需要通过用例的方式，再来找注册和登录的功能。

四 实现层用例

为实现用户的目标层用例，产品经理就要定义产品是如何实现，这个实现方法被称为实现层用例。比如，员工补货是一个目标层用例，为了实现补货，我们可以让员工查看电脑上的库存信息，或给员工推送库存告急短信，这两种方法就是在表达如何实现员工补货的目标，就是实现层用例。

目标层用例和实现层用例常常容易混淆。再举几例：

a 用户要订外卖是目标层用例，登录网站订外卖是一个实现层用例，打电话订外卖是另外一个实现层用例。

b 餐厅的客人排队，可以支持客人远程手机排队、客人在现场自己取号排队、由现场服务员代为取号排队三种实现层用例。

c 注册是目标层用例，可以有用户手机注册和邮箱注册两种实现层用例。

1 注意点

a 实现层用例可以跳过

b 实现层用例是解决方案的子集

五 步骤层用例

无论实现层用例是什么，都需要系统来实现。用户使用系统的过程，就是一步一步地操作的过程，这就是步骤层用例。同时，通过对这些步骤的拆分和合并，就可划分出产品的设计单元。划分出产品的设计单元就是步骤层用例的目标，也是整个用例分析的最终目标。

1 步骤层用例的拆分

以用户完成订外卖这个目标为例，进行说明。

a 去掉不必要的步骤

用户订外卖时，必然要看首页，看商家页和进行登录。但这几个步骤不需要加入步骤层用例的拆分。一方面，因为用例的目标是避免遗漏需求，但产品经理不会遗漏以上功能。另一方面，首页和商家页较为独立，与订外卖关联度并不强。

b 可按页面梳理步骤

我们将步骤分为两层。第一层包括三个步骤，分别是选择菜品，核对订单和支付订单，这也分别对应着三个页面，每个页面就是一个步骤。而核对订单这个页面又包括三个步骤，即设置收货地址、修改菜品数量和设置优惠卷。因此，提炼步骤用例的技巧是，想象下单时有几个页面，就可以轻松地抽象出步骤了。

c 按层来梳理步骤

每个步骤应在同一个层面表述，不要出现有的步骤拆分过粗，有的步骤又拆分过细的现象。如果无法在一个层表述，则可以将该步骤拆分成多层。在上面的案例中，选择菜品，核对订单和支付订单值是一个层面的问题。但其中核对订单的步骤比较多，于是又拆分出一层，包括设置收货地址、改菜品数量、设置优惠卷。

2 步骤层用例的合并

步骤层用例的拆分，是为了梳理出用户的操作步骤，这样可以避免需求遗漏。但是，我们还应通过用例的合并，来划分出设计单元，这样产品经理就可以分单元去设计产品。

合并原则：如果该步骤层用例较小，就要合并该步骤层用例。比如，在核对订单步骤下，修改菜品数量是一个简单的交互，设置优惠卷也是简单的交互，就是一个选择而已。因此这两个步骤都不能成为独立的设计单元，应合并到核对订单中。

通过以上两个步骤，就提炼出四个设计单元，也就是四个步骤层用例。我们可以理解为要绘制的四个原型图，并且在原型图的左侧导航中，有四个页面标签，分别是选择菜品、核对订单、设置收货地址、支付订单。

3 步骤层用例的认定

a 大小适中

用例的目的是划分设计单元，而不是理清业务细节。比如，设置收货地址用例就是一个大小适中的设计单元。但是，如果将该用例再拆分为填写姓名。填写手机号和填写送货地址等步骤，就不合适了。

从另外一个角度看，一个用例就是设计细化的起点，这之后才有该用例的流程图、状态图和原型图。

b 高内聚、低耦合

每个步骤都是相对独立的，但步骤之间也有联系。用例内的多个功能是紧密结合的，这就是高内聚，同时，用例之间也有联系，但并不紧密，这就是低耦合。

为此，我们将核对订单用例中的修改菜品数量、设置优惠卷进行了合并，它们之间是高内聚关系。

六 层级注意点

1 思考结构化，但不应过度结构化

a 用例的划分并不绝对

只要层次合理，数量和大小合适，不遗漏需求即可。

b 层次和数量控制要适合

给出一个建议值：一个中型软件系统的目标层用例数量为1层，每层10个用例以内。每个目标层用例下的实现层用例的数量为1层，每层1~3个用例，并且可以忽略。每个实现层下的步骤层用例为1~2层，每层用例的数量在5个以内。

2 先梳理用例，再提炼设计单元

用例是在梳理用户的目标、实现的方案和执行的步骤，而执行的步骤就是设计单元。但用例不等于功能，两者是一个抽象过程，一个转换过程。

3 不适合梳理信息和熟悉的功能

用例分析不适合梳理信息类内容，如个人中心、首页和详情页，这些页面以信息展现为主，并没有太复杂的流程，可直接画原型图。

用例分析页不适合梳理熟悉的功能。比如，登录和注册功能虽然多，但是这些功能很固定，产品经理也很熟悉，不会疏漏这些功能，因此不需要用用例分析。