功能需求

业务支持部分

系统要支持的是业务。在业务领域里，通常是先制定业务流程，再明确岗位与岗位职责。只有先清晰地梳理出流程，才能更好地分析需求。

首先要做的是业务场景梳理。一切脱离场景的功能设计，都是脱离实际的空中楼阁，难以落地并发挥出真正价值。只有定义清楚业务边界，才能定义清楚产品边界。很多时候产品定位模糊混乱，就是因为设计时对产品要解决的业务问题的边界和场景定义得不清晰。

在梳理业务场景的时候，产品经理可以采用四类触发四类流程法，以及新增/修改罗列法，识别出系统应该设计的业务流程。然后针对识别出来的业务流程，逐一做流程分析，并在流程分析结果的基础上，识别出业务设计、系统设计的业务场景，对这些场景进行优先级排序。

四类触发指的是一个业务流程的四种事件类型，几乎涵盖了所有业务操作的源头：

系统使用者为了完成某项目标而主动执行。
系统内部的定时器、调度器在特定时间，或者达到特定时间间隔时自动触发。
其他外部系统通过接口调用本系统而触发。
系统内部的某个核心对象或数据状态发生改变，从而自动触发后续一系列操作。

四类流程指的是根据核心目标和功能，业务流程都可以归纳为四种基本类型。每种触发事件最终都会落到这四类流程的一种或多种上：

在系统中创建一个新的核心业务对象或数据。
更改业务中已有业务对象的状态和信息。
从系统中获取或展示信息。
将数据从系统中物理删除或者逻辑归档。

所以，使用四类触发、四类流程法的时候，首先要识别核心业务对象，确定系统有哪些核心实体。

然后枚举触发事件。针对每个核心对象，从四类触发来思考：用户会主动对它做什么？系统需要定时为它做什么？外部系统会通知它什么？它自身状态变化会引起什么？

最终把触发事件映射到流程类型，将每个触发事件和流程的组合记录下来，形成业务流程清单。

新增/修改罗列法的核心思想是以系统的核心业务对象，或称为实体模型为中心，穷举出每个对象的所有新增和修改操作，也就是改变对象状态的操作，从而逆向推导出所有相关的业务流程和场景。

首先，识别核心业务对象，列出系统中所有最重要的名词或实体。这些通常是系统需要持久化存储的核心数据。

然后针对列出的每一个核心对象，思考两个问题：

这个对象在什么情况下会被创建出来？
这个对象创建之后，在其生命周期内可能会发生哪些变化？

这两个问题分别对应新增和修改操作。对于修改操作，要细致到具体修改哪个字段或哪个状态。

每一个新增和修改场景背后，都对应着一个或多个业务流程。所以最终要识别出这些场景，并把罗列出的场景转化为业务流程。

在整个业务场景梳理的过程中，最重要的是从业务流程到业务场景的梳理。也就是系统或产品需要新增哪些流程、修改哪些流程：

新增的流程是如何执行的？
流程中哪些业务活动需要系统支持？
流程中哪些审批分支判断需要系统支持？
修改的流程具体修改了哪些内容？
新增或者修改了哪些业务场景？

通常来说，一个基本场景等于人物加时间、地点、起因、经过和结果。

在大多数情况下，对于非常低频的需求和操作，可以将优先级调低。但在一些特殊情况下，即便需求频率很低，也要考虑加以实现。

完成业务场景梳理之后，就是业务流程识别。

企业或组织的核心价值，在于响应外部客户的服务需求，通过一系列协作满足服务需求，为客户带来价值，同时为组织或企业带来价值。业务流程的起点就是这些外部服务请求。企业或组织中每个成员的工作都属于某个流程，而且属于多个流程。流程由每个人的活动组成，每个活动又会有相应的执行步骤。

在梳理端到端流程时，有两个关键点：

完整。所谓端到端，实际上就是服务请求从提出到满足的全过程。判断一个流程是否完整，应该站在服务请求的立场，判断服务请求是否得到了满足，或者被拒绝。
边界。在识别业务流程的时候，涉及两种边界：一种是职能边界，也就是跨越了未涉及的业务域；另一种是系统边界，也就是不属于系统关注的部分。

为了更好地识别流程，通常会把流程分为主、变、支三类。主业务流程体现了外部客户的主诉求。变体业务流程实际上属于主业务流程，但因为其相对独立，不容易整合到同一张流程图里，所以通常将其识别为一个单独的业务流程。支撑业务流程提供一些边缘的、辅助的业务支持，属于一种锦上添花的业务。

但不要陷入“一个流程属于哪类流程”的细节争论。

识别出来之后，还要判断其是不是端到端流程。如果不是，需要进行相应整合。

所以，做业务流程识别，首先需要识别外部引发的主、变、支流程。业务流程大多会响应外部客户、外部员工的服务请求，因此需要先识别他们。

识别外部引发的主、变、支三个流程的典型策略，是首先梳理出本业务子系统有哪些外部客户，以及哪些其他部门员工会提出服务请求。

然后针对每个外部客户和员工思考：

其主服务请求是什么？
相应的端到端流程是什么？
主服务请求有独立的变体吗？
为了更好地服务客户，是否有辅助支持业务？

有些服务请求是由内部员工主动发起的，还有一些服务请求是在特定时间状态下发起的。所以，识别完外部流程后，还需要从内部进行补充。

