产生影响，但一旦产生影响，处理起来就很麻烦，这也是为什么大家都提倡在需求阶段把需求做充分，在设计阶段把架构设计灵活。前者可以预防问题发生，后者则可以尽量降低问题发生后对设计的影响。
(三) 测试阶段的需求变更
在这个阶段需求变更发生较少，但也会出现，有可能是用户突然又增加新的内容，而更多情况是测试人员发现的BUG是由需求的误差引发的。这也是为什么现在的软件测试从需求分析阶段就开始，而不是等到阶段性编码结束再开始。把问题尽量消灭在开始阶段总比在问题出现后再补救更合理。
(四) 实施阶段的需求变更
这个阶段出现的需求变更就更少，即使出现也不是功能方面的问题，可能是和实施相关的软硬件或网络问题。若要避免，则只能在设计时就考虑多种实施方案，以防万一。凡事预则立，不预则废。
(五) 系统维护阶段的需求变更
借用80/20原则，80%的需求变更产生于这个阶段，剩余的20%则产生于其他几个阶段。系统上线后，用户在使用起来肯定和原来的想法会有很大的出入，这就是理想与现实的差距。这个阶段的变更无法预料，只好认真的管理。
上面分析了各个阶段的需求变更，那么对于变更控制也就有了清晰的解决思路。国内讲需求变更管理，大多提到加强沟通、区分对待、合同约束等问题，这种功利化的处理方式无可厚非，但是却没有讲到重点上。对于需求变更控制，我觉得仍要沿用需求分析的处理方式，先分主次，再具体分析。这个过程中就需要标明是哪个阶段的需求变更，还要估计变更对程序带来的影响，而不是泛泛的记录变更的内容。很多软件在系统维护阶段变得异常的被动，主要还是没有把需求变更带来的影响分析准确。
把方法再明确一下，就是需求变更需要有专门的人员记录，这个人最好是项目组内部的人员，记录内容包括需求变更具体内容、发生于哪个阶段、以及由谁提出的等内容。项目经理需要每天关注需求变更记录，每周必须对需求变更产生的影响进行预估，并将预估结果记入到需求变更记录当中，以便于确定今后的工作计划。