控制需求变更的3种解决方案

需求变更是最让开发人员头疼的事情了。 每次需求变更，都要更改设计、修改代码、重新验证……一次次的变更，把开发人员的热情逐渐消磨殆尽。

对于管理者来说，需求变更意味着增加成本、延长开发周期、拖延进度……

所以，无论开发人员还是管理者都不希望需求变更不断出现！

那么，怎么控制需求变更呢？

宝玉老师在《软件工程之美》中给出了3个控制需求变更的解决方案：

1. 提升需求确定性

2. 提高需求变更的成本

3. 降低响应需求变更的成本

下面我们来逐个剖析下这些解决方案。

• 提升需求确定性

道理浅显易懂——如果需求都是确定不变的，需求变更率就是0！

但在实际的新研项目中，这个目标却是可望而不可达的！

开发用户需求时，部分需求定义不清楚； 需求评审走过场，没有识别出软件需求与用户需求的不一致……这些都会导致需求的不稳定。

而要提升需求的确定性，对应的也有两种方法。

一是快速原型开发。 宝玉老师给出的方法是开发人员使用原型设计 工具 和用户确认界面需求以及数据交互的需求，但在一些军用软件开发的场合下，这种方法不会很适用。 对于军用开发，可以基于历史项目的经验，快速开发出软件原型，再通过与外部系统或软件联调，来确认那些待定的需求。

二是做好需求评审。 要策划好合适的人员参与需求评审，要制定需求确认准则，要使用需求评审检查单。

• 提高需求变更的成本

现实当中的需求变更太多，除了前面的需求不稳定的因素之外，还有很多是用户的随意性造成的。

在一些军用软件开发的场景中，经常会有一些系统设计师不考虑开发成本（需求的更改不是只改几行代码那样简单）不考虑变更的适宜性（比如已经完成功能验证准备出厂试验的时候还提出增加一些不太重要的功能需求）随意地提出一些需求变更，软件开发人员响应了这些需求，后面引入新的缺陷、推迟了进度就都是开发人员的责任。

这就是没有需求变更成本造成的。

要控制需求变更的随意性，就应提高变更的成本。 比如： 需求变更的有严格的审批流程，不能任由系统设计师说变就变； 开发人员加强需求变更影响分析，提供预计的变更成本供管理者做决策； 对需求变更进行统计，作为对系统设计师的能力考核依据……

• 降低响应需求变更的成本

最后一种控制需求变更的方法是接受需求变更，但要降低响应变更的成本。 可以考虑的方法有：

一是采用迭代开发模型。 先开发和交付已确定的需求，把待定的需求放在后续的迭代过程开发。

二是逐步推进软件复用开发。 建立通用的开发框架和可重用构件，把功能需求构件化，需求变更时只要添加或减少对应的构件即可。

三是搭建自动化测试环境，对于变更的软件单元，可以实现自动化测试，以减少更改后的验证成本。

在实际项目中，以上3种解决方案应当混合使用，以追求需求变更控制的最佳效果。

这正是：

需求变更免不了，开发管理都苦恼

解决方案有三种，控制变更烦恼少

作者简介： 王小双，长期从事GJB5000推广、实施、评价、改进的工作，创建《软件工程之思》微信公众号，一直在《软件工程之思》分享GJB5000、CMMI、软件工程的知识和感悟。 现致力于GJB5000咨询以及软件过程改进、软件工程能力提升的研究工作。