做内部识别时先分析有哪些内部员工会引发流程，以及有哪些特定时间状态会引发流程。

针对每个内部员工、特定时间或状态，再分析最核心的业务诉求是什么；这些诉求有独立的变体吗？有相应的辅助支持业务吗？

除了上述内部流程和外部流程，还有一部分业务流程是为了实现控制、监督、管理等意图，所以需要单独识别。我们将其称为管理流程。

虽然管理流程的识别相对而言会更困难一些，但在实际工作中不会产生太大的影响，因为管理流程通常不会太多，而且可以通过与客户代表的交流快速补充出来。

如果做的不是项目，而是产品，就会更少有机会面对真实客户。这种情况下，最好能够引入相关领域专家，从管理的角度预先识别典型、常用的管理流程。

可以思考的角度主要有以下三类：

业务上线类的审批控制。
人、财、物资源的管控。
进度和异常的控制。

在上述处理过程中，可以使用流程图来表达。流程图是为了完成某一个特定任务而描述的相关活动，以及这些活动执行顺序的图形化表示。活动是对一组动作的描述，这组动作既可以是人做的，也可以是系统做的。而且活动之间要有明确的顺序。

业务流程图表达的是人和人之间的交互，目标是理清和设计业务。所以根据目标，绘制时要遵循以下 3 个原则：

一个人的活动之后，必须紧跟另一个人的活动，而不是一个人的多个活动之后，再跟着另一个人的一个活动。
绘图时不应该加入页面交互。但如果页面交互这个操作不做，业务就进行不下去，这时就必须加入页面交互。
业务流程图不应该体现系统做了什么。业务产品经理在绘制业务流程图时，只表达业务是什么，而不关心研究发现。但有时候系统会代替人做一些工作，这类工作要在业务流程图中体现出来。

首先是画主流程，也就是考虑主要业务流程，但不考虑分支流程和异常流程。并且这个主流程可以梳理得粗略一点，后续再完善细节。画完主流程之后，就要思考各种分支情况。

完善细节的时候要记得加入异常流程。分支流程是用户的选择，异常流程不是用户期望发生的。产生异常的原因可能是用户做错了，或者用户在执行过程中遇到了问题。异常流程的设计往往比主流程和分支流程的设计更复杂，设计内容也更多。

思考异常检查点时，要从活动和角色两方面来思考：也就是从第一个活动到最后一个活动，逐一思考是否有异常情况。这些异常情况可以根据异常检查表来排查，并且在每个活动里，还要考虑不同角色的异常。

同时，一个流程图所包含的活动一般不要超过 20 个，最好保持在 10 个左右。如果超出了 20 个，就要拆出来单独画。

最后一步就是加入泳道。泳道的画法是用竖线进行分割，然后在顶部写上角色名，每个角色所做的活动都要画在自己的泳道里。并且为了使表述更加简洁，可以把所有活动的主语去掉。在画带泳道的流程图时，只需要把主语提炼成角色，然后基于角色去画出泳道即可。

如果读者不能清晰地从流程图中看出他的工作，那么就最好加入泳道，否则也可以不加。在大多数实际工作里，绝大多数业务都最好不要加泳道，因为带泳道的流程图绘制起来时间比较复杂，而带来的收益很有限，仅仅能向业务人员更清晰地展示流程。

业务流程本身是分层的：

组织级流程：最宏观，画的是部门之间的协作关系，供决策层读者阅读。所以要以部门为维度，抽象层次由读者对象的管理视野决定。用来分层的参考框架是组织级别的流程，因为组织级别的流程可以展现部门间的协作。
部门级流程：中间层，画的是岗位之间的协作关系，供管理层读者阅读。业务流程分析应该在这个力度上进行。通常要以具体岗位为维度，与协作无关并且非原子性的活动不应该体现。
个人级流程：最底层，画的是一个岗位的工作步骤，应该在业务场景分析的时候进一步细化。通常来说没有带泳道，可以尽量细化。如果这个层级还是过于复杂，可以再进一步分层。

在判断一个业务流程是否画得过细时，需要思考两个重要问题：

这个流程是否与协作无关？
这个流程是不是独立可汇报的工作单元？

在大多数情况下，先有概括的业务流程图，再有细化的交互流程图。两者层次有高低。业务流程中的几步可以细化为交互流程中的若干步。虽然二者层次不同，但都在表达一项业务的整体或部分，所以也有一定的等价关系。

用例图和流程图之间也存在转化关系，但这种关系只是在部分情况下存在，因为二者的目的和层次不同。

用例图的目的是避免业务功能划分设计单元，流程图的目的是理清业务细节。一般来说，先有用例图，再根据每个用例完成该产品的单元设计。在做单元设计的时候，就可以考虑画流程图或者画原型图。

通常来说，用例图比流程图层次更高、粒度更大的抽象。

业务流程是信息系统交付的最小单元，所以对业务流程进行优先级判断，有利于做出更合适的迭代计划。识别完上述三种业务流程后，就需要判断业务流程的优先级。

在评估业务流程优先级的时候，最好根据业务流程是否为主营业务、发生频率高低这两个维度进行综合评估：

如果是主营业务并且频率高，优先级就是关键。
如果是主营业务但频率低，优先级就是重要。
如果是非主营业务但频率高，优先级就是有用。
如果既不是主营业务，频率也低，优先级就是一般。

