在进行 价值分析 之后，接下来要做的就是需求概要分析。这一步最重要的就是要梳理出核心用例和核心流程。需求概要分析主要分为三部分：

• 用例分析
• 用户流程分析
• 定义术语表

用例分析

这一步要做的是事情是在梳理出用户的角色后，通过分析需求，得出每个角色的用例。经过这一步之后，会产出一份用例图，其好处在于：

• 从图中可以看到，在这个需求里，每个角色都可以完成什么事情，这样即使需求的细节发生变更，也不会对这部分的分析有太大的影响。
• 通过用例图可以比较清晰地看到需求的全貌，不至于一下子陷入需求细节，对后面的流程梳理和详细分析都有很大的帮助。

每个人对需求的判断都不一样，那么怎么去判断一个用例图的好坏呢？其实这没有一个明确的标准，具体情况需要具体分析。不过，通过实践发现，好的用例图都会有一些特征：

• 每个节点的分支最多都不会超过7个，一般以3-4个为宜。用例数量过多，人的关注点就很难聚焦。当你发现自己列了一堆用例，远超于这个数字时，这可能是在提示你该对用例做抽象了。将零散的用例用一个概括性的用例来总结，会有助于你后续设计的时候，能根据需求用例做好模块设计。

• 好的用例不会陷入交互细节，会更注重业务规则。需求分析的核心是要分析需求的业务规则，业务规则不梳理清楚，即使界面做得再酷炫再友好，整个产品做出来也不会好用。所以，用例分析要关注业务规则，不要被界面带偏了。这一点很重要，也是用例分析里比较困难的一点。

• 用例图不要涉及技术点，除非产品的用户角色明确知道是一个研发人员。用例分析应该从用户视角出发，应该假定我们的用户完全不懂技术，当他来使用我们的产品时，他能完成什么事情。用例图反映的是用户使用产品能完成的事情，既然用户不懂技术，如果用例中出现了技术点，那么用户自然就不能完成这些用例。

• 用例图虽好，但也不是要面面俱到。图示的目的是为了提高可读性，让人能一下子理解到图示背后大量的信息。而一个需求涉及的细节点会有很多，一张用例图里面不可能塞满所有的细节。对于一些需求细节，是可以用文字、表格或其他图示的方式来表达的，不一定都要体现在用例图上。用例图只要能展示出用户角色的核心用例即可，其他细节可以有其他的方式来表达。

一开始都很难从一份逻辑性并不那么强的文字需求里面比较精确的提炼出用例。我们可以先过一遍需求文档和交互文档，将这其中的用例都先列出来，然后再将相似的用例进行归类，使其满足上述的特征。这样归纳出来的用例大体上不会相差太远。

当然，文档是死的，人是活的，用例分析更重要的是要和产品经理有充分的沟通，输出用例图之后，要和产品经理一起review这个用例图，以确保双方的理解是一致的。不要担心产品经理看不懂，用例图并不涉及任何技术点，要相信我们的产品经理有这个能力。

以下用一个实际的案例来说明如何从文字需求转化为一个能反映需求全貌的用例图。

视频会议中每个成员有角色的区分，分为组织者、主持人和普通参会人。其中组织者可以设置主持人，主持人可以转移身份给其他参会人。组织者和主持人可以对普通参会人静音和取消静音，也可以对视频会议中的所有成员静音。当普通参会人被要求取消静音时，需要经过普通参会人的同意才能取消静音，否则继续保持静音

从这个需求中，我们很容易得出需求中存在三种角色，普通参会人、主持人、组织者。而普通参会人能做的事情，主持人和组织者都能做，所以他们之间的用例可以是继承的关系，这样不同的角色，什么能做，什么不能做就可以通过继承的方式分隔开。主持人对于会中的音频操作会比较多，可以考虑往上抽象一层音频管理。另外我们注意到组织者是不能转让的，所以组织者并不能完全继承主持人的用例，为了突出这一点，我们可以在图中增加注释说明即可。图示的目的是方便人阅读和理解，只要达到这个目的即可。

