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 梳理脉络并且进行建模