做业务流程分析，关键是要理清业务流程中的要素。

首先是基本要素。当一个流程中有了分工，必然会将之前一个人负责的事拆分成一系列更小、相对独立的任务，这就是活动。分析一个业务流程时，首先需要明确整个流程中涉及哪些分工，每个角色负责执行什么活动，然后选择合适的流程图表达出来。

当然，这些活动之间不是独立的，而是存在顺序执行、并行执行、异步执行等多种可能，这就是协作关系。在流程图里，表现为各个活动之间的连线。

协作过程不是一成不变的，还需要根据实际情况进行处理，这就是流程中的分支。

在协作过程中，各分工之间需要传递工作产物。流程管理者会制定一些表单、单据，以明确职责，这就是产物关系。

其次是管理要素。在流程执行过程中，可能会出现一些意外和异常，所以事先需要制定一些备案，以备不时之需，通常可以另附文字说明。处理过程复杂的话，也可以另绘一张异常处理流程图。

在绘制流程时，不要使用“岗位名称 + 审批”的样式来命名一个审批，应该识别出审批内容和审批意图，这样才能真正分析到位。

做业务流程分析，首先要选择流程图的描述方式。业务流程分析的目的不是画出活动图、数据流图，这些图只是分析的一种结果。

如果分析的是业务流程图，大部分时候需要强调的不仅是分工，还包括每个角色所要执行的活动，所以应该选择跨职能流程图或者活动图。绝大部分管理者都能看懂，甚至绘制跨职能流程图，所以这个图与业务代表的沟通最无缝。绝大部分管理者只需要简单介绍，就能看懂活动图，所以更建议采用活动图。

如果涉及系统之间的业务流程，就需要强调交互过程，最好采用顺序图。如果强调的是数据处理过程，最好采用数据流图。

然后是勾勒流程主体。在实践过程中，最好在这一环节找到客户代表或者业务专家，请客户代表和业务专家讲述流程，同步在纸上画出流程的主脉络。这个时候只需要做到明确分工、活动以及最基本的协作关系，不要打断，也不要陷入细节，用最简单的方式勾勒出主脉络，把分支、产物关系、异常、审批规则都放在一边。

然后沿着主流程进行发问，看看是否存在分支情况，边问边修正。除了要问分支，还应该问问各协作之间的产物关系，然后将其补充出来。还可以针对异常审批规则等管理要素进行发问。

最后，产品经理自己讲一遍流程，确保与客户代表和业务专家达成共识。

在画出这个主脉络时，要么全使用岗位名称，要么全使用部门名称，不要混合使用。如果使用部门名称，应该尽量保证所有部门都是平级的。

活动命名应该采用动宾结构。每个活动都是工作任务，所以不能使用名词或者名词短语来命名。

在绘制整个业务流程时，暂时不要考虑系统边界。

整个流程应该先从服务请求者开始画起。如果流程中存在很多主从活动，这时不应该把主从活动都画出来，而应该只留一个。但具体留哪一个，取决于流程图要给谁看。

下一步是补充事中管控点。需要花时间，通过沟通讨论，对流程事中控制的管理要素进行分析。一般是和业务专家、客户代表就异常问题进行交流。主要思考方向是：是否存在完全不能按该业务流程执行的情况？如果存在，应该怎么处理？最好用文字或者另一张流程图来描述异常处理流程。

在此期间，把重点放在审批上，可以询问现在有哪些审批点，还有哪些环节存在执行风险，需要增加什么样的审批，由谁来审批合适。

最后，还要沿着流程思考一下是否需要设置一些规则。从类型角度划分，规则主要分为两类：一类是决定是否能够执行、如何执行的行为规则；另一类是操作权限、数据构成等数据规则。具体而言，可以从以下几个角度逐一思考：

协作间规则：用于控制流程协作的规则。
业务活动执行规则：用于在执行各个业务步骤时需要遵循的规则。
数据规则：针对表单、文档生成产物的格式、内容进行限制的规则。

再下一步是分析流程执行过程的监管要求。管理者为了更好地监督、控制流程执行，会有一些相应的管理需求，这时候也会产生一些功能性、非功能性需求。所以产品经理在流程分析完成之后，可以就这方面进行交流探讨。

这方面的分析主要有三点着手点：

进度与效率。
执行异常。
其他管控需求。

最后一步是业务流程优化。要想解决问题，首先就要发现问题。最典型的策略有四种：

找到业务流程中不产生效能、浪费、低效的环节，然后想办法清除。
对频率最高的环节进行优化。
把相互依赖的环节整合在一起。
把人做起来麻烦的事情交给计算机来干。

梳理业务操作可以使用状态图。流程图梳理的是一项业务的大致过程，状态图梳理的是一项业务的细致操作。

状态图也被称为状态机图，描述一个对象所处的状态，以及用什么操作可以促成状态转变。所以，状态图就是用图形来表达事物的状态，以及什么操作可以转变状态。

在描述状态的时候，用一个略方的圆角矩形表达状态，并在矩形内写上状态名称。状态图里的圆角矩形要比活动图里的圆角矩形更方一些。状态里面会有“已经”“未”“待”等字眼，很多时候这些词是可以省略的。而且状态名称有等价的多种表示方法，为了避免错误拆分为多个独立状态，应该把这些表述合并为一个复合状态名称，从而确保状态定义的一致性和准确性。

