需求变更是软件项目一个突出的特点，也是软件项目最为普遍的一个特点。虽然这与人类认识问题的自然规律是一致的，但是频繁而无管理的需求变更非常容易导致复杂、无形的软件在多变的情况下失控，加剧了软件开发过程中的不稳定性，从而造成多方的损失。那么如何对需求变更加以有效的控制和管理，从而保证软件开发的进度、成本和质量，便成为软件开发过程中一个值得思考的问题。
下面，我们将“需求变更管理”作为一个“项目”，按照问题定义、需求分析、设计、开发等步骤，从软件工程的角度来加以分析，而这样的讨论过程也正符合了我们的开发流程，相信大家会对需求变更管理的认识更加深刻。
问题定义
根据软件工程思想，需求说明书一般要经过需求评审的过程。在需求说明书经过论
证后，需要在原有基础上补充新的需求或对其进行修改和删减，则均属于需求变更。
这是软件开发过程中不可避免的问题，如何有效应对和处理需求变更，已经成为一个广泛受到关注的话题。
需求分析及评价
由于频繁需求变更且同时缺乏有效控制流程而导致软件项目失败的案例不胜枚举，
面临这种不稳定性，如果开发团队缺少明确的需求变更管理控制或者采用的控制机制无效，很可能出现成本增高、人力紧缺、项目拖延甚至是失败，这也就有了进行需求变更管理的需求。
诚然，需求变更管理不可能根本解决问题，但是实施严格的软件需求变更管理能最大限度地控制需求变更带来的负面影响，从而保证项目的可控性和稳定性，这也正是进行需求变更管理的目的所在。
设计
这里的设计指的就是如何来制定需求变更管理的执行计划。主要分以下几个阶段：
获取需求基线：需求的基线是指是否容许需求变更的分界线。需求分析人员在充分与客户用户进行沟通的基础上形成第一个版本的需求文档，这个需求文档在通过需求评审后即可以建立第一个需求基线。此后每次需求变更并经过需求评审后，都要重新确定新的需求基线。变更控制委员会为有效进行需求变更控制，必然要做的工作就是保存好各个版本的需求基线，维护需求基线文档，以备不时之需。随着项目的进展，基线将越定越高，即容许的需求变更将越来越少。
分析变更影响：对于提交的每项需求变更请求，应确定它对项目整体进度的影响和对其他相关开发任务的影响，并且一定要明确完成这些变更相关任务的工作量。只有经过全面的分析，变更控制委员会才能够做出更好的决策。进行变更影响分析可以对申请的需求变更有更深刻的理解，通过对变更内容的更深刻的理解，才能做出对正在进行的工作的调整的部署。
维护变更记录：记录每个需求变更文档的版本号、日期、所做的变更、原因等，当然应该明确该文档由谁来负责更新。
衡量需求稳定性：变更控制委员会需要对需求变更的整体有良好的把握，通过记录需求基准的数量可以获得宏观需求的变更次数；同时还应该记录一段时间内（如每周、每月）的变更数量，最好按变更的类别来列出详细信息。如果某一需求过于频繁变更，则说明对该问题的认识还不深入或者说还没有达成一致的处理意见；如果需求变更的总体数量过高，则意味着项目范围并未很好地确定下来或是政策变化较大。
使用需求管理工具：需求变更控制委员会可以采取商业化的需求管理工具，以此来在数据库中存储不同类型的需求。这些工具提供了对每项需求的属性描述，状态跟踪等，并可以在需求与其它的相关工作产品建立跟踪能力联系链。
开发
这里的开发指的就是如何在项目的开发过程中有效实施需求变更管理。实施需求变更管理需要遵循如下三个阶段的原则：
需求变更的前绪工作：
1.项目的高效进行，需要良好的高质量的需求，同时它也是需求变更的依据。
2.建立以文档形式存在的简单、有效的变更控制流程。
3.建立项目变更管理执行小组及变更控制委员会。委员会成员组成涉及项目的多方人员，至少应包括用户方代表和开发方的决策人员。小组成员可以由负责需求的人员中有经验的需求分析员来担当。
需求变更进行时：
需求变更的流程一定要遵循由变更控制委员会制定的变更控制流程。变更控制一般要经过变更申请、变更评估、委员会决策、委员会回复、实施变更、变更验证六个步骤。
1.变更申请：随着项目的深入，需求变更也是不可避免的。需求分析小组一定要在充分考虑用户需求，项目进度，需求基线的基础上提交变更申请，并提供尽可能详细的说明以供变更控制委员会进行变更评估。
2.变更评估：需要对提出的变更需求进行影响分析，评估变更是否在项目范围内，对项目计划安排和其它需求的影响，需要的工作量等等。
3.委员会决策：根据评估作出决策以确定选择哪些，放弃哪些，并设置实现的优先顺序，制定目标版本。
4.委员会回复：回复包括同意实施变更和拒绝实施变更，并制定相应变更方案或说明拒绝理由。
5.实施变更：维护需求变更文档，包括：日期以及所做的变更、原因、负责人及新的版本号等等。该工作可以由委员会或者责成执行小组来完成。
6.变更验证：充分和提交变更申请人进行沟通，以使其得到满意答复。然后根据变更方案和需求基线，进行相应的需求变更后的工作。该工作可以由执行小组来完成。
需求变更后：
参照需求跟踪能力矩阵找到受需求变更影响的工作产品，并进行一致性变更，同时要维护变更历史记录。所有这些工作也是至关重要的内容，需要慎重细致对待，否则对持续的需求变更来讲，将是一场灾难。
项目结束
一个项目的交付验收，并不意味着项目的真正结束，一个优秀的项目管理人员善于在项
目结束后进行总结。项目总结工作当然要包括那些没有预料到而发生的需求变更，以及这些变更的应对措施。根据实际工作中遇到的需求变更管理的问题，笔者总结如下几点，以供参考和交流：
◆良好气氛下的充分交流 讨论需求及变更需求时，需求人员与客户及用户应该尽量采取协作的态度，良好的工作氛围也会提高工作效率，很难想象双方在“刁难”与“对付”的态度下是一种该有多糟糕的工作场景。确定需求基线的过程也就是与客户用户交流的过程，而频繁大量的需求变更在很大程度上也是交流不充分的后果。所以，有效的充分的交流尤为重要，需求人员认真听取客户用户的要求，进行分析和整理。同时还应该有能力设想项目的开发过程中可能会遇到的由该需求导致的问题，同时要让客户认识到如果此时再提出需求变更，将会给整个项目带来的各种影响和冲击。
◆专职人员负责需求变更管理 在具有相当规模的项目中，专职的需求人员和由此组成的需求变更执行小组是项目稳定、进度良好的保证。没有变更管理而直接由开发人员处理的需求变更将会给项目带来毁灭性的灾难。这些专职人员应该具有专业的需求分析技巧技能，针对用户的变更需求，可以给用户说明利弊，可以按紧迫程度为开发人员提供工作重点，同时， 他们应该还能控制需求变更的频率。
◆明确合同约束，限制需求变更 需求在软件项目中的地位已经越来越重要，需求变更给软件开发带来的影响也是有目共睹，甚至因为质量低下的需求或者频繁无控制的需求变更而导致项目的失败。因此，应该让客户明白需求变更给项目带来的工期、成本等各方面的影响，在互相理解的基础上增加合同条款，比如明确说明客户可以提出需求变更的期限，超过期限的需求变更的具体处理细则(如增加开发费用等，需求变更与开发费用本身也是关联的，这个要求并不过分)。
◆良好的软件结构适应需求变更 优秀的软件体系结构可以快速应对不同情况的需求变
更，这样就可以适当降低需求的基线（当然是在成本影响的允许范围内），从而来提高客户的满意度。适应需求变更必须遵循一些设计原则，如松散耦合、合理的接口定义等，要力求减少会对接口入口参数产生变化。
最新内容请见作者的GitHub页：http://qaseven.github.io/