sp;
有时使用非常正式的 RM 实践可能是小题大做。比如，如果您的项目团队任务是构建一个视频游戏，那么扩展请求和需求变更就可能频繁出现，以至于随后如果使用传统变更控制过程（需要变更控制委员会的批准）实际上可能妨碍项目成功。这种情况下，变更控制过程实际上限制了开发人员的创新，并且成为软件交付的瓶颈。然而，即使在这种情况下，项目团队仍可以使用诸如故事板或原型这样的RM技术在开发和交付之前验证游戏创意，并从中获益。
在另一个极端上，也有极其需要使用非常正式的 RM 实践的时候。比如，如果项目团队的任务是开发一个运行医疗设备的软件，它能根据情况自动管理病人的精确的、正确的用药量，那么项目团队就应该采用高度正式的 RM 过程来保证开发出正确的系统。这种情况下需求错误的风险可能危及人的生命安全。
那么 RM 如何影响像您这样的开发人员呢？诸如 Standish Group 报告（见参考文献）这样的研究表明，需求错误是修复成本最高的错误，因为它们出错的时间越长，影响就越大。随着软件开发生命周期的进展，这些错误越来越难以纠正，这实际上产生了雪球效应。如果您从一个错误的需求或者需求变更开始，那么您的设计就是无效的，这最终会导致进行代价昂贵的构架返工。确认测试也是错误的，用户文档也不精确，等等。最终，这将导致花费更多的时间来修复问题，而这些是完全可以避免的。
但您是开发人员，而不是分析人员。RM 不是仅用于分析人员的吗？可以肯定的是，您项目团队中代表客户的那些人涉入 RM 最深。分析人员通常负责创建需求。然而，需求的质量不仅仅落在分析人员的肩上。记住，整个项目团队对需求有一个完整清楚的理解是至关重要的。为了实现这种质量，开发人员必须尽早参与，以帮助澄清最初需求版本中的模糊性。开发人员提供了一种实现视角，能够提高已编写需求的质量，并且能够增加开发解决方案的成功率。与开发人员的合作是"如鱼得水"；开发人员负责将概念转化为现实。因此，开发人员越早参与需求的澄清，项目成功交付正确的软件解决方案的机会就越大。
开发人员还应该关心适当的 RM，因为它可以简化他们的工作。当从高质量的需求而不是很差劲的需求（这样的需求总需要团队成员查找测试内容，并且用各种问题打断开发人员）开始工作时，质量保证（QA）或质量工程（QE）和文档编辑团队的工作就更有效率。另外，维护活动可以减少到只专注于系统中真正的实施缺陷，而不是由不清楚和不完整的原始需求导致的缺陷。更高质量的需求最终能够保证软件的质量更高，这使得开发人员可以集中精力思考如何对系统作出改进。
与拙劣的需求管理相关的软件问题
让我们看一下可能面对的问题，将它们与拙劣的 RM 实践中的根本原因挂钩，并为每个问题提出解决办法。
问题1：持续变更
市场或销售人员每隔多久会要求您在代码中加入客户请求的变更？通常变更看上去都是很小，并且看上去是合理的。当然您希望能够成功地完成代码编写，所以您非常愿意满足他们的请求，并且加班加点地在代码中加入变更。这些持续性的中断影响您设计和交付优质软件的效率。您很难集中精力。但是更大的破坏是接受这些随意的请求对项目计划和总体软件质量造成的影响。像这样持续的中断使项目计划超出了最初的范围，这就是通常所说的"范围蔓延"。这些打断分散了项目团队的思路，使他们无法按照最初目标交付软件，从而导致所交付的软件不能满足客户期望。
该需求问题的根源在于，项目团队在接受变更或扩展请求之前不能正确评估它们的影响。
让开发人员对这些直接请求作出响应，可能导致项目团队不能正确评估接受变更的整体影响。结果，如果开发人员接受这些乍一看很小的请求