12.1 SERU过程框架的理论基础
Subject Area：主题域。核心思想是根据业务区域分解系统，使系统的各个部分在业务上保持相对独立，降低耦合。从某种意义来说，Subject Area也可以理解为子系统，只不过更加强调业务分析，而非功能分解。
Event：业务事件。通过业务事件的标识，就能找到流程，通过流程就能将不同场景串联起来。
Report：报表。
User Case：用例。用例可以作为需求的最小单元，一个业务活动，一个具体的报表项，一个具体的接口等，都可以称为用例。
12.2 SERU过程框架全景图
12.2.1 需求定义阶段
对应与软件生命周期的项目立项阶段。
12.2.1.1 核心工作
》判断系统规模，决定是否划分主题域。
》如果需要，则根据业务特点划分主题域。
》讨论每个主题域的范围，可以使用上下文关系图。
》讨论每个主题域，列出业务事件列表，报表类型列表。
12.2.1.2 主要产物
》构件图：用来表示主题域之间的关系，通常只有一张。
》上下文关系图：用来表示每个主题域的范围。
》业务事件列表，报表类型列表。
12.2.1.3 主要访谈对象：中高层用户代表。
12.2.1.4 重要信息
》组织结构图，分管领导，有助于主题域的划分。
》部门职责说明，有助于主题域之间的服务接口标识。
12.2.1.5 其他提示
这个阶段花费的时间是比较简短的，不求标识出所有业务事件和报表类型，重点在于从宏观层面理解业务，标识出最重要的业务事件和报表。
12.2.1.6 裁剪说明
》对于规模较小的系统，不必划分主题域。
》对于涉及原系统的项目，可以标识出新主题域和原有主题域。
12.2.2 理清需求框架和脉络阶段
对应软件生命周期中的需求捕获分析阶段。
12.2.2.1 核心工作
》针对每个业务事件进行流程，业务实体，使用场景分析。
》针对每个报表进行业务实体，使用场景分析。
》将前面标识出来的所有场景(用例)进行抽象，得到用例模型。
》将前面业务实体分析得到的领域模型片段进行合并和抽象(类图)。
》对设计约束和质量属性进行分析。
12.2.2.2 主要产物
》活动图，数据流图，用来表示业务流程。
》领域类图片段，标识每个流程，报表涉及到的业务实体。
》用例模型片段，表示每个业务流程中的业务活动，具体报表项。
》领域模型，按主题域对领域类图进行合并和抽象。
》用例模型，按主题域对用例模型片段进行合并和抽象。
》部署图，用来表述软硬件环境方面的设计约束。
12.2.2.3 主要访谈对象：中层用户代表。
12.2.2.4 输入
》业务事件，报表类型列表，作为访谈计划的线索。
》业务事件，报表类型列表作为需求组织的二级目录。
12.2.2.5 其他提示，这个阶段主要是搭建需求框架，不要涉及太深入的内容，目标不在于标识所有用例，所有领域类，而是标识出最重要的部分。
12.2.2.6 裁剪说明
》对于业务流程不太明晰的小项目，可以越过流程分析。
》对于涉及原系统的项目，可以标识出新业务事件和老业务事件。
12.2.3 填充需求细节阶段
对应软件生命周期中的需求捕获，分析阶段。
12.2.3.1 核心工作
》针对每个用例进行捕获，分析。
》对流程图上标识的相关文档进行分析，完成领域类的细节填充。
》在架构师的支持下，完成技术类用例的描述。
12.2.3.2 主要产物
》业务类用例描述，包括事件流，相关需求，UI原型，规则约束。
》报表类用例描述，包括报表概述，报表内容，输入输出格式。
》接口类用例描述，包括使用者概述，内容与格式，实现约束。
》领域类描述，包括数据窗口分析，组成与格式，计算规则。
12.2.3.3 主要访谈对象：操作层用户代表，小部分中层用户代表。
12.2.3.4 输入
》用例模型，按基线安排调研和细化。
》领域类模型，按用例安排分析和细化。
12.3 需求工作要点
