为什么要分层
用例描述了用户做了什么事。用户可以做很多事，比如，我们梳理出用户需要下订单，管理收货地址、进行支付、选择支付方式、使用优惠券等，毫无疑问这些都是用例。然而读者会发现，这些用例没有层次和顺序，将导致遗漏一些需求，也不利于研发人员理解需求。
此时，我们可以凭经验来梳理，比如，将用户订外卖的用例按照操作步骤拆解成浏览首页、浏览商品列表、浏览商品详情、选择商品数量和规格、进行登录和输入密码、输入支付密码、确认支付等。这样就清晰了一些，但内容仍然很多，也缺少层次。所以，我们需要把用例分层。
用例层级概述
用例可以分成三个层级，分别是目标层用例、实现层用例和步骤层用例。我们以用户订外卖为例做说明。用户要订外卖，可以拆解的用例如下。
目标层用例：用户订外卖。
实现层用例：为完成用户订外卖的目标，我们可以让用户在网上订外卖，或者打电话订外卖。这两种方法就是实现层用例。
步骤层用例：如果用户选择在网上订外卖，就要进行操作，其步骤是选择菜品、下订单和支付，这三个步骤就是步骤层用例。
通过这种方式梳理，业务的需求就清晰了。以上三个层级都可称为用例，但用通俗的说法表达，三个层级就是在梳理用户的操作目标、该目标的实现方案、该方案的操作步骤。“用例”这个词是更准确的表述，也是有特定含义和目标的概念。
1.目标层用例
目标层用例要从目标和用例两方面理解。既然称作目标层用例，那么该事务既是目标也是用例。其中，目标是指用户使用系统的理由或要达到的效果，用例是指用户实际做的一件事。
目标层用例的判定
用户想做的事情很多，但符合目标层用例的事情并不多。目标是指用户登录网站的理由，所以只要不是用户登录网站的理由，就不算目标层用例。在这个定义下，用户购物、注册和退货等，都是目标层用例，这些用例都是用户登录网站的理由。用户支付货款、设置收货地址等，都不是目标层用例，因为用户一般不会为了设置收货地址而登录网站。为了分清目标层用例，我们要注意以下几点。
1）用户在做完一件事后能满意离开
用户在做完一件事后就满意了，不需要做其他事，那么做这件事就是目标层用例。
用户在做完一件事后就满意了，不需要做其他事，那么做这件事就是目标层用例。
订外卖：登录外卖平台干什么？登录外卖平台订外卖。购买后满意了吗？满意。
退货物：登录电商平台干什么？登录电商平台退货。退货完成后满意吗？满意。
银行存钱：用ATM机干什么？用ATM机存钱。存完钱后满意吗？满意。
显然，在以上案例中用户都是满意的。如果用户只填收货地址，那么这就不是目标层用例。因为用户在填写收货地址后就走了，用户是无法完成购买的，也是不满意的。如果用户支付完毕后就走了，用户也是不满意的，因为用户不会为了给网站付款而付款，用户的目标是购物。
从另一个角度看，无论是填写收货地址还是支付，都不会独立存在，都是为完成“购物”这个目标而执行的步骤。“购物”这个目标是可以独立存在的。实际上，支付和填写收货地址这两个用例都是步骤层用例。
2）员工工作职责是目标层用例
上面我们列举了用户的目标层用例，这些用户都是消费者。企业内部的员工也有目标层用例。比如，用户要购物，员工就要办理发货，用户要退货，员工就要办理退货，办理发货、办理退货都是目标层用例。再如，员工要补货也是目标层用例。
用户的目标层用例的判定标准是，用户能满意离开的是目标层用例。员工的目标层用例的判定标准是，工作完成了，就是目标达成了。比如，上面的发货、退货和补货等工作完成了，就认为目标达成了。
用户的目标层用例的判定标准是，用户能满意离开的是目标层用例。员工的目标层用例的判定标准是，工作完成了，就是目标达成了。比如，上面的发货、退货和补货等工作完成了，就认为目标达成了。
员工的目标层用例往往就是员工的工作职责。比如，员工的工作职责可以是在用户订购货物后及时发货、在库存缺货后及时补货、当用户存款时高效办理存款等。
3）表达目标，而不是具体实现
能够让用户满意离开的事情是目标层用例，但应注意不应体现具体实现。
如果目标的判定比较模糊，也可追问一下要做的工作或解决的问题是什么。比如：
库管要获得商品库存量，要做的工作（解决的问题）是可提前进行补货。
管理员要获得系统错误信息，要做的工作（解决的问题）是排除系统错误。
梳理时的注意事项
我们理解了如何判定目标层用例，而在判定目标层用例时，还应注意以下两点。
1）目标层用例可以分层
目标层用例可分层表述，即可拆分成大目标和小目标。比如，用户目标是订外卖，订外卖可以拆分为订外卖和退货两个目标层用例。
但在实战中，直接列出订外卖和退货两个目标层用例，不分层也是可以的。原因是目标层用例并不多，只要保证能列全就可以了。
2）注册和登录的特殊处理
注册是目标层用例，而登录不是目标层用例，但在实战中不用区别。
用户登录电商平台注册完就走了，或者到银行开通一个账户就走了。因此，注册账号和开通账户都是目标层用例。但是用户不能在登录电商网站后就离开，登录后还需要购物或查询所购商品。
如果产品经理已经能厘清登录和注册功能，那么就不需要通过用例的方式，再来找到注册和登录功能了。
2.实现层用例
为实现用户的目标层用例，产品经理就要定义产品如何实现，这个实现方法就被称为实现层用例。比如，员工补货是一个目标层用例，为了实现补货，我们可以让员工查看电脑上的库存信息，或给员工推送库存告警短信，这两种方法就是在表达如何实现员工补货的目标，就是实现层用例。
目标层用例和实现层用例常常容易混淆，我们再举几个例子便于读者理解。比如，用户要订外卖，就要登录网站下单，这是一种方法。此外，用户还可以打电话下单，这也是一种方法。
再如，一个餐厅的客人要排队，系统就可以支持客人远程用手机排队、客人在现场自己取号排队、由现场服务员代为取号排队这三种实现方法。用户要在外卖网站注册，注册就是目标层用例，其实现方法有用户用手机注册、用邮箱注册等。
在梳理实现层用例时，我们还应注意以下两点。
1）实现层用例可以跳过
区分目标层用例和实现层用例是一个好习惯，这有助于产品经理思考为满足业务目标有哪些可选方案。但这种区分不是必须要做的，比如，在用户订外卖的用例中，企业只打算实现网站下单，那就没必要列出实现层用例。此时目标层用例也暗含着实现方案。
2）实现层用例是解决方案的子集
一个实现层用例同时也是一个解决方案，但是实现层用例只是解决方案的子集。在上文中，我们对解决方案做了深入说明。我们知道解决方案是一个范围很大的词，我们给用户提供的解决方案可以是一项服务、一个产品或一个产品的功能等。
3.步骤层用例
无论实现层用例是什么，都需要系统来实现。用户使用系统的过程，就是一步一步地操作的过程，这就是步骤层用例。同时，通过对这些步骤的拆分和合并，就可划分出产品的设计单元。划分出产品的设计单元就是步骤层用例的目标，也是整个用例分析的最终目标。下面我们分成步骤层用例的拆分和步骤层用例的合并两步，来说明这个过程和目标。
步骤层用例的拆分
用户为完成订外卖这个目标，就要有如下步骤，分别为选择菜品、核对订单、支付订单，这是第一个层级的步骤层用例。而核对订单又可拆分成设置收货地址、修改菜品数量和设置优惠券，这是第二个层级的步骤层用例。
在拆分步骤层用例的时候，我们应注意以下几点。
1）去掉不必要的步骤
用户在订外卖时，必然要看首页、看商家页和进行登录。但这几个步骤不需要加入步骤层用例的拆分。一方面，因为用例的目标是避免遗漏需求，但产品经理不会遗漏以上功能。另一方面，首页和商家页较为独立，与订外卖的关联度并不强。
2）可按页面梳理步骤
我们将步骤拆分成了两层。第一层包括三个步骤，分别是选择菜品、核对订单和支付订单，这也分别对应着三个页面，每个页面就是一个步骤。而核对订单这个页面又包括三个步骤，即设置收货地址、修改菜品数量和设置优惠券。因此，提炼步骤层用例的技巧是，想象下单时有几个页面，就可以轻松地抽象出步骤了。
3）按层来梳理步骤
每个步骤应在同一个层面表述，不要出现有的步骤拆分过粗，有的步骤又拆分过细的现象。如果无法在一个层面表述，则可以将该步骤拆分成多层。在上面的案例中，选择菜品、核对订单和支付订单就是一个层面的问题。但其中“核对订单”的步骤较多，于是我们又拆分出一层，包括设置收货地址、修改菜品数量、设置优惠券。
步骤层用例的合并
我们进行步骤层用例的拆分，是为了梳理出用户的操作步骤，这样就可以避免需求遗漏。但是，我们还应通过用例的合并，来划分出设计单元，这样产品经理就可分单元地去设计产品。
合并的原则是，如果该步骤层用例较小，就要合并该步骤层用例。比如，在“核对订单”步骤下，修改菜品数量是一个简单交互，设置优惠券也是简单的交互，就是一个选择而已。因此，这两个步骤都不能成为独立的设计单元，应合并到核对订单中。
步骤层用例的认定
和目标层用例和实现层用例不同，步骤层用例没有严格的定义和划分，其提炼也极为灵活。虽然提炼很灵活，但是步骤层用例也有认定原则，其认定原则如下。
1）大小适中
有的资料会把用例拆得很细，这是不恰当的。用例的目的是划分设计单元，而不是厘清业务细节。比如，设置收货地址用例就是大小适中的设计单元。但是，如果将该用例再拆成填写姓名、填写手机号和填写送货地址等步骤，就不合适了。
2）高内聚、低耦合
每个步骤都是相对独立的，但步骤之间也有联系。用专业的说法就是高内聚和低耦合。意思是说，用例内的多个功能是紧密结合的，这就是高内聚。同时，用例之间也有联系，但并不紧密，这就是低耦合。
用例分析不适合梳理信息类内容，如个人中心、首页和详情页，这些页面以信息展现为主，并没有太复杂的流程，可直接画原型图。用例分析也不适合梳理熟悉的功能。比如，登录和注册的功能虽然多，但是这些功能很固定，产品经理也很熟悉，不会遗漏这些功能，因此就不需要用用例分析了。
梳理用例是为了不遗漏需求和功能，而不是为了表达自己懂用例。
网友评论