一、目标
需求管理阶段的目标是:
- 确保需求管理流程持续运行,并在所有相关的 ADM 阶段运行
- 管理在 ADM 周期或阶段的任何执行期间确定的架构要求
- 确保在执行阶段时,每个阶段都可以使用相关的体系结构要求
二、输入
需求管理阶段的输入包括:
- 填充的架构存储库
- 企业架构的组织模型,包括:
- 受影响的组织范围
- 成熟度评估、差距和解决方法
- 架构团队的角色和职责
- 体系结构工作的约束
- 预算需求
- 治理和支持战略
- 定制架构框架,包括:
- 量身定制的架构方法
- 定制的架构内容(可交付成果和工件)
- 已配置和部署的工具
- 架构工作声明
- 架构愿景
- 架构需求,填充架构需求规范
- 需求影响评估
三、步骤
下表描述了需求管理阶段中的步骤:
| 需求管理步骤 | ADM 阶段步骤 |
---|---|---|
步骤 1 |
| 确定需求(通常通过分析如何通过价值设计来满足业务目标/目的 流、业务场景、用户体验或提供管理信息),并将其记录在体系结构中 需求规范和需求存储库。 |
步骤 2 | 建立基线要求:确定优先级,确认利益相关者对优先级的同意,并记录 它们在架构需求规范和需求存储库中。 |
|
步骤 3 | 监视基线要求。 |
|
步骤 4 |
| 确定新的和更改的要求:
|
步骤 5 | 确定更改的需求并记录优先级:
笔记
|
|
步骤 6 |
|
|
步骤 7 |
| 实施 H 阶段提出的要求。 架构可以通过架构更改管理阶段(阶段 H)在其生命周期中进行更改。这 需求管理流程确保管理从阶段 H 派生的新需求或更改的需求 因此。 |
步骤 8 | 使用与所请求更改相关的信息更新体系结构要求存储库,包括 利益相关者的意见受到影响。 |
|
步骤 9 |
| 在当前阶段实施更改。 |
步骤 10 |
| 评估和修改过去阶段的差距分析。 ADM 阶段 B 到 D 中的差距分析确定了基线架构和目标架构之间的差距。 某些类型的间隙可能会产生间隙要求。 ADM 描述了两种类型的差距:
“差距要求”是指意外消除的任何内容,因此需要更改目标 建筑。 如果差距分析生成差距要求,则此步骤将确保解决、记录和 记录在架构需求存储库中,并相应地修订目标架构。 |
四、输出
需求管理过程的输出可能包括但不限于:
- 需求影响评估
- 如有必要,更新架构需求规范
架构需求存储库将作为需求管理阶段的一部分进行更新,并且应该 包含所有要求信息。
当出现新需求或更改现有需求时,将生成需求影响声明,该声明 确定需要重新访问 ADM 的阶段以解决更改。该语句经历了各种迭代 直到最终版本,其中包括需求的全部含义(例如,成本、时间表和业务指标) 关于架构开发。一旦当前 ADM 周期的需求最终确定,那么架构要求 规范应更新。
五、方法
1 、概述
如 ADM 图形中心的“需求管理”圆圈所示,ADM 连续 由需求管理流程驱动。
需要注意的是,需求管理圆圈表示的不是一组静态的需求,而是 确定企业架构需求的动态过程以及对这些需求的后续更改, 存储并送入和送出相关 ADM 阶段,以及 ADM 的周期之间。
处理需求变化的能力至关重要。建筑是一种活动,就其本质而言 处理不确定性和变化——利益相关者所渴望的与可以指定和设计为的“灰色地带” 一个解决方案。因此,架构要求总是会在实践中发生变化。此外,建筑经常处理 具有驱动因素和约束,其中许多本质上超出了企业的控制范围(不断变化的市场) 条件、新立法等),并且可能会以不可预见的方式产生需求变化。
另请注意,需求管理过程本身不会处置、处理或优先处理任何 要求;这是在ADM的相关阶段内完成的。它只是在整个 整体行政管理。
建议使用架构需求存储库来记录和管理所有架构 要求。与架构需求规范和需求影响评估不同,架构 需求存储库可以保存来自多个 ADM 周期的信息。
2、 需求开发
第一个高级需求作为架构愿景的一部分进行阐述,通过 业务场景或类似技术。
ADM 的每个阶段,从初步阶段到阶段 H,都必须选择该阶段的批准要求,如 体系结构需求存储库和体系结构需求规范。在阶段结束时,状态 所有这些要求都需要更新。在阶段执行期间,为未来的架构工作生成新的要求 在当前架构工作声明的范围内,需要在架构要求中记录 必须将当前架构工作声明范围之外的规范和新要求输入到 架构需求存储库,用于通过需求管理流程进行管理。
在ADM的每个相关阶段,架构师应确定必须满足的需求类型 架构,包括适用的:
- 功能要求
- 非功能性需求
在定义需求时,架构师应考虑:
- 需求的假设
- 需求的约束
- 推动需求的领域特定原则
- 影响需求的策略
- 要求必须满足的标准
- 要求的组织准则
- 要求规范
ADM 后期阶段的可交付成果还包含与设计要求的映射,并且还可能生成新类型 要求(例如,一致性要求、实施时间窗口)。
3、 资源
需求工程领域充满了针对需求的新兴建议和流程 管理。TOGAF 标准不强制要求或推荐任何特定的流程或工具;它只是说明什么是有效的 需求管理过程应该达到(即“需求需求”,如果你愿意的话)。
3.1 业务场景
一种用于分析流程或价值流如何实现业务目标的技术。分析 在该过程中的活动由人类和计算机参与者执行的情况下,是识别和澄清的非常有效的方法 体系结构要求
3.2 需求工具
有大量且不断增加的商业现货 (COTS) 工具可用于支持 需求管理,尽管不一定是为体系结构需求而设计的。