需求管理过程域

本过程域要实现以下目标：
1）开发活动早期要确保需求被正确理解；
2）开发过程中要确保各种活动产生的工作产品都能满足用户和开发方一致认可的需求。

所谓管理需求，不仅仅把需求控制起来，还要“标识需求与项目计划和工作产品间的不一致性”。
这里的“不一致性”是存在两个方面的。通常大家关注的都是在需求和工作产品之间的不一致，很少关注需求和计划之间的不一致。
何种情况下会造成需求和计划之间的不一致呢？当我们按照既定的需求展开了WBS分解，依据WBS的分解进行了策划，而当需求发生了变化，已有的策划就应随之改变。
比如为该需求安排的实现和验证的进度可能需要调整，验证和确认的工具可能需要调整等等。

专用实践1.1 获得对需求的理解
本实践要求软件开发方与需求提供者（通常是用户）对需求的理解达成一致。
而要达成这一目标，首先就要“制定辨别合适的需求提供者的准则”。
这是容易被忽略的一个重要实践。
软件开发人员往往只关注提供过来的需求是否满足要求，却忽略对需求提供者的辨识。如果需求提供者不合适，即便前期双方对需求达成一致，也会因为真正的需求方提出的问题导致需求发生变更，而且，这类需求变更可能会出现在开发后期，对软件交付将带来非常巨大的影响。
而且，要确保双方达成“一致”，还应有一个软件开发方和需求提供者事先都认可的——“制定验收和评价需求的客观准则”——即便是使用标准给出的通用准则如“相互一致的”“完备的”，也比没有准则效果更好！
如果没有准则，在评价需求的时候，仅靠个人的经验，往往会忽略需求描述存在的这些“不一致”，“有遗漏”等问题，因为多数开发人员会从需求能否实现的角度考虑其是否满足要求，而不会注意此类问题，而这种疏忽会为将来需求变更埋下伏笔！

专用实践1.2 获得对需求的承诺
本实践要求在需求达成一致理解的基础之上给出保证完成需求的承诺。
谁来做出这个承诺？
“这个专用实践则处理项目参与者之间的协议和承诺，项目参与者是负责执行实现需求必要活动的那些人”。
做出承诺的项目参与者究竟包括哪些人？所有完成“分析、设计、编码、测试＂这些实现需求必要活动的人。
“确保项目参与者对当前的、经批准的需求作出承诺，以及对在项目计划、活动和工作产品中所发生的更改作出承诺”——项目参与者不仅对当前的需求作出承诺，也要对发生更改的需求作出承诺。

专用实践1.3 管理需求更改
本实践要求对需求的变更进行控制。
本实践和配置管理的SG2息息相关，所以标准中是这样描述的——“关于维护和控制需求基线并使需求及其更改数据可用于项目的更多信息，参见配置管理过程域”。
但两者的关注点是不同的，本实践关注的是需求本身的变更，而配置管理的SG2关注的是需求工作产品（配置项和基线）。

专用实践1.4 维护需求的双向可追溯性
本实践要求在整个软件生命周期对需求进行双向跟踪。
对于需求的双向追溯，标准是这样解释的——“建立从源需求到较低层需求和从较低层需求回到它们的源需求的双向可追溯性”。
这里所说的“源需求”，是来自于用户或客户，就是顾客需求；“较低层需求”，就是在源需求的基础之上开发（导出）的产品和产品部件需求。
需求的双向追溯就是从“源需求”顺流而下，在其后产生的较低层需求依次建立跟踪关系，然后再从这些较低层需求逆流而上，依次回溯。
这就是需求的双向可追溯的第一种关系。
除此之外，“需求可追溯性还能覆盖需求与其它实体的关系，这些实体如中间的和最终的工作产品、设计文档中的更改、以及测试计划等”。
需求的追溯关系不仅是从源头的顾客需求，追溯到产品需求，还要追溯到设计文档，以至测试计划等实体。这是需求的双向可追溯的第二种关系。
做好本实践，就要处理好这两种关系。

专用实践1.5 标识项目工作与需求之间的不一致性
本实践要求及时发现和纠正项目活动和工作产品与需求的不一致。
“评审项目的计划、活动和工作产品与需求及其更改的一致性”
——而要标识出工作产品、活动和需求的一致性，采用的主要手段之一就是“评审”。