编辑指南：用例图是UML的一种，正确使用用例图可以更清楚地展示用户的需求和用户所需的服务，使产品团队可以站在用户的角度更好地思考问题，建立场景化思维在这篇文章中，作者总结了用例图的类型和使用方法，并进行了共享，让我们一起来看看吧。

以前写《做产品，为什么要画这些图？》，介绍产品的一般视图后，想详细介绍所有图的使用方法，但是不理解，也不想当文字搬运工，所以很难写。

这次，我利用打磨的课程，让他努力学习了几本书，结合这几年的产品制作经验，终于提炼出了自己的构想。

首先说明用例图。 用例是UML中最重要的要素之一，之后的分析流程、设计功能都是围绕它展开的。

本文先介绍为什么要画用例图，然后解读用例图的知识，最后用一个案例展示用例图的绘制方法。

虽然文章有点长，但我相信你阅读后，会对如何进行需求分析有新的认识。

在制作

一、用例图有啥了不起

产品的几年前，我很少画用例图。 在建立数据中心之前，遇到的需求更复杂，翻了《大象：Thinking in UML》，得到了灵感。

读例句的时候，我恍然大悟。 我没有放置例句那样优秀的宝石进行使用，完全是徒劳的存在。

之后，我从业务调查开始，使用用例分析方法，对业务进行了彻底的研究和说明，脑子里渐渐清楚了该如何制作系统。

当然，并不是每个需求都必须画用例图。 如果是简单的需求，不使用笑脸唇膏也没关系。

1. 用户视角

用例设计之初，我们不是永远在系统内执着于功能，而是希望跳出系统，用用户的眼光看系统，思考在什么情况下会向谁提供什么样的支持。

如果学习用例图的分析思想，理解其表现逻辑，至少可以站在用户的角度去看问题。

只有打开这个视角，才能用晦涩难懂的术语让用户不混乱，用商务端的语言进行交流，真正以用户为中心获取需求，转化为产品服务。

练习的方法是，按照用例的规则和方法，一点一点地做，逐渐改变想法。

2. 场景化思维

用例的另一个特点是关注用户在什么情况下做了什么。 这是典型的场面化思维。

我想起了以前必须教妈妈换手机给她用，但是头疼了。

每次跟她说，这都在查号码，这是在打电话，这是在听歌，这是在看视频等等，她都记不住。 我曾经觉得人老了，记忆力差，很难接受新事物。

之后，我反省了自己，改变了战略，告诉了她一些用手机可以做的事情。

打电话，我告诉她第一步按哪里，第二步按哪里，每一步都有什么标记符号，再把经常拨的号码，设定为快捷键，每次只需要一步操作。

结果，她居然记得。

找到了吗？ 功能说明容易脱离用户的使用场景，让人困惑。

所以，我们必须从场景中告诉用户在具体情况下，以该做的为中心，该怎么办。

每次谈

3. 系统思维

产品经理的想法，都要谈系统的想法。 但是，真正能通过系统思考的人，可以说是凤毛麟角。

什么是系统思维？

系统思考，也就是考虑问题时，不能只考虑单个事物的情况，而要全面考虑系统内事物之间的相互影响，关注整体的运行规律。

制作产品时，如果只讨论功能，就会孤立地看产品。

如果产品离开了使用者，就没有意义了。 只有我们同时考虑产品和使用者，才能成为系统的思考。

用例的本质是将产品和使用者作为一个系统来看待。

让我们看看用例。

二、解读用例图

1. 何为用例

用例是一种用于在UML中捕捉功能需求的方法，从不同的角度来解释不同的角色使用系统/产品做什么，也就是谁做什么。

用例之一是参与者为实现特定目标而进行的一系列活动或功能的集合。

换言之，用例是参与者为了满足自己的期望而完成的。

也就是说，用例不是功能，而是由参与者驱动的，有明确的目标，从用户的角度看问题。

例如，人喝水，基本上必须做拿杯子、倒水、喝的动作。 人喝水是个例子，但拿杯子不是。 因为没有人会无缘无故只拿杯子。

2. 用例图的构成

用例图。 由参与者、用例、边界和关系组成。

1 )用参加者、小人表示

根据正式文档的定义，参与者可以是在系统外部与系统交互的人或人、部门或系统。

产品以系统外的参加者为对象。

有时，系统内部也有人或对象，参与工作。 这叫业务工人，不是参与者，需要明确区分。

2 )用例，用椭圆表示

