SERU（Subject area, Event, Report, Use case）是CSAI顾问团需求工程专家组提出的一种需求方法体系，SERU是源于实践的、业务驱动的软件需求方法体系，秉承从业务出发、逐层剥茧抽丝，全面深入分析需求的思想，以实现IT投资商业价值最大化为目标，确保软件开发团队做正确的事，避免“完美地实现了本不需要的任务”之悲剧。
SERU方法体系将软件需求工程分成三个重要阶段：明确目标和范围（开天辟地）、理清脉络和框架（泾渭分明）、填充需求细节（天圆地方）；通过主题域、事件、报表/管控点、用例四个关键分解项贯穿分析、建模和描述过程。
在实际的应用过程中，由于结构化分析、面向对象分析方法都无法覆盖需求工程的全部内容，因此还派生了业务工程、业务建模方法来补充。另外，由于实践需求工程的人员大多是技术背景，因此经常仍然遵循UI驱动、数据库驱动等技术驱动需求过程。
而用例、用户故事等业务视角的需求分析方法应用误区多，加之无法覆盖所有的需求工作，因此许多需求人员仍然无法离开技术驱动的思想，形成了半业务、半技术的结果。
SERU需求方法体系正是针对这一问题，有效集成了各种有效需求实践，为从业人员提供了完整、清晰的全面业务驱动需求方法体系。SERU完全覆盖需求开发的全过程，打通了业务工程和需求工程之间的鸿沟，具有很好的可操作性。
SERU需求规格说明书模板大纲
1. 文档概述
1.1编写的目的
1.2背景
1.3定义
1.4参考资料
2. 任务概述
2.1业务需求
2.2 Stakeholder利益分析（略）
2.3用户特点分析
2.4相关事实与假定
3. 需求概述
3.1系统概述[主题域划分，用构件图表述]
3.2主题域 1
3.2.1 概述[用上下文关系图表示该主题域的范围]
3.2.2 业务事件
3.2.2.1 业务事件1[包括流程分析、领域类分析、用例分析]
… …
3.2.2.n 业务事件n
3.2.3 报表
3.2.3.1 Report 1
[用领域类图片段表示涉及数据，用用例标识具体的报表项]
… …
3.2.3.n Report n
3.3主题域 n
4. 具体需求
4.1主题域 1
4.1.1 用例模型
4.1.1.1 UC_B_xx（B类）
（1）概述[编号、名称、概述、相关Stakeholder]
（2）事件流描述[前、后置条件，基本、扩展、子事件流]
（3）相关需求与功能点
（4）界面原型[交互过程与界面详解]
（5）规约与约束
4.1.1.2 UC_R_xx（R类）
（1）概述[名称、用户部门与职位、业务意图、相关场景]
（2）报表内容[领域类图、数据项]
（3）输入/输出格式
（4）其他
4.1.1.3 UC_I_xx（I类）
（1）使用者[名称、业务目的、时机、频率]
（2）内容与格式[交互过程、数据包说明]
（3）设计与实现约束[诸如协议格式要求、性能要求等]
… …
4.1.2 领域模型
4.1.2.1 xx领域类
（1）概述[类名称、别名]
（2）数据窗口分析[涉及主题域、业务事件，各域数据]
（3）数据组成与格式
（4）其他
… …
4.n主题域 n
5. 补充规约
5.1设计约束
5.1.1 技术选择的限制条件
5.1.2 运行环境[建议用部署图表示]
5.1.3 预期的使用环境
5.2质量属性[本部分建议直接分解成需要开发的技术功能点]
5.2.1 安全性要求
5.2.1.1 访问安全性要求
5.2.1.2 数据安全性要求
5.2.1.3 通信安全性要求
5.2.1.4 其他安全性要求
5.2.2 可靠性要求
5.2.2.1 容错性要求
5.2.2.2 可恢复性要求
5.2.2.3 其他可靠性要求
5.2.3 易用性要求
5.2.3.1 界面友好性要求
5.2.3.2 易操作性要求
5.2.3.3 其他易用性要求
5.2.4 性能要求
5.2.4.1 数据访问性能要求
5.2.4.2 数据传输性能要求
5.2.4.3 其他性能要求
5.2.5 可维护性要求
5.2.5.1公共数据要求
5.2.5.2公共框架开发要求
5.2.5.3公共程序库开发要求
5.2.5.4其他可维护性要求
5.2.6 可移植性要求
5.2.6.1适应性要求
5.2.6.1易安装性要求
5.2.6.1其他可移植性要求
5.2.7 其他质量属性要求
5.3其他需求
5.3.1 培训需求
5.3.2 后勤需求
5.3.3 包装需求
