需求变更后：
　　参照需求跟踪能力矩阵找到受需求变更影响的工作产品，并进行一致性变更，同时要维护变更历史记录。所有这些工作也是至关重要的内容，需要慎重细致对待，否则对持续的需求变更来讲，将是一场灾难。
　　项目结束
　　一个项目的交付验收，并不意味着项目的真正结束，一个的项目管理人员善于在项
　　目结束后进行总结。项目总结工作当然要包括那些没有预料到而发生的需求变更，以及这些变更的应对措施。根据实际工作中遇到的需求变更管理的问题，笔者总结如下几点，以供参考和交流：
　　◆良好气氛下的充分交流　讨论需求及变更需求时，需求人员与客户及用户应该尽量采取协作的态度，良好的工作氛围也会提高工作效率，很难想象双方在“刁难”与“对付”的态度下是一种该有多糟糕的工作场景。确定需求基线的过程也是与客户用户交流的过程，而频繁大量的需求变更在很大程度上也是交流不充分的后果。所以，有效的充分的交流尤为重要，需求人员认真听取客户用户的要求，进行分析和整理。同时还应该有能力设想项目的开发过程中可能会遇到的由该需求导致的问题，同时要让客户认识到如果此时再提出需求变更，将会给整个项目带来的各种影响和冲击。
　　◆专职人员负责需求变更管理　在具有相当规模的项目中，专职的需求人员和由此组成的需求变更执行小组是项目稳定、进度良好的保证。没有变更管理而直接由开发人员处理的需求变更将会给项目带来毁灭性的灾难。这些专职人员应该具有专业的需求分析技巧技能，针对用户的变更需求，可以给用户说明利弊，可以按紧迫程度为开发人员提供工作重点，同时， 他们应该还能控制需求变更的频率。
　　◆明确合同约束，限制需求变更　需求在软件项目中的地位已经越来越重要，需求变更给软件开发带来的影响也是有目共睹，甚至因为质量低下的需求或者频繁无控制的需求变更而导致项目的失败。因此，应该让客户明白需求变更给项目带来的工期、成本等各方面的影响，在互相理解的基础上增加合同条款，比如明确说明客户可以提出需求变更的期限，超过期限的需求变更的具体处理细则(如增加开发费用等，需求变更与开发费用本身也是关联的，这个要求并不过分)。
　　◆良好的软件结构适应需求变更  的软件体系结构可以快速应对不同情况的需求变
　　更，这样可以适当降低需求的基线（当然是在成本影响的允许范围内），从而来提高客户的满意度。适应需求变更必须遵循一些设计原则，如松散耦合、合理的接口定义等，要力求减少会对接口入口参数产生变化。