阅读提示：本文作者从项目管理的角度来讨论对变化需求管理的策略。首先是讨论在构建前需求的质量，然后说明了如何在构建过程中对需求进行跟踪，最后讲述了当真正发生需求变更的时候，我们应该如何去面对。

　　需求总是在变化，客户总会有新的想法，项目好像没有终结，我们软件开发人员应对软件需求变化时，为了拥有更多的准备，应该做些什么呢？

　　这个世界唯一不变的就是变化了。月有阴晴圆缺，潮涨潮落，千年前的沧海是现在的良田，这是自然界的变化；人有悲欢离合，生老病死，这是人情世故。变化是并不一定总是给我们带来惊喜，更多的是带来意外，使得我们被迫去作一些改变来适应这种变化。

　　所以，变化也是我们人类得以从简单生物进化到今天的推动力。

　　回到我们软件需求这个论题上来，无疑，变化是需求的一个基本特性。

　　没有一成不变的需求，无论我们在正式构建之前对需求进行了多么深入的开发，和客户进行了多少回合的反复验证，而最终却不得不接受这样的现实：系统正式上线之后，在客户提交的试运行报告中，客户的需求发生了变化，或者客户又提出了新的需求等等。

　　我们的软件开发人员陷入了这样的一个困境：需求总是在变化，客户总会有新的想法，项目好像没有终结，即使验收通过，那也是草草完事，而不是想象中的那么完美。

　　这是一个残酷的现实。之所以Fred Brooks敢在1987的《没有银弹》这篇论文中强调即使不存在银弹，也能使得软件工程的生产力在十年之内提高十倍，这也是基于软件需求自身复杂性的原因。

　　在本文中，笔者从项目管理的角度来讨论对变化需求管理的策略。首先是讨论在构建前需求的质量，然后说明了如何在构建过程中对需求进行跟踪，最后讲述了当真正发生需求变更的时候，我们应该如何去面对。

　　我们先来看软件需求的生命周期，正如软件项目具有一般的过程，软件需求也有着一个普遍的生命周期，如图1所示：

图1：软件普遍的生命周期

　　图1中的项目阶段反映的是一般的项目过程，不管采用瀑布模型还是迭代开发或者是其他的软件开发生命周期模型，这样的一个基本过程都是需要遵循的。而需求的生命周期和项目的阶段也是一一对应的。

　　在项目的启动阶段，我们需要对项目进行可行性分析，完成立项报告，在这个阶段，也就种下了需求的“种子”，这个“种子”也决定了下面所有阶段的努力是否有成果，如果项目根本就是不可行的，那么就别提最后的“结果”了，“种子”是否能“萌芽”也都是个未知之数。

　　如果通过了可行性分析，完成了项目的启动过程。接下来我们就要把需求这颗“种子”种下去，通过需求调研和需求分析阶段的努力，需求的“种子”开始“萌芽”，并且一直“成长”，直到“成熟”，需求“成熟”之后，我们就可以构建需求基线，进入项目构建阶段。

　　如果对还没有“成熟”的需求就开始构建，那么后果就是在构建阶段需求的反复变化，开发人员疲于奔命。

　　对“成熟”的需求进行构建，我们所交付的才是优质的“果实”，当然，项目后期也不可避免有需求变更，这时，只要我们按照规定的流程进行需求变更，将变更控制在一个可以接受的范围，这是不会影响到我们最终的交付的“果实”。

　　做好需求变更的管理，最终的目的是为了有优质的交付品。从上面的图中，我们可以得知，首先必须要有良好的“种子”和健康的“果树”，最后才有可能结出优质的“果实”。所以，做好需求开发是有效需求变更管理的基础。