用例。 展示参与者实现目标的一系列活动。 用例名称。 以动句出现，表示参加者所做的事。

用例是财务分析、需求分析

、系统分析与设计过程的基本单位，粒度可专注的黄豆小。

粒度的确定，一直是个难题，没有标准，只能根据实际情况分析。一个大型系统，可能会有上百个用例，一个小产品，也许只有几个用例。

这有 2 个经验供你参考：

完整性，一个用例是一个完整的使用场景，不是零散的动作步骤。比如，拿起手机刷微信是个完整的场景，拿起手机只是一个步骤。独立性，一个用例有一个明确、独立的目标，如果一个用例包括多个目标，则可再逐层细化出子用例。

3）边界，用矩形表示

边界将系统内外分开，参与者在外面，用例在里面。边界内的用例，就是系统要实现的事情。

一个系统的好坏，常取决于边界是否清晰，即明确做什么、不做什么。边界内的事，是系统的任务；如没有特定条件推动，系统与外界没有联系。

设计产品时，一出现自相矛盾、疑惑的问题，往往可能是不知不觉偏离了最初的定位，跑到边界外部。

因此，做产品要多回归定位，检查产品有没有越界。一个好的产品，是界限分明的，做什么不做什么从不含糊。

4）关系，用常见的箭头连线

UML 中关系挺多的，常用的有关联、包含、扩展、实现四种。

关联关系，一般由参与者指向用例，意味着参与者发起用例。当然，也有少数情况，是用例指向参与者，如推送消息，是系统自动触发用户。包含关系，指一个用例包含了子用例，由父用例指向子用例。请注意，父用例并不等于所有子用例之和，它的范围可以大于所有子用例。子用例是一定会执行的。扩展关系，指一个用例在某种情况下需要完成特定活动，由扩展用例指向被扩展用例。与包含关系不同，扩展是特殊分支，在特定情况下才出现的支流，如电商的订单退款。实现关系，连接用例与用例实现，表示一个用例可以有哪几种实现方式。

5）用例表，图形之外的文字补充

除了画图，UML 中用例图还会写用例表，以描述说明用例，内容包括用例名称、用例描述、参与者、前后置条件、基本流程等。

3. 用例图的类型

在 UML 中，用例图的常见类型，有业务用例图和系统用例图。

1）业务用例图

业务用例图，是从业务的视角，对业务进行描述。即描述没有新系统或产品前，业务是如何进行的。

UML 使用业务用例图，旨在把业务描述清楚，发现业务问题和目标，新系统才能更好地解决问题，实现业务目标。

简单需求，很少画业务用例图；复杂需求，用这个思路分析，更好发现业务问题，保证产品需求不跑偏。

2）系统用例图

一般说用例图，默认指系统用例图，它描述参与者使用新系统或产品做什么事，从而实现业务目标。

它是从业务用例分析推导出来的，是新系统的蓝图、开发范围。

从业务用例如何分析、推导出系统用例呢？下面的案例马上讲到。

三、如何画用例图

画图是为了表达、传递信息，当我们画用例图时，本质是在分析业务场景、系统功能性需求，并描述出来。

因此，与其说学如何画用例图，不如说是在学如何分析，用例图只是分析的结果。

下面，我将通过用一个简单的案例，把这个分析过程，一步步展示出来。

以手机话费充值业务为例，假设我们接到一个需求，要开发一个话费充值 APP ，为用户提供充值服务。

常规做法，接到需求，会想到去调研业务、研究竞品，列出功能结构图，再画流程图，很快就能画原型，写 PRD 。

对于简单的产品，这么做没问题。但碰到复杂的系统，就得有一套好的分析思路和方法工具。

用例图，可以帮我们从业务场景分析入手，理清业务，逐步推导出系统功能。

具体怎么做呢？我总结了这 3 步。

1. 分析业务场景，找出人、事、物、目标

如今，我们早已离不开手机，为了能上网、打电话，要用手机就得有话费。

这个业务的“人”比较好找，就是普通手机用户。目标，是为了保证手机可用，得充话费。

充话费，我们可以去微信充值、也可以去支付宝，或用运营商的 APP 。

由此，得出充值话费的几种实现方式，而我们要做一个充值 APP，便是实现方式之一。

△ 充值话费业务用例实现

2. 分析业务流程，细化目标，得出业务用例图

明确业务用例的实现方式，我们挑典型的微信充值来研究，以便了解业务。拿出手机，打开微信手机充值，体验一番，把整个流程理出来。

△ 微信手机充值过程