状态是可以转移的。状态转移常常是通过人的操作来实现的，人的操作其实就是人的一个活动。既然是活动，表达方式就应该遵循活动的表达方式，也就是按照“主动宾”来写，强调谁做了什么事。在图上就是画一条带箭头的直线，并在直线上写上转移的操作，表示一种状态能转移到另一种状态。当然，状态之间的转移不仅可以由人触发，也可以由系统触发。

表示开始的符号是一个实心的小圆点，从小圆点向下引出一条带箭头的直线，直接连接第一个状态。开始本身并不是一种状态，只是想让读者明白状态图从什么地方开始。所以开始在图里只能有一个，并且不可以被忽略。

表示结束的符号是一个带圆框的实心小圆点。结束本身也不是一种状态，只是想让读者明白状态图到哪里就结束了。所以结束仅起到提示作用，可以没有，也可以有一个或者很多个。当然，用什么状态来标记结束，这件事并没有绝对的标准。一般来说，把正常流程中的最后一个状态标记为结束。

内部转移一般用带箭头的回环表示，表明用户虽然可以操作信息，但并没有改变其状态。

状态的值必须是有限集合，状态的所有枚举值必须能够涵盖所有实际可能的情况，并且状态值之间要互斥，不能出现二义性。

如果想要更准确地描述，状态本身还可以存在子状态。状态应该能够持续一定时长，而不应该是很快就结束的瞬时态。

状态有三个注意点：

一个具体事物就是一个对象，对象就要有状态，并且状态只针对该对象。只有对象确定了，才有该对象的状态。所以产品经理一定要把握住这一点。
状态图是用来表达对象的状态的，并且一个状态图只能表达一个对象的状态。所以为了避免在一个状态图中表达两个对象的状态，最好在状态图里写上对象的名称。
流程图用菱形来表达判断和分支。状态图在有的资料里加了菱形，但实际上并不建议加入菱形标志。如果不加入菱形标志，可以使状态图的表达更加简洁，没有歧义。加入菱形标志就会导致状态图的表达逻辑出现混乱。

状态图并不等于流程图，二者在内容使用上存在区别。状态图表达的是状态之间的迁移，而流程图表达的是活动之间的迁移。在状态图上表示转移的线上写的内容，对应的就是流程图中的活动，两者的内容可以完全等价。流程图表示转移的线上通常不写内容，只在进行判断的时候，要在线上写明判断条件。

在使用上，包含若干步骤且判断条件多的流程，可以通过画流程图来理顺思路，避免设计错误。如果每个对象都有很多种状态，那么可以通过画状态图，明确不同状态下的操作。

在二者上使用时会有配合。通常来说，先画流程图，再画状态图。流程图梳理大致流程，状态图梳理细致操作。但是什么时候画状态图，什么时候画流程图，本身并没有绝对的标准。

在绘制状态图的时候，一般按以下步骤进行：

先绘制主干状态，忽略一些次要的分支状态。
进行状态拆合：先用两个词表述状态，再确认这两个词是要拆分还是不拆分。
完善分支状态：分支状态可以通过寻找和主干状态相反的状态来获得。
完善角色和操作。一种状态有可能转移到任何一种状态，包括转移回自己。任何角色都可以操作，也都可以通过操作触发状态转移。所以，想要找到所有操作，需要思考：每个角色能否将当前状态转移到任意状态？也包括当前状态。

状态一般用“主语 + 状态”来表述，通常主语占一行，状态占另一行；也可以用两个短语来描述一个状态。

如果两个状态之间可以相互转移，就需要画两条单行的、单向的箭头线。这个时候可以简化：在两个状态之间画一条两端都有箭头的线。

任何状态都可以转移到某个状态，这会导致连线很多，所以可以在状态旁边加备注，说明在什么条件下可以达到此状态。

最终要输出业务流程描述文档。

第一部分是图表部分。主要有三个字段：

业务流程名称。
流程简要说明：描述流程的起点和终点，以及流程目标概述。
业务流程描述：选择合适的模型，呈现业务流程分析的结果。在流程图里，将呈现分工、活动、协作、产物关系、分支、审批这 6 个要素。

第二部分是附加描述部分。可以根据需要，对协作间的产物关系进行详细说明。这部分中也应该对这个流程中相关的规则进行描述，包括类型、规则、数及备注。

业务流程分析与优化完成之后，下一步就是业务场景识别。

用例、用户故事，这些现代需求分析技术的精髓在于用户视角以及业务场景。这就要求产品经理不再关注系统提供什么功能，而是用户在什么场景下需要系统提供支持。枯燥的非用户直接相关的功能性描述，只能被人拒之千里之外，最终导致业务支持顺畅，影响需求的获取理解。而生动的用户视角的使用场景或业务场景描述，才能与用户产生共鸣，实现以用户为中心的需求获取与理解。

业务场景识别这个任务不能被跳过，因为在以业务为中心的需求分析方法里，是封装需求的分子级单位。

首先要基于流程图识别系统角色。可以从以下几个问题来分析：要对这个流程提供支持，至少要涉及多少用户？对于非必须的用户纳入系统支持有什么价值？不支持有什么不足？对于系统而言，这些用户扮演的什么角色？从权限系统的角度如何抽象这些角色？

然后是基于流程图识别业务场景。沿着业务流程对每个活动分支判断点进行分析思考：哪些业务活动需要系统支持？哪些业务活动需要部分支持？审批点是否属于系统内？判断点是否为独立环节？

