会员登录
会员注册
其次，“管理需求变更”中应先进行评估与审批，审批之后应执行“维护对需求的双向可追溯性”和“标识项目计划和工作产品与需求的不一致性”。这两个看上去好象是附加上去的特定实践，其实很重要(不好的需求管理流程中常缺这两个特定实践)，其目的是通过流程维护需求变更的历史和理由、评价需求变更的影响，发现不一致并启动相关的处理过程域(进入其他流程)。例如，当变更对项目产生风险时，需要使用其他流程进行风险防范或进行项目计划变更，这些都可以包含在流程中。“管理需求变更”流程需要配置管理过程域的支持(通常是通过配置管理的控制变更来实现对需求变更的控制)。
再次，两个关系密切的特定实践“维护对需求的双向可追溯性”和“标识项目计划和工作产品与需求的不一致性”，一般分散在其他相关流程中，并贯穿于整个软件生命周期中。例如，定期或以事件触发方式启动“标识项目计划和工作产品与需求的不一致性”，检查是否一致，从而进行相应处理。
流程的具体编制依赖于组织结构(同时它也影响着组织结构)，因此，不同的组织需要制定自己的流程。组织流程一般是跨过程域的综合流程，在制定流程前，应充分了解过程域之间的依赖关系，只有这样，才能将这些关系有机地融合到流程中。这些相关的过程域可能分属于不同的成熟度级别，因此，可能在现有条件下没有实施较高级别的过程域，这时我们可以“弱化”这些不能实现的过程域，即只取其必要的功能放到流程中去。我们将“需求开发”过程域弱化成“需求分析”(“需求管理”要求“需求开发”提供必要的功能)放到流程中。
总之，掌握过程域之间的关系，对编制流程很有帮助。这里我们总结出需求管理与其他过程域的主要关系。
(1)需求管理依赖的过程域
①需求开发：通过需求开发建立和维护客户产品、产品部件和接口需求。
②配置管理：通过配置管理控制需求的变更。
③项目监督和控制：通过监督和控制识别需求与项目计划、工作产品的矛盾。
(2)依赖于需求管理的过程域
①需求开发：通过需求管理来管理客户和产品需求，获得需求供应者的同意和需求实现者的承诺，并使需求的维护可追溯。