应变之道 浅析需求变更管理(1)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

重视需求开发

需求开发是在问题及其最终解决方案之间架设桥梁的第一步，是软件需求过程的主体。一个项目的目的就是致力于开发正确的系统，要做到这一点就要足够详细地描述需求，也就是系统必须达到的条件或能力，使用户和开发人员在系统应该做什么，不应该做什么方面达成共识。

我们都知道开发软件系统最为困难的部分就是准确说明开发什么，最为困难的概念性工作便是编写出详细技术需求，这包括所有面向用户、面向机器和其它软件系统的接口。

需求开发就是为了解决这些问题，它必不可少的成果就是对项目中描述的用户需求的普遍理解，一旦理解了需求，分析者、开发者和用户就能探索出描述这些需求的多种解决方案。

这一阶段的工作一旦做错，将最终会给系统带来极大损害的部分，由于需求获取事物造成的对需求定义的任何改动，都将导致设计、实现和测试上的大量返工，而这时花费的资源和时间将大大超过仔细精确获取需求的时间和资源。

首先，软件需求不能如实反映用户的真正需要。比较常见的一种误解是需求的简单和复杂程度决定了用户是否能够真正理解相应的内容：误认为客户只能看懂简单的需求，但是对开发没有直接帮助；只有复杂的需求才有用，但是大多用户又不可能看得懂。事实上，造成这类问题的主要原因是捕获的需求不能反映用户的视角，因而，用户站在自己的立场上很难判断需求是否完备和正确，特别是在开发活动的早期。

其次，软件需求不能被开发团队的不同工种直接共用。理论上，开发团队所有成员的工作内容都受软件需求制约；现实中，如果不采用理想的需求捕获方式，只有分析人员的工作看起来和软件需求的内容直接关联，其它人的工作内容和软件需求的关联并不直观，形式上的差异或转述往往不易察觉地造成了诸多歧义、冗余或者缺失。