再下一步是补充业务场景，除了由人触发的业务场景，还存在特定时间、特定状态触发的业务场景。这类场景可能没有在流程图里表现出来。在完成了前面两步之后，还有必要再花一点时间补充出这类易于遗漏的业务场景。但并不是每个流程每个系统都存在这种业务场景。所以在使用这个方法的时候，千万不要抱着非得找出这种场景的心态。

最后一步就是绘制用例图片段，并概述业务场景。当所有业务场景都被识别出来之后，就可以使用一张用例图片段来呈现结果，并对里面的业务场景逐一进行概述性说明。用例图最核心的元素就是 Actor （角色、参与者）与用例。

Actor 与用例之间的关系分成 Actor 指向用例，以及用例指向 Actor。Actor 指向用例读作“某 Actor 可以执行该用例”，表示该系统角色可以通过系统完成相应的业务。用例指向 Actor 读作“该用例将调用系统或通知某 Actor”。如果 Actor 是由人扮演的，则一般指用例在执行过程中会通知到他；如果 Actor 是系统扮演的，则一般指用例在执行过程中将调用该系统。

Actor 与 Actor 之间只有一种关系，就是泛化，表示角色权限继承。当一个低权限的 Actor 能够执行一部分用例的时候，一个高权限的 Actor 除了能够执行这部分用例，还可以执行一些其他用例。如果直接连线就容易出现交叉线，这个时候就可以使用泛化关系来表述，读作“某某 Actor 继承了某某 Actor 的权限”。在任何时候，Actor 与 Actor 之间都不应该直接连接。如果它们之间有协作，那么可以思考这种协作是否与系统有关，如果有关，就在它们之间加一个用例。如果无关，就不用操心，毕竟这属于系统之外的事情。

用例与用例之间有包含、拓展、泛化这三种关系，并不存在使用关系：

包含关系表示的是一定会执行的公共子事件流，并且这一个信息通常只有开发团队关心，所以在给用户看的用例图里可以省略这个关系。甚至可以在写用例描述的时候，再抽象出这种关系。
拓展关系表示的是不一定会执行的拓展事件流。一般会出现在两种情况。第一种情况是这个拓展的部分具有极强的独立性。第二个情况是，其实现优先级比较低，抽取出来告诉用户，开发团队将放在第二步实现。拓展关系通常会呈现给客户看。
泛化关系表示公共的事件流。在实际使用里，可以直接给出两个抽象前的用例，也可以把抽象前后的用例都呈现给用户，但绝对不能只给出泛化用例，这样会导致用户感到疑惑。

完成用例图片段之后，还应该从以下三个角度进行补充说明：

Actor 与最终用户的映射。因为 Actor 是相对于系统的角色，可能是从权限系统角度来抽取的。所以如果引入了新的命名，还应该说明扮演这些 Actor 的是哪些最终用户。
用例概述。针对每个识别出来的用例，应该用一句话概括它的目的，以便读者快速理解。但是被包含用例、拓展用例、包含用例除外。
用例优先级。根据这个用例是否是主营业务、执行频率、是否必备这三个点来进行评估，赋予其相应的优先级。一般采用四级划分标准，即一般、有用、重要、关键。

管理层用户关注事到事的逻辑，所以更愿意看到流程图。操作层用户则更关注人到事的逻辑，所以用例图适合给操作层用户阅读。

最终，这个环节要输出业务流程内的业务场景描述文档。

文档分为两部分。第一个是图表部分，选择合适的模型，通常用例图，呈现业务场景识别结果。第二个部分是业务场景描述部分，对识别出来的、通过用例来成像的业务场景（也可以称为业务功能）进行简单描述，包括四个栏目：

类型：说明是新增的还是修改的。
用例名称。
用例简述：说明业务场景的核心业务意图。
优先级。

针对每个业务场景，要说明由什么角色使用。因为这些角色是抽象的，所以最终要与用户映射起来。

业务支持部分的最后一个环节是业务场景分析。

在需求分析里，先梳理出整个使用场景的各个步骤，能让用户更有代入感地发现功能需求。将场景细化为事件流：先整理出用户预期的正常步骤，然后写出变化情况。针对每一个步骤，站在用户的角度思考他们会遇到什么问题，或是面对什么样的挑战。针对这些问题，思考系统应该提供什么样的功能。

业务场景分析这个环节不能被跳过，因为在以业务为中心的需求分析方法里，这是对封装需求的分子单位进行分析的。

首先要概述业务场景，主要是思考三个大问题：

业务目的：在这个业务场景里，用户要实现什么样的业务目的？用一句话概述用户执行该业务场景所要达到的业务目的是什么。最好使用用户的语言，重在传达用户的意图。
前提条件：执行该场景有什么前提条件？结束前需要保证哪种状态？对于一个业务场景而言，有的时候是有执行条件的，有的时候只是在业务场景结束前必须保证满足某个状态。在用例分析理论里面也有相应的点，分别称为前置条件和后置条件。但存在这些条件的业务场景，或是用例并不多，大概只占 30% 左右。前置条件指的是用户在执行该业务场景之前，系统需要检查什么状态；后置条件指的是用户在结束该业务场景之前，系统需要检查以确保什么状态。
相关角色：除了场景执行者之外，还有谁关心它？关心什么？在一个业务场景里，除了执行它的用户，可能还涉及上游、下游、管理者、协作者等其他关心该场景的人。对于关键的业务场景来说，还有必要思考他们有什么关注点，是否需要提供一些功能来满足这些需求。但并不是每个业务场景都需要进行这样的分析。

