在软件开发过程中软件开发需求的变更会给软件开发带来不确定性，但只要把软件开发需求变更作为重点、难点小心加以控制，软件开发的进度、成本和质量也就有了"安全"的基础。

根据软件工程思想，软件开发需求说明书一般要经过论证，如果在软件开发需求说明书经过论证以后，需要在原有软件开发需求基础上追加和补充新的软件开发需求或对原有软件开发需求进行修改和削减，均属于软件开发需求变更。

软件开发需求变更的出现主要是因为在项目的软件开发需求确定阶段，用户往往不能确切地定义自己需要什么。用户常常以为自己清楚，但实际上他们提出的软件开发需求只是依据当前的工作所需，而采用的新设备、新技术通常会改变他们的工作方式;或者要软件开发的系统对用户来说也是个未知数，他们以前没有过相关的使用经验。随着软件开发工作的不断进展，系统开始展现功能的雏形，用户对系统的了解也逐步深入。于是，他们可能会想到各种新的功能和特色，或对以前提出的要求进行改动。他们了解得越多，新的要求也就越多，软件开发需求变更因此不可避免地一次又一次出现。

软件开发需求变更控制一般要经过变更申请、变更评估、决策、回复这四大步骤。如果变更被接受，还要增加实施变更和验证两个步骤，有时还会有取消变更的步骤。变更控制流程如图所示。针对变更控制流程，笔者在实际工作中总结出了软件开发人员在软件开发需求变更管理实践中的几点对策：

相互协作　很难想像遭到用户抵制的项目能够成功。在讨论软件开发需求时，软件开发人员与用户应该尽量采取相互理解、相互协作的态度，对能解决的问题尽量解决。即使用户提出了在软件开发人员看来"过分"的要求，也应该仔细分析原因，积极提出可行的替代方案。

充分交流　软件开发需求变更管理的过程很大程度上就是用户与软件开发人员的交流过程。软件开发人员必须学会认真听取用户的要求、考虑和设想，并加以分析和整理。同时，软件开发人员应该向用户说明，进入设计阶段以后，再提出软件开发需求变更会给整个软件开发工作带来什么样的冲击和不良后果。

安排专职人员负责软件开发需求变更管理　有时软件开发任务较重，软件开发人员容易陷入软件开发工作中而忽略了与用户的随时沟通，因此需要一名专职的软件开发需求变更管理人员负责与用户及时交流。

合同约束　软件开发需求变更给软件开发带来的影响有目共睹，所以在与用户签订合同时，可以增加一些相关条款，如限定用户提出软件开发需求变更的时间，规定何种情况的变更可以接受、拒绝接受或部分接受，还可以规定发生软件开发需求变更时必须执行变更控制流程。

区别对待　随着软件开发进展，有些用户会不断提出一些在项目组看来确实无法实现或工作量比较大、对项目进度有重大影响的软件开发需求。遇到这种情况，软件开发人员可以向用户说明，项目的启动是以最初的基本软件开发需求作为软件开发前提的，如果大量增加新的软件开发需求(虽然用户认为是细化软件开发需求，但实际上是增加了工作量的新软件开发需求)，会使项目不能按时完成。如果用户坚持实施新软件开发需求，可以建议用户将新软件开发需求按重要和紧迫程度划分档次，作为软件开发需求变更评估的一项依据。同时，还要注意控制新软件开发需求提出的频率。

选用适当的软件开发模型　采用建立原型的软件开发模型比较适合软件开发需求不明确的软件开发项目。软件开发人员先根据用户对软件开发需求的说明建立一个系统原型，再与用户沟通。一般用户看到一些实际的东西后，对软件开发需求会有更为详细的解释，软件开发人员可根据用户的说明进一步完善系统原型。这个过程重复几次后，系统原型逐渐向最终的用户软件开发需求靠拢，从根本上减少软件开发需求变更的出现。目前业界较为流行的叠代式软件开发方法对工期紧迫的项目的软件开发需求变更控制很有成效。

用户参与软件开发需求评审　作为软件开发需求的提出者，用户理所当然是最具权威的发言人之一。实际上，在软件开发需求评审过程中，用户往往能提出许多有价值的意见。同时，这也是由用户对软件开发需求进行最后确认的机会，可以有效减少软件开发需求变更的发生。