，就会导致必须对代码的其他部分作出必要变更的涟漪效应。同样，涟漪效应超出了代码范围，扩大到了项目团队的其他领域。比如，如果没有将变更有效地通知测试人员，那么他们可能就不能构建出必要的验证脚本来测试变更，从而带来了影响软件质量的风险。此外，即使变更只需要开发人员的一点点努力就能实现，但是对 QA/QE 或文档的影响可能延误整个项目进度。由于涟漪效应的存在，整个项目团队为出现的变更召开会议就很有必要。
由于这些依赖关系，开发人员将接受变更的权利委派给项目团队中对项目交付有着高度和完整预见性的人就变得很重要。为了降低破坏项目稳定性的风险，您只希望接受被项目团队批准的变更，这样您就知道您正在实现的是一个商定的功能，并且每个人都有义务测试和记录该功能。
解决办法：通过评估变更的影响控制需求变更
良好的 RM 实践可以避免未经评估就随意做出变更。他们将变更请求视为"头等公民"，以保证所有潜在的变更都经过检查，并且接受变更的影响能在影响开发人员的工作之前得到评估。
需求规格说明书应该经过由客户、开发团队和测试团队三方代表组成的小组批准之后才能进行变更。这个小组通常被称为 CCB。该组的职责是从客户的角度、开发的角度、测试和文档化的角度评估每一个被请求的变更。根据应用程序类型的不同，培训和支持人员可能也需要参与进来。
为什么需要所有这些人参与呢？因为每个代表都在分析实施给定变更请求的潜在影响或成本时具有不同的视角：
开发代表负责评估变更请求影响的所有软件设计区域，以及实施变更所需的后续努力。通常需要个别开发人员作为这样的代表参与分析变更请求的影响。
QA 代表必需评估与接受提议变更相关的测试工作的可行性和程度。我们应该时刻记住变更可能很容易加入到代码中，但是很难（有时候甚至不可能）测试。
客户代表提供了业务视角，并保证变更不会使项目偏离最初的业务目标，以及提供有关变更的任何信息来帮助 CCB 理解客户需要。
最后，为了安全起见，包含来自 CCB 的培训、支持和文档化代表也是我们推荐的，因为变更请求通常也对这些领域有影响。
为了保证评估过程的有效性，CCB 的每个成员应该负责查找一个适当的替代品，以防万一，从而保证对变更请求的评估绝没有偏见。对于所有方面都没有代表的罕见情况，应该将变更请求推迟到以后再评估。
好的 RM 实践应该防止开发人员匆忙地对事情做出变更。需求的变更方面，从您编写它们开始直到交付软件，都是项目中最难应付的事情。Standish Group 在它 2001 Extreme Chaos 报告中指出："变更需求就像死亡和税收一样确定无疑"。掌握管理变更需求的技巧对于项目的成功很重要，并且它还是一种直接影响开发人员生活的实践。
迭代开发取代传统的瀑布型方法对管理需求变更是一种很大的帮助。在传统方法中，需求规格说明书在项目一开始就被冻结了，并且直到软件发布之后变更还不能加入进入。让变更进入版本中的唯一方法就是直接找开发人员，请求他们变更代码。这也正是我们前面看到的由于不能评估变更对项目真正的总体影响而导致项目不稳定的方法。迭代开发允许软件团队将工作分割成小的部分，其中需求是稳定的并且在迭代过程中保持不变。在下一次迭代开始时，团队就有机会更新需求规格说明书，以加入上一次迭代中提交和接受的变更。在迭代开发中，规格说明书只在迭代开始时发生变更，而不能在迭代过程中进行变更。这使得我们可以在迭代期间把注意力集中在一组需求上。当下一次迭代来临时，您就会被分配一组缺陷和新的或更新过的需求。
问题2：处在影响您工作的变更的盲区
当需求发生变更时，如何通知您？您的经理被