当我们从用户的视角，绘制出微信充值的流程后，不难发现这个过程中，大致可分为两个阶段。

一个是充值，这个过程不能中断，一断充值就不成功，所以，可以得到一个小目标：充值话费。

一个是查结果，支付完成后，不一定马上有结果，但基本都会成功，这时用户可选择离开；还有一种场景，发现话费快用完了，查什么时候充值的。可见，查看结果目标也相对独立。

△ 用户视角下的微信手机充值活动图

有上面的分析，我们可以把两个有完整目标的活动集合，归纳为两个业务用例：充值话费、查看结果。

再把视角缩到充值过程，充值得支付金额，而支付一般是通用的，供其他模块使用，在系统内部看相对独立，可抽出来，作为子用例。

当查看结果时，发现话费并未到账，需要联系客服处理，虽然这不多见，但偶有发生，所以是一个特殊情况下才会发生的支流，可作为扩展用例。

△ 微信手机充值业务用例图

3. 由业务用例推导出系统用例

经过从场景到流程的分析，业务用例基本清楚。就到最关键的一步，推导出系统用例。

常用的推导方法有：映射、抽象、拆分、合并和补充等。

1）映射，指一种特殊的对应关系，可直接对应过去。比如，微信充值有“充值话费”用例，与我们要做的 APP ，目标一致，可直接映射。

这容易被误以为是抄袭。实际上，如今大部分产品功能都类似，很少有完全创新的东西。如能从用例去分析，就知道为什么这个功能要“抄”，哪个不“抄”，“抄”了要不要改，改哪些。

2）抽象，是找共性，把有相同特征的归纳成一类。比方说，在微信充值中查看结果，但做个新 APP ，得考虑更多操作，这些属于订单的范畴，可归纳为“管理订单”用例。

3）拆分、合并，把一些大的用例进行拆解，或小的用例进行合并，合并类似抽象归纳。

4）补充，根据实际情况，发现业务上没有的，而新产品必不可少，则需要增加相应的用例来完成目标。例如，微信充值中，只能用微信支付，我们做 APP ，要支持多种支付方式，所以补充“支付宝支付”用例。

同理，还要补充“管理账号”用例，用户才能注册登录、查看自己的订单。

经这一推导，新 APP 的参与者，也显而易见：充值得有运营商支持；支付对接微信支付、支付宝；协助用户处理未到账，还需有运营人员介入。可见，整个充值 APP ，还应包括后台管理系统。

这些都是后续系统分析、梳理系统关系、设计系统架构的基础。

为方便说明，我只简化出核心部分，并把子用例合在一起展示。

△ 充值 APP 系统用例图

至此，充值 APP 的系统用例图就出来了。

有这份新系统的蓝图，就可以细化前端 APP 和管理后台的用例，进而再分析系统流程、系统关系、设计产品功能。

这一路的分析推导下来，再画原型图、写 PRD，你自然知道要写什么，设计出来的功能，也更有依据、有逻辑，不容易被人以为是靠拍脑袋的。

四、总结

用例图的基本用法，到此结束了，看累了吧？没关系，我帮你小结下，记住这几条就够了。

1. 为什么要画用例图

用例是从用户视角去思考的，学会站在用户的角度去看产品，更能理解业务，表达清楚需求。

用例的本质，是场景化思维和系统思维的体现。画图的过程，实际上是在锻炼我们的思维方式。

2. 什么是用例图

用例，是 UML 中用来捕获功能性需求的一种方法，它从不同视角，描述不同角色用系统/产品做什么事，即什么人做什么事。

一个用例，就是参与者为完成某个特定目标的一系列活动或功能的集合。

用例图，由参与者、用例、边界、关联构成，写用例表，更完整。

用例图，常见类型有业务用例图和系统用例图。

3. 如何画用例图

1）分析业务场景，找出人、事、物、目标。

2）分析业务流程，细化目标，得出业务用例图。

3）由业务用例图推导出系统用例图。

常用推导方法有：映射、抽象、拆分、合并和补充等。

最后，不是所有需求都要画用例图，视情况而定。

用例作为一种需求分析方法，不管你在是否用到它，关键是理解它的分析思路和表达逻辑。

善用用例，可以提高我们在需求分析、产品设计中的理解、思考和表达能力，确保我们的输出是高效、准确、有理有据的。

从学用例开始，以用户之眼看产品。

从今天起，做个说人话的产品经理。

作者：四月；公众号：四月喃哗

本文由 @四月 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自Unsplash，基于CC0协议。