SERU需求分析是由徐峰老师于08年提出的一种以业务为驱动，实践为载体的需求分析体系。个人认为是一种理论最大化应用到实际业务中的方式：把传统的分析方法与建模理论应用到实际业务中，再对业务中的场景和问题结合uml,rup分析的方法进行业务建模，具体问题抽象化找到最佳的解决路径。有时候很多产品人在分析需求的时候只是凭一些逻辑分析的方法，通过几个原型就去规划信息系统或app的架构正是缺少需求理论分析的表现。

SERU需求分析意为Subject Area，Event/Report，User case三个需求分析创建的层次。分别对应了seru方法中三个重要的阶段： 明确目标和范围（开天辟地）、理清脉络和框架（泾渭分明）、填充需求细节（天圆地方）；整个需求体系可划分为需求定义、需求捕获和需求分析， 通过主题域、事件、报表/管控点、用例四个关键分解项贯穿分析、建模和描述过程。我认为这有点像画素描的过程，首先把范围以及大致的框架画成型，然后画出各部分的骨架以及结构形成大致的形体，最后再添加每一个层次上的细节形成一幅完整的画作。需求分析建模也是有种艺术的境界。

图1 SERU模型

明确目标和范围

第一阶段，明确目标和范围也就是需求的定义阶段，在项目立项初始对需求范围的梳理阶段。这个阶段的核心目标是通过划分主题域(subject)、标示出每个主题域中的业务事件(event)和确定报表(report)的方式明确分析的范围和目标。在上一篇文章我已经完整叙述了整个划分和标示的流程，在这里简单地说一下。笔者提倡一种自上而下、逐层分解的分析思路。 在这个阶段需要按照业务流程来划分，以”事”为线索贯穿系统，用uml中的构件图建模并表达业务流程抽象化的过程。首先应该按照业务的职责区块来划分子系统，然后根据实现关系及使用关系标示出各系统之间的接口并且在这个阶段分析各子主题域之间的关系，最后一步进行主题域范围的明确，界定每个主题域内进行的功能以及相关的事件并且要考虑到Customer与Worker之间的关系。找到系统中所有的客户，考虑这些客户会引起什么事件的发生，这些事件会引起Worker什么样的工作，将这些都考虑进来。然后再补充Worker主动发起的动作，那么一个系统的所有事件就能没有遗漏地梳理完整了。

图2 划分子系统，确定关系

理清脉络和框架

第二阶段，理清脉络阶段就是对业务粒度的细化。该阶段的任务就是对每个业务事件、每类报表进行人事物三者之间关系的分析，并标示出绝大部分的用例。需求先分解再提炼，第一阶段是需求分解并形成组织架构的阶段，在第二阶段就是对需求进行提炼的过程。前面说过分解是一个自上而下的过程，那么按照一种线索进行分解时多个业务时间就会产生相互交叠的情况。提炼就是一种自底向上的方式将每个业务事件的类进行提炼，抽取出共性的部分，建立针对整个系统的全局领域模型。我们可以使用uml中的领域类图、流程图和用例图来理清需求的结构框架和行为脉络，把业务事件列表以及报表输出成领域模型和用例模型。业务流程的梳理应该是每个产品人的基本功，在这里我推荐使用跨职责流程图以及完善的活动图提炼出业务模型。

图3 跨职责流程图

图4 活动图

那么通过模型，我们可以看到子系统内业务流转的过程，从而确定逻辑关系以及数量关系。总而言之，理清脉络的方式可以通过uml中各种图例帮助产品人员理清业务流程，建立起完善的业务逻辑模型。在这里要善于合也要善于舍，合并提炼相同的业务类，舍弃细节的干扰，整理出子系统内层次清晰的架构。

图5 梳理脉络并且进行建模

填充需求细节

第三个阶段是填充细节阶段，该阶段的任务就是填充每个用例的实现细节，以便于开发人员进行具体的实现。往往产品人员在考虑需求范围的时候只考虑到功能性需求，在这个阶段要对非功能性需求以及设计约束进行更细致的补充。这个阶段的任务是对用例模型、领域模型标示出用例、领域类的细节进行填充。对于组织行为需求的用例，我们要填充用例的事件流；对于组织数据(结构)需求的领域类，我们要填充它的字段与格式。很多产品人员在归纳用例的时候会采用“先人后事”的思路，这种方式很容易陷入误区。我们应该讲人（角色，参与者）和事（场景，用例）分开考虑，在确定他们的关联时，要先事后人地考虑。用例说明可以分为两个层次，第一个层次重点关注业务活动的变化以及其中的约束条件，另外一个层次就是交互/界面在视觉层次上的建模和细化。这两个层次其实是纵深对应的关系，先考虑业务和规则，再考虑前端的交互和界面展示。在这个阶段不单单是对业务的考虑，同时前置条件，后置条件，基本事件流程，拓展事件流程，子事件流程都是用例的核心部分。

图6 填充需求细节

总结

在需求分析，架构系统的时候往往我们产品人员会把大量的时间花在探索“怎么做”，很少对现实业务的整个过程进行思考。SERU需求分析的核心是从“人，事，物，接口”四条主线着手，沿着业务的脉络（业务主题域－业务事件/流程报表－业务活动－业务步骤）进行有机的分解，再以建模（构建－流程图－用例－事件流）的方式实现定向的需求分析。先从广义上对问题进行系统的拆分，以子系统的方式单独成一个封闭的集合，接下来考虑集合与集合之间的关系，最后完善集合内部符合业务流转的玩法。实际上我认为这个过程很像古代治国的方式，三个步骤对应着确定国家边界，国与国之间的延展，国内的治理。或许徐峰老师自身体现的也是一种设计系统架构的兵家思想。

本文由 @justinlam(知乎id:justinlam) 授权发布于人人都是产品经理 ，未经许可，禁止转载。