在概述业务场景之后，就要细化业务场景的业务步骤。这里可以按照场景、挑战、方案的顺序进行分析。

首先是展开场景，要回答以下问题：用户习惯的步骤有什么？有什么类似的场景可以移植？最典型的、用户预期内的业务步骤是怎么样的？针对各个步骤，有哪些潜在的变化情况？有没有异常情况？异常如何处理？

然后是识别挑战，要回答以下问题：针对目标用户场景中的各个基本步骤、拓展步骤，会遇到什么困难？针对目标用户在该场景的各个步骤中存在哪些相关挑战，需要产品提供支持？

最后是制定方案、导出功能，要回答以下问题：针对这些困难和挑战，产品可以通过哪些功能帮助目标用户解决它们？解决方案有多个吗？哪些方案最有效？哪些成本最合适？投入产出比大于 0 吗？

在写作过程中，要重在人机交互，而非人机界面；重在用户意图，而非用户动作。

人机交互指的是人、系统分别做什么；人机界面指的是系统的 UI，不适合用文字写出来，而应该考虑用初步交互设计来代替。

而且不是写程序，而是进行结构化陈述。不要用“如果……那么……”之类的结构，改用拓展事件流表示；也不要用“重复执行……”之类的结构，改用子事件流表示。

细化完业务步骤后，就需要遍历步骤，分析其中的困难并导出功能。通常从以下两个角度来思考：

在各个业务步骤变化以及异常情况下，会遇到什么困难？针对这些困难，系统需要提供什么样的功能支持？
是否存在不能按以上步骤处理的情况？这种情况需要系统提供什么样的功能支持？

接下来是识别环境与规则。质量要求和约束是有局限性的，在分析一个业务场景时，应该考虑环境业务特点给系统实现带来的要求和影响。通常可以从以下三方面着手分析：

性能相关：主要包括执行该业务场景的人数、典型业务量、达到峰值时的业务量、密度。特别是一天内业务发生频率不一定时，需要说明。
易用性相关：主要考虑用户的成长经历和相关系统使用经验。这对于系统易用性设计有指向性作用。
部署环境相关：说明用户所在的网络、软硬件等相关环境。

最后一步是分析实现方式，完成初步交互设计，以此起到澄清需求的作用，并作为后续专业交互设计师完成最终设计时的建议和约束。初步交互设计要包含以下几个方面：

交互过程，也可以理解为界面流转图，用来表达产品经理希望系统如何实现该场景的所有业务步骤。
静态快照，即每个页面上的具体内容，可以使用纸上原型呈现。
设计说明，针对每个页面内容和界面流转进行一些描述。核心在于说明自己为什么这样考虑，以及这是一种建议还是一种约束。

上述所有工作完成之后，本环节就要输出业务场景分析文档。

场景概述：说明该场景或任务的名称、执行目的、前提条件，以及出现的频率。
场景分析：以“场景/任务 + 问题/挑战 + 方案/所需功能”的形式整理分析结果。子任务/子场景一栏，填写该场景最预期的步骤，以及每个步骤的问题。任务变体/拓展事件流里，填写一些拓展事件流及相应的问题。最后，在所需功能描述部分写出这些问题和挑战所需要的功能。
关键例外：就是在该场景中，一些特殊的、需要开发特定功能来支持的例外场景。但这一部分并不是必须的。需要注意的是，这些场景并不是正常执行过程中的分支，或者我们可以称之为变体，而是一种例外情况。

对于业务系统而言，场景就是操作层用户要执行的任务。因此，在这个文档里，用“任务”一词代替“场景”一词，可以更方便用户理解。

管理支持部分

软件系统对管理的支持，主要体现在三个方面：

通过增加管理流程，在事前规避风险。
通过规则和审批，在事中控制风险。
通过数据分析，在事后总结优化。

所以，管理需求分析是信息化系统需求分析中的一项重点。但如果开发的系统不包括通过数据分析来支持管理，那么这个任务可以被裁剪掉。如果开发的系统是经营分析、大数据分析等项目，那么这个任务就是重中之重。

数据与信息是有距离的，而这个距离就是“Why”所带来的。需要多问用户：为什么要看到这些数据？这些数据有什么用？这样必将会看到另一个世界，也就能更深入地理解其中的需求。

产品经理在做业务报表、BI、数据挖掘、数据仓库、大数据分析时，核心在于把握用户想要什么信息、他的管理意图是什么，这样才能实现有效分析。这也被称为管控点。

首先需要识别管理需求。识别管理需求的第一步是标识出潜在的管理者：

在子系统层面寻找相关的决策层、管理层用户。
在流程层级寻找相关的管理层用户。
在整个系统层级寻找相关的决策层用户。

找到系统所涉及的管理者之后，还应该判断他们属于管理型还是经营型，因为不同类型的管理者关注的重点不一样。

管理自我这一级别，准确来说并不属于管理者，而是员工。只不过作为员工，也应该做好个人的时间管理、计划管理、情绪管理等。这些人不会在管理需求分析任务中被关注到。

