1.11 需求管理（Requirements Management）
企业架构开发方法各阶段——需求管理
1.11.1 目标
本阶段的目标是定义一个过程，使企业架构的需求可以被识别、存储并与其他架构开发方法各阶段交互。
1.11.2 方法
如上图所示，需求管理阶段位于整个架构开发方法循环的中心，而整个架构开发方法过程实际上也是由这一构成所驱动的。需求管理的目标并不是针对一系列静态的需求表述，而是一个动态的过程，借助于这一过程企业架构的需求和因此而产生的变更能够被识别、储存，并与企业架构开发方法其他各个阶段的输入与输出产生互动。需要注意的是，需求管理构成本身并不能解决任何需求（这些应该是企业架构开发方法相应阶段的任务），它只是一个用来在整个架构开发方法周期中对需求进行管理的过程。
可借助的资源
在现实生活中存在着多种关于需求管理的建议和过程，TOGAF并不强制企业采用何种方式来进行需求管理，它只是表述了作为一个有效的需求管理过程所应该达到的要求。
- 业务情景（Business Scenarios）：此技术是描述在TOGAF中的一个非常有效的技术，用于发现并记录业务需求，同时还可以用来描述一份用于实现这些需求的架构愿景。
- Volere需求说明模板（Volere Requirements Specification Template）：此需求说明模板是目前比较流行的需求说明模板之一，虽然它本身并不是为了架构需求而设计的，但是这并不妨碍其可用性，并且这一模板可以被自由获取、修改或复制。
- 需求工具（Requirements Tools）：在当前存在着很多现成的商业性需求工具，并且其数量还在不断增长。虽然这些工具大多不是为架构需求而特制的，但是其可用性并不受阻碍，因为架构需求从本质上讲也没有太多特殊之处。
1.11.3 输入与输出
在当前阶段所需的输入材料以及此阶段输出的各种交付物归纳如下：
|
输 入 |
架构资源库 |
|
企业架构组织模型，包括：
|
|
|
定制的架构框架，包括：
|
|
|
架构工作说明书 |
|
|
架构愿景 |
|
|
架构需求说明中的架构需求 |
|
|
需求影响评估 |
|
|
输 出 |
需求影响评估 |
|
更新的架构需求说明（如有必要） |
1.11.4 步骤
由于需求管理阶段是一个与其他架构开发阶段交互的过程，因而在本阶段的各步骤中鲜明地体现了这种交互：
|
步骤序号 |
需求管理步骤 |
ADM各阶段步骤 |
|
1 |
|
通过业务情景或其他模拟技术识别/记录需求 |
|
2 |
定义基线需求：
|
|
|
3 |
监控基线需求 |
|
|
4 |
|
识别变更的需求：
|
|
5 |
定义变更需求和记录优先顺序：
|
|
|
6 |
|
|
|
7 |
|
实施架构变更管理阶段的需求 |
|
8 |
使用与变更请求相关的信息更新需求资源库，包括受到影响的干系人视图 |
|
|
9 |
|
实施当前阶段的变更 |
|
10 |
|
评估和修正先前阶段的差距分析。这一步骤需要确保因为差距发生变化而产生需求被清楚地表述出来，且被记录到需求库中，同时也要对目标架构做出相应的修改。 |
来源：https://blog.csdn.net/wyhappy612/article/details/99303731