由上可得用例图为：

用户流程分析

梳理用户流程，是在上述用例分析的基础上进行的。通过用例分析，我们知道用户有哪些角色，这些角色又可以完成哪些事情。但是用例图是静态的，它无法很好地展现出来，不同的角色是怎么协作的，而用户的操作流程在需求中又是很重要的部分，如果用户操作流程不合理，对用户来说就会认为这个产品不好用。因此，我们在分析完用例图之后，还要再梳理用户的操作流程。

通过用户操作流程的分析，我们可以看到，流程是否闭环，每个角色是如何协作的，中间环节如果出了异常，我们的产品是怎么处理的 等等。用户操作流程贯穿用户使用产品的整个生命周期，可以很好地帮我们发现需求中缺失的环节，以及有问题的环节。

那么，用户流程该如何梳理呢？

• 可以用 活动图/泳道图/流程图 来表示用户的操作流程。个人推荐使用泳道图，因为泳道图能比较好地反映出用户角色在流程中发挥了什么作用。而单纯的流程图和活动图则缺少了这一环节。
• 基于用例图来梳理用户流程。用例分析和用户流程分析两者是互补的。当分析流程的时候发现有环节不在用例图里面时，可能意味着用例分析遗漏了用例，这时候就需要重新审视用例了。如果你在用户流程分析中使用的流程都能在用例分析中找到，那么可以印证到你的用例分析大概率没有遗漏。
• 用户流程分析只需要体现出核心流程即可，不需要每个流程都面面俱到。我们只需要保证用户核心流程没有遗漏重要的环节，这样就可以了。需求的细节有很多，流程也可能有很多，我们抓住核心流程，就抓住了需求的关键。

还是以上面的例子来说明如何用图示来分析用户的操作流程，需求涉及的流程比较多，这里挑选其中一个比较典型的来分析。

以主持人对参会人取消静音为例，我们可以在泳道图中画出不同的角色。接着，从上面的用例图中，主持人角色的用例包含对参会人取消静音，但是没有体现出来普通参会人在这个场景下会做什么操作。由此我们可以知道，普通参会人这里会有两种选择，接受或拒绝。这样我们就可以根据上述需求，得出以下的泳道流程图。

需要注意的是，这里提到的流程，都没有涉及技术，对于用户来说，都是可以理解的用户行为。

定义术语表

在进行用例分析和用户流程分析的过程中，我们会提炼出很多的词汇，比如 组织者、主持人、普通参会人、静音、取消静音等。这些词汇对每个人来说，表述的方式可能都不尽相同。比如静音，可以表述为静音，也可以表述为关闭麦克风，但是这两者都是在说同样的事情。这就增加了很多不必要的沟通成本。在多人协作的团队里，术语不统一带来的沟通成本就更大了。为此，在分析需求的时候，我们要尽量将各方描述的术语、词汇都统一起来，这样大家对相同的事情有统一的描述，沟通成本就会降低很多。

我曾经就感受到术语不统一带来的极大沟通成本。比如，我所处的业务中，后端团队中有音视频媒体服务团队和非媒体服务的业务开发团队，客户端团队中有音视频SDK开发的团队和业务客户端开发的团队，这四个团队对 <视频会议> 这个事物的描述都不一样。后端业务开发团队定义为session，音视频媒体服务团队定义为room，音视频SDK团队定义为conference，业务客户端开发团队定义为meeting，明明在描述同一个事物，四个团队却有四种描述，这在协作中带来了极大的困扰和沟通成本。由此可见，统一业务词汇的描述，在多人协作的团队里面是多么重要。

接下来做什么

在完成概要分析之后，我们就梳理好了需求的骨架。接下来要做的就是往骨架里面填充细节。填充细节是整个需求分析里面最复杂、最繁琐的部分，很有可能充斥着各种意想不到的情况。要做好需求的详细分析，除了对相关业务要熟悉之外，还需要有一些方法来辅助我们发掘需求中遗漏的细节。这要到 [[业务需求分析中的三板斧-详细分析]] 再详细分析。