一 什么是用例

用例是对参与者发起的一组动作的描述，系统响应该组动作，并产生可观察到的显著结果。

比如：用户登录电商平台就是一个用例。这个用例的参与者是用户，参与者发起执行了系列工作，系统响应了用户动作，结果就是登录成功。

很多事情都可以归为用例，如用户申请贷款，用户进行登录，用户进行注册，用户浏览商品。总之，用户发起动作，系统响应动作并且有结果，就是一个用例。

1 是用户在系统上做的事

用例是在表述一件事，这件事是：“用户在系统商做了什么？”

a 事情是任务或动作

事情可以是一项任务。例如：用户申请贷款，银行员工审核贷款。

事情可以是人的动作。例如：用户登录，用户输入密码。

b 表述为“动词 + 宾语”

2 用例的两种表达方式

用例可以用用例图和用户故事表达

用例图和用例故事是等价的，只是一个是图形表达，一个是文字表达。

两者的区别是：用例需要画图，图形更有层次和结构，并且因为用例图还可以表达用例间的各种关系，所以还可以用于研发设计软件中。用户故事用文字表达，因为文字的灵活和易懂，所以产品经理稍加变化， 就能将其用于挖掘用户需求上。

3 沟通中不提用例概念 

“用例”这个词不容易被人理解，可以用“用户故事”这个词去沟通，如果有的人还是不明白，可以用“梳理用户要做的事”进行沟通。

所以，无论是用例、用户故事还是用户要做的事，其表述的内容都是一样的，我们只需选择一个便于沟通的说法就可以。

二 用例的特点

1 有宽度地梳理业务

要有宽度地梳理业务，就要有层次地进行梳理，要不断把大的需求有层次地拆解成小的需求。我们可以把用例分为：目标层用例、实现层用例和步骤层用例。

举例：

目标层用例：申请贷款

实现层用例：线上申请贷款、线下申请贷款

步骤层用例：为了完成线上申请贷款，用户就需要有几个步骤，如申请贷款、填写资质等。

用用例方法是为了拓宽度、不是为了拓深度。所谓深度是指异常的情况和分支流程。

2 用例是业务梳理的起点

用例描述了用户做的事，只有明确了用户要做的事，才会在宽度上不遗漏功能。只有明确了用户要做的事，才有描述该事的流程图、状态图和原型图，从而再实现在深度上不遗漏细节。

3 用例是定义功能的起点

很多时候，用户和功能有一定的等价关系。比如，我们说系统有登录功能，或者说用户用该系统登录，这两种说法表达的是一个意思。

但是从用户角度看，通过用例更容易把业务梳理全。比如，针对电商平台的商品管理，从功能上看是增删查改、按销量筛选等功能，但按用例就是上传商品，补充货源等。为完成上传商品，我们可以再梳理出发布和审核流程，并进一步绘制原型图。

三 参与者的概念

1 参与者

参与者是系统之外与系统交互的人或物。

参与者 = 参与人 + 参与系统。

例如：用户到ATM机取款，用户是参与者，如果用户是跨行取款，则与ATM对接的另外一个银行系统也是参与者。

2 参与人

a 参与人与涉众的关系

涉众就是对产品“指手画脚”的人。参与人就是和产品“眉来眼去”的人。其中“指手画脚”是指对产品提意见，“眉来眼去”是指和产品交互。

有时候一个人可以是涉众，也可以是参与人。比如：普通用户，当他给银行系统提意见时，他就是涉众，当他到ATM机取钱的时候，他就是参与人。

有时候一个人可以只是涉众，而不是参与人。比如：国家相关机构可以对软件提出风控需求，但它并不使用系统。

参与人是涉众的子集。参与人要使用产品，涉众可以不用。参与人是个体，涉众可以是个体，也可以是组织。两者的关系如下。

b 主要参与人与辅助参与人

主要参与者也称为启动人，辅助参与人也称为支持人，两者区别如下：

主要参与人是产品存在的原因，会主动发起一项业务。

辅助参与人是支持产品运转的人员，会被动响应业务请求。

比如，用户到 ATM 取款，用户是主要参与人。当 ATM 机的钱取完了，银行员工就要往取款机放钱，此时银行员工就是辅助人员。

需要注意的是，一个人可以是辅助参与人，也可以是主要参与人。从用户视角看，用户下单，物流人员是辅助参与人。但当物流人员使用物流软件时，他就是主要参与人。

在不同系统中，分清主要参与人和辅助参与人，可有层次地梳理业务。通常，应先梳理主要参与人的需求，再梳理辅助参与人的需求。

3 参与系统

当用户通过 ATM 机跨行取钱时，另外一个银行系统就是参与系统。再如，通过第三系统登录，第三方系统就是参与系统。

参与系统不是涉众，原因有二。

a 参与系统可以和产品“眉来眼去”，但无法对产品“指手画脚”，所以不是涉众。

b 涉众只能是人或组织，而参与系统只能是软件或硬件，因此参与系统不是涉众。

产品经理不用把重点放在参与系统上，但需要知道参与系统能提供什么信息或功能。

4 小结

以上就是参与者，参与人和参与系统的概念。参与者包括参与人和参与系统，其中参与人是涉众的一个子集。对于产品经理，应该把主要精力放在参与人的分析上，要努力找到所有参与人，并明确参与人会做什么。

四 参与人和角色的关系

参与人比角色的表述更为准确，强调的是人的操作而不是角色的操作，并且参与人的概念已被业界普遍接受。

对于角色来说，抽象出角色的目的是梳理出相应的权限，如定义谁能查看销售业绩。

参与人既可以写成一个人的名字，也可以写成一个职位。

虽然角色和参与人的概念有区别，但是，将角色作为参与人，或者将职位名作为参与人，也都是没问题的。我们可以将参与人称为销售经理，理财专员，或者称为销售经理张三，理财经理李四，都是没问题的。

五 系统的概念

系统是由相互作用、相互依赖的若干部分结合而成的。

这里的若干部分可以是软件或硬件，也可以是人或组织。关于系统的定义，要注意两点。

1 系统可由硬件、软件和人组成

银行的线下取款系统，就是由硬件、软件和人共同组成的。该系统包含银行员工、软件和硬件，其共同协作完成任务。

总之，现在的柜台取款，ATM机取款，上世纪80年代的人工取款，都是由系统完成的。另外补充一点，银行员工其实就是工人，在 UML 中被称为业务工人（Business Worker）

2 一个系统可以包含另外一个系统

我们发现这里有两个系统：一个是用户角度的取款系统，该系统由硬件、软件和人共同组成；一个是银行员工的角度的系统，该系统就是由银行的内部软件系统。这两个系统有包含关系，即取款系统包含了银行的内部软件系统。