管理团队是管理型管理者的第一级，通常负责带领一支小团队完成上级交办的特定任务。比如军队里的班长，或是开发团队里的 Team leader，都属于这类管理者。这类管理者关注团队管理、人员管理，在管理需求分析任务中可能会少量涉及。

管理事是管理型管理者的第二级，开发团队里的项目经理就是这一管理层的典型。他们对一件事负责，人、进度、资源都会涉及，在管理需求分析任务中会经常遇到。

管理职能是管理型管理者的第三级，开发团队中的需求分析部经理、测试部经理都属于这个层级。他们关注许多事物，也关注人、资源、进度，在管理需求分析任务中会经常遇到。

管理业务是经营型管理者的第一级，会涉及经营性指标，更加关注客户、产品、供应商等经营主体。这里的“主题”不是“主体”，反而对具体执行性事务关注比较少，在管理需求分析任务中会经常遇到。

管理业务群是经营型管理者的第二级，与管理业务这一级最大的区别在于，它将管理多业务，一般对资本均衡方面更重视，想法也更宏观。通常他们关注的都是决策相关的管控点。

标识出所有相关的管理者之后，接下来可以通过访谈、侧面了解的方法，标识出他们希望通过系统实现的管控点，或者想通过数据分析实现的管理意图。

首先可以通过对管理者的职位职责及考核指标进行分析，标识出所需的管控点；进一步可以从问题入手分析：如果是管理型管理者，可以从管理问题着手；如果是经营管理者，可以从经营问题着手。也可以多花时间了解同行及相关行业的数据分析应用，特别是一些大数据应用，从中获得灵感。

完成管理需求识别之后，就需要分析数据指标体系。由于管控点是“Why”，报表等数据分析手段是技术上的“How”，两者之间存在断层。补充这个断层的方法就是思考出指标，这样就可以形成有效衔接。

另外，实际管控点和指标之间可能是多对多的关系，也就是指标是可以复用的。拿到一个管控点的时候，应该从正反两方面去进行分析：

正面：迎难而上，思考分析业务设置合理性需要哪些信息。
反面：逆向思考，思考业务设置如果不合理会出现什么情况，这些情况可以通过哪些数据反映出来。

有些产品经理能够发现潜在的指标，但有可能受限于数据源、技术手段，暂时无法实现。作为待解决的问题，或许在下一代产品、下个项目里就有了合适的解决方案。

另外，还可以换一种角度思考。如果没法详细获得竞争对手的数据，还可以另辟蹊径来解决。比如，考虑通过客户的意见单来统计。

确定数据指标体系之后，就要明确实现方式，并细化数据收集或分析的需求。

如果数据源和条件都确定，就选用报表的方式。
如果数据源确定、条件不确定，就使用 BI 的方式。
如果数据源和条件都不确定，就使用数据挖掘和大数据的方式。

做需求分析时，应该有效针对不同的管理者来标识管控点，然后主动学习一些统计学、群体动力学等方面的知识，跟大数据分析团队一起探讨潜在的业务解决方案，才能够推动大数据应用发挥更大的业务价值。

在执行完管理需求分析这个任务之后，就应该列出所有找到的管控点。使用管控点列表文档来整理，每个子系统一份，包含以下字段：

类型：说明该管控点是经营类还是管理类，也可以细化到下级分类。
名称：也就是管控点名称。命名的时候应该能体现其意图，避免出现统计、汇总之类的技术性动词。
简要说明：说明该管控点的主要用户及其使用价值。
优先级：包括关键、重要、有用、一般这四个等级。根据使用频率、业务价值来评估。如果有必要，还可以引入等级最低的镀金级。

在识别出所有的管控点之后，接下来就应该针对每个管控点进行分析。用管控点分析文档来整理，要有这么几个字段：

名称：也就是管控点名称。命名的时候应该能体现其意图，避免出现统计、汇总之类的技术性动词。
相关干系人：指出这个管控点有哪些管理层用户会用到。如果他们的阅读重心不同，还需要用文字来指出。特别是相关干系人包含决策层和管理层的时候，他们的角度往往都会有所不同。
管控点目标：要清晰地从业务价值出发，以价值态的形式说明各个干系人希望通过这个管控点达到的业务目标。
所需业务报表：管控点通常需要一些指标来分析，而指标则由一堆数据来体现。如果这个管控点所需的数据分析可以从相对固定的数据源获取，并且可以采用相对固定的查询条件来分析，那么就可以简单地使用报表来解决。如果管控点可以用报表实现，那么产品经理就应该在此列出自己认为所需的业务报表，以便后续进一步分析。
BI 数据仓库、数据挖掘需求：有一些指标和数据分析要求无法简单地使用报表来实现，就需要使用更复杂的手段。如果要采用 BI、数据仓库、数据挖掘、大数据等技术，那么产品经理就应该在此明确，自己认为需要对哪些指标、哪些数据进行挖掘，以黑盒视角明确相关需求。

只要系统里存在业务报表需求，就需要进行业务报表分析；如果没有这个需求，自然就可以跳过。

首先，要明确报表的使用场景，也就是谁使用、为什么使用、使用频率如何。谁使用的问题，如果深究一下，会涉及报表生成者和报表阅读者。当存在这种情况时，报表生成者可能会出于考核业绩，对数据进行一些伪造。在系统实践时，需要采用相应措施来应对。如果存在这种情况，一般也不应该直接写出这类问题。

