话费|用例图这样画，3步让你做需求分析有理有据( 二 )

一个用例，就是参与者为完成某个特定目标的一系列活动或功能的集合。
换句话说，用例是参与者为满足自己的期望，而完成的事情。
所以说，用例不是功能，而是由参与者驱动的，是有明确目标的，是从用户视角看问题的。
比如，人喝水，大致要做拿杯子、倒水、喝这几个动作，人喝水是用例，拿杯子却不是，因为不会有人没有目的只拿杯子。

2. 用例图的构成用例图，由参与者、用例、边界和关系构成。

1）参与者，用小人表示
按官方文档的定义，参与者是在系统外部与系统交互的人或事物，可以是人、部门或系统。
产品面向的用户，也是在系统之外的参与者。
有时，系统内部也有一些人或对象，参与完成业务，这种称之为业务工人，并非参与者，需区分清楚。
2）用例，用椭圆表示
用例，表示参与者为完成某个目标的一系列活动。用例名称，以动宾短语出现，表示参与者做的事情。
用例是业务分析、需求分析、系统分析与设计过程的基本单位，粒度可大可小。
粒度的确定，一直是个难题，没有标准，只能根据实际情况分析。一个大型系统，可能会有上百个用例，一个小产品，也许只有几个用例。
这有 2 个经验供你参考：

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

3）边界，用矩形表示
边界将系统内外分开，参与者在外面，用例在里面。边界内的用例，就是系统要实现的事情。
一个系统的好坏，常取决于边界是否清晰，即明确做什么、不做什么。边界内的事，是系统的任务；如没有特定条件推动，系统与外界没有联系。
设计产品时，一出现自相矛盾、疑惑的问题，往往可能是不知不觉偏离了最初的定位，跑到边界外部。
因此，做产品要多回归定位，检查产品有没有越界。一个好的产品，是界限分明的，做什么不做什么从不含糊。
4）关系，用常见的箭头连线
UML 中关系挺多的，常用的有关联、包含、扩展、实现四种。

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

5）用例表，图形之外的文字补充
除了画图，UML 中用例图还会写用例表，以描述说明用例，内容包括用例名称、用例描述、参与者、前后置条件、基本流程等。
3. 用例图的类型在 UML 中，用例图的常见类型，有业务用例图和系统用例图。
1）业务用例图
业务用例图，是从业务的视角，对业务进行描述。即描述没有新系统或产品前，业务是如何进行的。
UML 使用业务用例图，旨在把业务描述清楚，发现业务问题和目标，新系统才能更好地解决问题，实现业务目标。