需求管理流程可以由几个子流程组成，有些子流程可以并行工作，有些子流程还与其他过程域的流程有关。
首先，“获得对需求的理解”和“获取项目参与者对需求的承诺”两个特定实践可以放到一个流程中实施。将实际流程图进行简化（见图2），可以看出：
①通过一个综合流程可将多个特定实践包含其中。同时，还可以看出需求管理过程域与其他过程域（配置管理、技术开发、项目策划）相关联。
②“获得对需求的理解”要求明确需求的正式来源（总行业务部门）。
③“获得对需求的理解”实际上是进行需求分析、确认需求的过程，它的结果是形成“达成一致”的需求（《软件需求说明书》）。
④“获取项目参与者对需求的承诺”主要包括两个承诺。一是需求方对达成一致的需求（《软件需求说明书》）的正式确认二是开发方以项目目标定义书的方式，对开发计划和成本等作出承诺。
其次，“管理需求变更”中应先进行评估与审批，审批之后应执行“维护对需求的双向可追溯性”和“标识项目计划和工作产品与需求的不一致性”。这两个看上去好象是附加上去的特定实践，其实很重要（不好的需求管理流程中常缺这两个特定实践），其目的是通过流程维护需求变更的历史和理由、评价需求变更的影响，发现不一致并启动相关的处理过程域（进入其他流程）。例如，当变更对项目产生风险时，需要使用其他流程进行风险防范或进行项目计划变更，这些都可以包含在流程中。“管理需求变更”流程需要配置管理过程域的支持（通常是通过配置管理的控制变更来实现对需求变更的控制）。
再次，两个关系密切的特定实践“维护对需求的双向可追溯性”和“标识项目计划和工作产品与需求的不一致性”，一般分散在其他相关流程中，并贯穿于整个软件生命周期中。例如，定期或以事件触发方式启动“标识项目计划和工作产品与需求的不一致性”，检查是否一致，从而进行相应处理。
流程的具体编制依赖于组织结构（同时它也影响着组织结构），因此，不同的组织需要制定自己的流程。组织流程一般是跨过程域的综合流程，在制定流程前，应充分了解过程域之间的依赖关系，只有这样，才能将这些关系有机地融合到流程中。这些相关的过程域可能分属于不同的成熟度级别，因此，可能在现有条件下没有实施较高级别的过程域，这时我们可以“弱化”这些不能实现的过程域，即只取其必要的功能放到流程中去。如图2中，我们将“需求开发”过程域弱化成“需求分析”（“需求管理”要求“需求开发”提供必要的功能）放到流程中。
总之，掌握过程域之间的关系，对编制流程很有帮助。这里我们总结出需求管理与其他过程域的主要关系。
（1）需求管理依赖的过程域
①需求开发：通过需求开发建立和维护客户产品、产品部件和接口需求。
②配置管理：通过配置管理控制需求的变更。
③项目监督和控制：通过监督和控制识别需求与项目计划、工作产品的矛盾。
（2）依赖于需求管理的过程域
①需求开发：通过需求管理来管理客户和产品需求，获得需求供应者的同意和需求实现者的承诺，并使需求的维护可追溯。
②技术解决方案：通过需求管理为产品和产品部件管理需求。
③产品集成：通过需求管理来管理接口需求的变更。
④项目计划：根据需求管理来制定计划和更改计划。
⑤验证和确认：根据需求管理维护需求。
⑥供应商合同管理：根据需求管理确定能被外部满足的需求并管理可追溯的需求，这些需求来源于供应商已经完成的产品。
四、需求管