报表的业务意图实际上可以追溯到管理需求分析任务中所标识的管控点及管理意图。但由于实现一个管控点通常需要一组报表，甚至需要借助 BI、数据挖掘等手段，一张具体的报表应该只体现一个子意图。作为产品经理，应该从业务价值的角度来描述，以便开发人员更好地理解。

最后是使用频率如何的问题。使用频率决定了性能要求，越常用的报表，用户肯定对其速度要求越高。如果很难写出“必须在多少秒内响应”之类的描述，也可以写出使用频率。

然后是分析报表的内容。报表的本质不是事件流，而是内容。即生成报表之前需要输入什么条件？从哪里得到所需数据源？生成哪些数据，以及格式、计算方法是什么？

生成报表所需要的输入条件，可以使用界面来呈现，也可以说明需要哪些查询条件。数据来源应该直接列出该报表应该从哪些数据表中获得基础数据。如果涉及大量的数据表，也可以考虑画一张领域类图片段，把涉及的数据表及数据表之间的关系都呈现出来。

另外，还应该说明统计口径，也就是对哪些数据进行统计。还应该逐一列举出报表中各个数据项，以及每个数据项的格式、计算方法。

最后是整理报表的输出需求。首先，可以用一张表头来呈现报表的输出要求。其次，应该考虑是否要讲清以下内容：这些细节都可能带来返工，值得提前做出说明。

屏幕显示和打印版本是否有区别？
图表显示和打印有没有什么不同？比如图表需要打印黑白版本，那么就需要考虑显示是否清晰。
分类小计如何处理？
如果报表有多页，打印的时候每一页是否要页码？是否要表头？

完成上述分析之后，就要输出业务报表描述文档，包含以下三个部分：

报表概述：包括报表名称、使用者、业务意图、使用频率这四个栏目，也就是讲清楚报表叫什么、谁会使用、用来干什么、多久一次。
报表实现分析：包括报表输入条件、报表输入格式要求（可以使用原型）、报表数据来源分析（领域类图片段）、报表数据项说明这四个栏目。也就是说明生成这个报表之前是否需要输入查询条件，生成的报表是什么样的格式，报表的数据从哪里来，以及每个内容项的格式是什么。
报表相关要求：主要包括报表是否要打印，是否有特定的图表要求，图表是否要打印；如果生成的报表有多页，应该如何处理；分类小计如何处理；是否存在特殊排序需求（用升序、降序无法解决的需求）；在统计口径方面是否有需要交代的地方。

维护支持部分

维护支持部分主要是做维护需求分析。除了一些生命周期很短的临时系统、过渡性系统，运行维护是系统必然会经历的阶段。所以要识别有哪些维护场景，然后分析这些维护场景。这些通常都是必须要做的。

但是对于同一类系统而言，只要维护场景可以多次复用，每个项目只需要做少量修改即可。

首先要标识配置性维护场景。配置是为了应对变化，所以标识配置性维护场景就应该从变化入手。系统变化从里到外主要有以下几个方面：

用户群变化：使用系统的用户发生改变，他们的职位发生改变，权限也发生改变。所以要想维护用户角色权限，也就相应需要一些配置功能。权限核心包括功能权限、数据范围权限、分配权限的权限。
流程变化：企业的流程总会根据自身在发展过程中关注点的改变而不断调整，以满足阶段性管理目标。所以如何有效应对流程变化给系统带来的影响，是需要提前考虑的。
数据变化：随着企业业务的不断发展深化，需要在系统中引入更多的数据项、数据细节。因此，如何应对未来数据项的增加、数据构成的调整与变化，也是需要提前考虑的。
法规变化：企业在经营过程中，有时候会涉及法律法规的要求。而法律法规在一定时间周期内，可能会更新或出台不同的实施条例。所以应当考虑这些法规发生变化时，如何有效应对。

然后是标识系统运行阶段维护场景。在系统运行过程中，运维团队有责任保证系统安全、可靠、稳定运行，因此需要一些系统工具来支持这些工作。这方面可以从正常时和故障时两个角度展开分析。

正常时主要涉及两个运维场景：

运行状态监控：通常可以从服务（服务是否可用、负载是否正常等）、网络通信（网络连通性、网络传输速度等）、数据库（数据库可用性、负载是否正常等）、客户端（客户端可用性、是否存在未授权连接等）等角度逐一识别分析。
数据备份：应该从备份内容、备份周期、是否需要远程灾备、数据恢复相关需求等角度进行分析。

系统运行时必然会出现各种各样的故障，因此也需要故障定位、排错、故障恢复以及应急措施的支持。

最后是其他维护场景，比如第一次安装部署系统时，需要提供什么样的工具支持？系统升级时需要提供什么样的支持？每次升级时是否需要对原有系统进行数据迁移？是否需要支持双系统并行运行等。

最后要输出一个维护需求描述文档。这个文档可以偏向技术语言，主要用于运维团队进行确认。文档由以下几个部分组成：

配置类需求：包括用户权限配置需求、业务流程配置需求、业务规则配置需求、业务数据配置需求、其他可配置需求。
运行阶段维护需求：包括运行状态监控需求、数据备份与恢复需求、故障定位与排错需求、故障应急方案需求。
其他维护需求：包括系统初始化支持需求、系统升级支持需求、系统迁移支持需求、其他维护需求。