5.2 进化式需求与瀑布式需求

注意，在UP的需求管理定义中使用了“不断变更”一词。UP能够包容需求中的变更，并将其作为项目的基本驱动力。这一点极为重要，也是迭代和进化式思想与瀑布思想的核心差异。

在UP和其他进化式方法中（Scrum、XP、FDD等），具有产品品质的编程和测试要远早于大多数需求的分析或规格化——或许当时只完成了10%到20%的需求规格说明，这些需求都具有重要架构意义、存在风险以及具有高业务价值。

详细的过程是怎样的？如何在迭代中结合早期设计和编程来进行局部、进化式的需求分析？可以参见2.4节。该节简要阐述了这一过程。6.21节中对此进行了详细论述。

在20世纪60年代和70年代（当时我还是个开发者），软件项目的早期需求分析（即瀑布）还仍然是完全有效力的普遍理论信条。从20世纪80年代开始，这种方法逐渐被证明是拙劣的，并且导致了大量失败。这种过时信条的错误根源是，将软件项目与大规模制造业项目视为等同，而后者是可预测的，并且具有低变更率。但是软件属于具有高变更率的新产品开发领域，具有大量新奇事物，需要大量的发现和探索。

据统计，软件项目的平均需求变更率为25%。因此，任何试图在开始就固定或定义所有需求的方法都具有本质上的缺陷，这些方法基于错误假设，因而只能拒绝或沉溺于不可避免的变更。

为了证实这一点，这里引用对1027个软件项目失败因素的研究[Thomas01]。其结论是什么？尝试瀑布实践（包含在项目开始进行详细需求分析）是导致这些项目失败的主因，其中82%的项目都将其列为头等问题。其结论如下：

……完整地定义需求，随后在其被实现之前又产生了大量差异，这样的方法不再适用。

高度变化的业务需求表明，任何假设需求一旦形成文档后就不会再有显著变更的方法都具有本质上的缺陷，花费大量时间和工作量以便最大程度地定义需求是不适当的。

另一项相关研究结果回答了下面这个问题：当试图使用瀑布式需求分析时，有多少早期定义的特性在最终的软件产品中有效？在一项对上千个项目的研究中[Johnson02]，其结论极具启示——45%的特性从未使用，此外还有19%的特性“罕有”使用。参见图5-1。几乎65%的瀑布式定义的特性少有或根本没有价值！

上述结论并不意味着要忽略需求分析或记录需求，在项目第一天就开始竭力编码。一种折中的方法是：结合早期时间定量的迭代开发，进行迭代和进化式需求分析，并且引入频繁的涉众参与、评估和对局部结果的反馈。