2、全生命周期的需求变更管理
各种规模和类型的软件项目的生命周期大致可以分为三个阶段，即项目启动、项目实施、项目收尾。不要以为需求变更的管理和控制只是发生在项目实施阶段，而是要贯穿在整个项目生命周期的全过程中。
站在全局角度的需求变更管理，需要采用综合变更控制的方法。
(1) 项目启动阶段的变更预防
正如前面强调的，对于任何软件项目，需求变更都无可避免，也无从逃避，无论是项目经理还是开发人员只能积极应对，而这个应对应该是从项目启动的需求分析阶段就开始了。
对一个需求分析做得很好的项目来说，基准文件定义的范围越详细清晰，用户跟项目经理提出需求变更的几率就越小。如果需求没做好，基准文件里的范围含糊不清，被客户发现还有很大的“新需求空间”，这时候项目组往往要付出许多无谓的牺牲。
如果需求分析做得好，文档清晰且又有客户签字，那么后期客户提出的变更就超出了合同范围，需要另外收费。这个时候，项目经理一定要据理力争，此时这并非要刻意赚取客户的钱财，而是不能让客户养成经常变更的习惯，否则后患无穷。
(2) 项目实施阶段的需求变更
成功的软件项目和失败项目的区别就在于项目的整个过程是否是可控的。
项目经理应该树立一个理念，即“需求变更是必然的、可控的，并且是有益的”。项目实施阶段的变更控制需要做的是分析变更请求，评估变更可能带来的风险和修改基准文件。
控制需求渐变需要注意以下几点：
需求一定要与投入有联系，如果需求变更的成本由开发方来承担，则项目需求的变更就成为必然了。所以，在项目的开始，无论是开发方还是出资方都要明确这一条：需求变，软件开发的投人也要变。
需求的变更要经过出资者的认可，这样才会对需求的变更有成本的概念，能够慎重地对待需求的变更。
小的需求变更也要经过正规的需求管理流程，否则会积少成多。
在实践中，人们往往不愿意为小的需求变更去执行正规的需求管理过程，认为降低了开发效率，浪费了时间。但正是由于这种观念才使需求逐渐变为不可控，最终导致项目的失败。
精确的需求与范围定义并不会阻止需求的变更。
并非对需求定义得越细，就越能避免需求的渐变，这是两个层面的问题。太细的需求定义对需求渐变没有任何效果。因为需求的变化是永恒的，并非需求写细了，它就不会变化了。
注意沟通的技巧。
项目开发过程中的实际情况是用户、开发者都认识到了上面的几点间题，但是由于需求的变更可能来自客户方，也可能来自开发方，因此，作为需求管理者，项目经理需要采用各种沟通技巧来使项目的各方各得其所。
(3)、项目收尾阶段的总结
能力的提高往往不是从成功的经验中来，而是从失败的教训中得来。许多项目经理不注重经验教训总结和积累，即使在项目运作过程中碰得头破血流，也只是抱怨运气、环境和团队配合不好，很少系统地分析总结，或者不知道如何分析总结，以至于同样的问题反复出现。
事实上，项目总结工作应作为现有项目或将来项目持续改进工作的一项重要内容，同时也可以作为对项目合同、设计方案内容与目标的确认和验证。项目总结工作包括项目中事先识别的风险和没有预料到而发生的变更等风险的应对措施的分析和总结，也包括项目中发生的变更和项目中发生问题的分析统计的总结。
3、 需求变更管理原则
虽然需求变更的内容和类型有各种各样，但需求变更管理的原则却是万变不离其宗。实施需求变更管理需要遵循如下原则：
(1) 建立需求基线。需求基线是需求变更的依据。在开发过程中，需求确定并经过评审后(用户参与评审)，可以建立第一个需求基线。此后每次变更并经过评审后，都要重新确定新的需求基线。
(2) 制订简