当场景分析完成之后，比较关键的一步就是要做系统需求(System Requirement)的识别与提取。系统需求(SR)的提取一般是由SE（系统工程师）、系统架构师或者研发骨干协助产品完成。系统需求的提取结果，是需要在《XXX场景分析说明书》中进行体现。

1 系统需求提取总体过程

一般来讲，系统需求的提取总体过程主要分为以下几步：

• Step 1：基于业务背景知识，先定义出业务域的初步划分（后续可以调整）
• Step 2：根据用户原始需求，绘制 Use Case 图（PD和架构师）。 针对每个Use Case进行分析，识别出：
  • 正常场景流程：用分析模型识别出边界类、控制类和实体类。其中边界类在后续会转换成Domain Service模型、控制类会转换成内部的主要业务管理类/模块、实体类会转换成Domain Model。用时序图或鲁棒图完成一次业务正常会话过程的分析，识别出这几个分析模型。 这里最需要关注的是，不仅要识别出本业务域能对外提供什么边界类，更重要的是要能识别出我们需要其他业务域提供什么边界类；
  • 异常分支流程：对于正常场景的异常情况进行补充，定义出在异常操作场景下的业务规则是什么，一会后面举例；异常分支有时会很简单，简单的异常分支文字方式描述规则即可，对于非常复杂的异常分支，也是需要使用分析模型/鲁棒图等方式进行分析；
  • 潜在的用户需求：用户的原始需求有可能只是从某一方面出发的，从整体分析的角度看，我们可以对标业界友商同类产品，进行竞争分析，分析出是否有从原始需求关联出未来可能的潜在需求；
  • 非功能性需求识别：非功能性需求也叫做DFX需求（Design for XXX），如：可维护性需求、可测试性需求、可安装性需求、技术限制需求、高性能需求、高可用需求、安全性需求等。非功能性需求需求往往是会对架构、方案产生重大影响，一些非功能性需求需求往往还会要求进行技术预研、原型验证，看是否可行

• Step 3：通过上述的场景分析识别出正常场景、异常分支、潜在需求、非功能性需求后，我们将每个正常场景对应成一个SR、每个异常分支对应一个SR、每个潜在需求对应一个SR、每条DFX对应一个SR，汇总到一个Excel表格中（用Excel会方便后期的设计管理）；
• Step 4：各个域组织评审与补充系统需求
• Step 5：对系统需求列表进行依赖关系分析，在Use Case中是有大的前置依赖定义，可以作为指导。 通过系统需求的依赖分析，我们会得到一个依赖关系树（也叫做系统解剖图）。基于系统解剖图，我们就能得到所有系统需求的前后依赖关系，进而就可以知道整体项目的关键路径是什么，最大的可并发度是在什么阶段等
• Step 6：将刷新后的系统需求进行工作量评估，并按照业务域录入到开发任务管理系统中，后期这些任务按照依赖关系定义出开发优先级并安排到具体的迭代中进行管理。

2 系统需求分析设计样例

2.1 基于业务背景知识，先定义出业务域的初步划分

关于业务域如何识别与划分，可以参考：设计实战 – 场景分析 & 领域划分

2.2 根据用户原始需求，绘制 Use Case 图

我们以会员域为例，识别出的总体Use Case图如下：

在这个用例图中，识别出和用户账号相关的相关场景。比如，邮箱方式注册账号、SNS方式注册账号等。用例图中，需要体现出场景与场景之前的前置关系、扩展子用例等关系。 所有的用例，都需要进行编号。

2.3 针对“邮箱注册账号”进行领域分析

2.3.1 邮箱注册正常场景分析

我们对邮箱注册账号识别出其边界类、控制类以及实体类，绘制其大致的处理鲁棒图或者时序图。

针对这个正常场景，我们可以很清楚的看到用户要完成一次正常的邮箱账号注册，需要分两步注册。第一次，是填写个人信息，第二次是到注册邮箱中点击确认链接完成邮箱确认。 这里，我们识别出有两个关键的边界类要提供服务：1）邮箱注册界面 2）邮箱确认界面 ，在具体描述时，我们要进一步描述这两个界面服务的细节，如下：

这个就是一个相对比较简单的正常场景系统需求的分析与描述。

2.3.2 邮箱注册异常场景分析

在正常场景梳理完后，我们可以挑战一些可能会出现的异常场景、非功能性需求识别等，比如：

• 【异常场景】如果用户注册的邮箱已经注册过了，怎么办？
• 【异常场景】如果用户在填写邮箱注册信息后，一直没有登录邮箱确认，怎么办？（比如，用其他人的信箱注册）
• 【安全性】用户注册的密码安全性如何保证？是否有第三方社工库做弱密码验证？ 第三方的社工库服务挂了怎么办？
• 等等

这些异常的场景，我们还可以进一步细化出很多。针对这些异常场景，如果是比较复杂的，也应该提供时序图的方式，将边界类、控制类、实体类进行识别与设计。 如果是非常简单的，可以直接写出系统需求，做好规则约定，便于后续遇到这个场景，PD、开发、测试能按照统一的规则去验证。比如，上面提到的几个异常场景，相对比较简单，我们可以直接转换成系统需求，如下：

2.3.3 识别并定义对外服务接口清单

在所有业务域的业务分析完毕，并输出系统需求清单后，比较重要的一个事就是汇总所有系统需求中设计到的接口清单。接口清单要包括：

1. 业务域对外提供的接口
2. 业务域使用到其他业务域的接口。 比如，交易域要识别出对库存域有库存查询服务、库存预扣减服务、库存扣减服务的接口需求。库存域的同学汇总各个域的服务接口需求，后期统一考虑接口设计以及出入参模型设计。

各个业务域要显性的把对外提供的接口需求也作为一个个单独的系统需求列在表格中，确保后续的任务没有遗漏。

2.3.4 系统需求工作量评估 & 开发任务创建

系统需求汇总完毕后，还需要做工作量评估和依赖关系分析（系统解剖图）。 这样就能够指导后续每个迭代的范围制定、关键开发路径识别了。
一级开发任务建议就按照系统需求，一条一条的对应。如果该系统需求比较大，可以在该任务下建立子任务进行跟踪和迭代安排。