用例图可以对需求建模_需求分析需要画什么图[通俗易懂]

用例图可以对需求建模_需求分析需要画什么图[通俗易懂]用例,是UML中用来捕获功能性需求的一种方法,它从不同视角,描述不同角色用系统/产品做什么事,即什么人做什么事

编辑导语:用例图是UML的其中一种,合理使用用例图,可以更清晰地展示用户需求与用户所需服务,让产品团队更好地站在用户角度去思考问题,并建立场景化思维。本篇文章里,作者总结、分享了用例图的类型与用法,一起来看一下。

用例图可以对需求建模_需求分析需要画什么图[通俗易懂]

之前写《做产品,为什么要画这些图?》,介绍产品常用视图后,一直想深入介绍每一种图的用法,却生怕理解不到位,又不想当文字搬运工,迟迟不敢开写。

这次趁着打磨课程,逼自己猛啃几本书,结合这几年做产品的经历,总算提炼出自己的思路。

我首先要讲的是用例图,用例是 UML 中最重要的一个元素,后续分析流程、设计功能,都是围绕它展开的。

本文先介绍为什么要画用例图,再为你解读用例图知识,最后用一个案例演示如何画用例图。

文章有点长,不过相信你看完,对如何做需求分析会有新的认识。

一、用例图有啥了不起

做产品前几年,我很少画用例图,直到做数据中台,碰到的需求更复杂,我重翻《大象:Thinking in UML》找灵感。

读到用例时,我恍然大悟,原来我放着用例这么好的法宝不用,简直暴殄天物。

后来,我从业务调研开始,用用例的分析方法,把业务研究透、描述出来,系统该做成怎样,脑海里渐渐清晰。

当然,并非每个需求都得画用例图,简单的需求完全可以不用牛刀。

1. 用户视角

用例的设计之初,是希望我们别老在系统内执着功能,而是跳到系统外,以用户的眼光看系统,思考什么情况下给什么人提供什么支持。

如果我们学会了用例图的分析思想,理解它的表达逻辑,至少能试着站在用户的角度去看问题。

开启这种视角,才不会总用晦涩难懂的术语,将用户搞晕,才能用业务方的语言去沟通,真正以用户为中心去获取需求,转化为产品服务。

练习的办法,便是按用例的规则和方法,一点点做, 逐渐转变思考的方式。

2. 场景化思维

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

这让我想起,以前给老妈换手机,要教会她使用,可让我头疼了。

每次跟她说,这是查号码、这是打电话、这是听歌、这是看视频等等,她都记不住。我一度以为人年纪大了,记忆力不好,很难接受新东西。

后来,我反思自己,改变策略,只给她讲,她用手机会做的几件事情。

打电话,我只告诉她第一步按哪,第二步按哪,每一步有什么标记符号,再把常拨号码,设置成快捷键,每次只需一步操作。

结果,她居然记住了。

发现没?功能描述容易脱离用户使用场景,让人困惑。

所以,我们要从场景出发,围绕用户在具体情况下,要做的事情,告诉他怎么做就好了。

3. 系统思维

每个讲产品经理的思维方式,都会讲系统思维。可,真能用系统思维去思考的人,可谓凤毛麟角。

究竟什么是系统思维呢?

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

做产品时,如果只讨论功能,就是孤立地看待产品。

产品脱离了使用者,就没有意义。只有当我们把产品和使用者都考虑进去,才算是系统的思考。

用例的本质,就是将产品和使用者当成一个系统来看。

下面一起看看用例为何物吧。

二、解读用例图

1. 何为用例

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

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

换句话说,用例是参与者为满足自己的期望,而完成的事情。

所以说,用例不是功能,而是由参与者驱动的,是有明确目标的,是从用户视角看问题的。

比如,人喝水,大致要做拿杯子、倒水、喝这几个动作,人喝水是用例,拿杯子却不是,因为不会有人没有目的只拿杯子。

用例图可以对需求建模_需求分析需要画什么图[通俗易懂]

2. 用例图的构成

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

用例图可以对需求建模_需求分析需要画什么图[通俗易懂]

1)参与者,用小人表示

按官方文档的定义,参与者是在系统外部与系统交互的人或事物,可以是人、部门或系统。

产品面向的用户,也是在系统之外的参与者。

有时,系统内部也有一些人或对象,参与完成业务,这种称之为业务工人,并非参与者,需区分清楚。

2)用例,用椭圆表示

用例,表示参与者为完成某个目标的一系列活动。用例名称,以动宾短语出现,表示参与者做的事情。

用例是业务分析、需求分析、系统分析与设计过程的基本单位,粒度可大可小。

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

这有 2 个经验供你参考:

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

3)边界,用矩形表示

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

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

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

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

4)关系,用常见的箭头连线

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

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

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 的系统用例图就出来了。

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

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

四、总结

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

1. 为什么要画用例图

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

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

2. 什么是用例图

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

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

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

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

3. 如何画用例图

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

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

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

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

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

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

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

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

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

 

今天的文章用例图可以对需求建模_需求分析需要画什么图[通俗易懂]分享到此就结束了,感谢您的阅读。

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
如需转载请保留出处:https://bianchenghao.cn/82946.html

(0)
编程小号编程小号

相关推荐

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注