软件开发项目需求变更管理及应对之

软件开发工程需求变更经管及应对之道研究

变化并不是人们最害怕的，最怕的是跟不上变化的步 伐。同样，在软件开发过程中需求的变更会给开发带 来不确定性，但只要把需求变更作为重点、难点小心 加以控制，软件开发的进度、成本和质量也就有了

安全 \"的基础。

需求变更经管的需求

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

需求变更的出现主要是因为在工程的需求确定阶段， 用户往往不能确切地定义自己需要什么。用户常常以 为自己清楚，但实际上他们提出的需求只是依据当前 的工作所需，而采用的新设备、新技术通常会改变他 们的工作方式。或者要开发的系统对用户来说也是个 未知数，他们以前没有过相关的使用经验。

随着开发工作的不断进展， 系统开始展现功能的雏形，

用户对系统的了解也逐步深入。于是，他们可能会想

到各种新的功能和特色，或对以前提出的要求进行改

动。他们了解得越多，新的要求也就越多，需求变更

因此不可避免地一次又一次出现。

这时，如果开发团队缺少明确的需求变更控制过程或

采用的变更控制机制无效，抑或不按变更控制流程来

经管需求变更，那么很可能造成工程进度拖延、成本

不足、人力紧缺，甚至导致整个工程失败。当然，即

使按照需求变更控制流程进行经管，由于受进度、成

本等因素的制约，软件质量还是会受到不同程度的影

响。但实施严格的软件需求经管会最大限度地控制需

求变更给软件质量造成的负面影响，这也正是我们进

行需求变更经管的目的所在。

六大原则

实施需求变更经管需要遵循如下原则：

1. 建立需求基线。需求基线是需求变更的依据。在开

发过程中，需求确定并经过评审后 （ 用户参与评审 ），

可以建立第一个需求基线。此后每次变更并经过评审

后，都要重新确定新的需求基线。

2. 制订简单、有效的变更控制流程，并形成文档。在

建立了需求基线后提出的所有变更都必须遵循这个控

制流程进行控制。 同时， 这个流程具有一定的普遍性，

对以后的工程开发和其他工程都有借鉴作用。

3. 似

成立工程变更控制委员会 (CCB) 或相关职能的类

组织， 负责裁定接受哪些变更。 CCB 由工程所涉及的

多方人员共同组成，应该包括用户方和开发方的决策

人员在内。

4. 需求变更一定要先申请然后再评估，最后经过与变

更大小相当级别的评审确认。

5. 需求变更后，受影响的软件计划、产品、活动都要

进行相应的变更，以保持和更新的需求一致。

6. 妥善保存变更产生的相关文档。

应对之道

需求变更控制一般要经过变更申请、 回复这四大步骤。如果变更被接受，还要增加实施变

更和验证两个步骤，有时还会有取消变更的步骤。变

更控制流程如图所示。针对变更控制流程，笔者在实

际工作中归纳总结出了软件开发人员在需求变更经管

实践中的几点对策：

相互协作 很难想像遭到用户抵制的工程能够成功。

在讨论需求时，开发人员与用户应该尽量采取相互理

解、相互协作的态度，对能解决的问题尽量解决。即

使用户提出了在开发人员看来 \"过分 仔细分析原因，积极提出可行的替代技术方案。

充分交流 需求变更经管的过程很大程度上就是用户

与开发人员的交流过程。软件开发人员必须学会认真

听取用户的要求、考虑和设想，并加以分析和整理。

同时，软件开发人员应该向用户说明，进入设计阶段

以后，再提出需求变更会给整个开发工作带来什么样

的冲击和不良后果。

安排专职人员负责需求变更经管 重，开发人员容易陷入开发工作中而忽略了与用户的

随时沟通，因此需要一名专职的需求变更经管人员负

变更评估、 决策、

\"的要求，也应该

有时开发任务较

责与用户及时交流。

合同约束 需求变更给软件开发带来的影响有目共

睹，所以在与用户签订合同时，可以增加一些相关条

款，如限定用户提出需求变更的时间，规定何种情况

的变更可以接受、拒绝接受或部分接受，还可以规定

发生需求变更时必须执行变更控制流程。

区别对待 随着开发进展，有些用户会不断提出一些

在工程组看来确实无法实现或工作量比较大、对工程

进度有重大影响的需求。遇到这种情况，开发人员可

以向用户说明，工程的启动是以最初的基本需求作为

开发前提的， 如果大量增加新的需求 （虽然用户认为是

细化需求， 但实际上是增加了工作量的新需求 工程不能按时完成。如果用户坚持实施新需求，可以

建议用户将新需求按重要和紧迫程度划分档次，作为

需求变更评估的一项依据。同时，还要注意控制新需

求提出的频率。

选用适当的开发模型 采用建立原型的开发模型比较

适合需求不明确的开发工程。开发人员先根据用户对

需求的说明建立一个系统原型，再与用户沟通。一般

用户看到一些实际的东西后，对需求会有更为详细的

解释，开发人员可根据用户的说明进一步完善系统原

， 会使

）

型。这个过程重复几次后，系统原型逐渐向最终的用

户需求靠拢，从根本上减少需求变更的出现。目前业

界较为流行的叠代式开发方法对工期紧迫的工程的需 求变更控制很有成效。

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