为什么要有正式的需求

要求一套明确的需求，这点很重要，理由很多。

明确的需求有助于确保是用户（而不是程序员）驾驭系统的功能。如果需求明确，那么用户就可以自行评审，并进行核准。否则，程序员就常常会在编程期间自行决定需求。明确的需求免得你去猜测用户想要的是什么。

明确的需求还有助于避免争论。在开始编程之前，先把系统的范围（scope）确定下来。如果你和另外一个程序员对于“程序应该做什么”意见不一致，你们可以查看书面的需求，以解决分歧。

重视需求有助于减少开始编程开发之后的系统变更情况。如果你在编码过程中发现了一个代码上的错误，你只需要修改几行的代码，然后就能继续工作。但是如果你在编码的时候发现了一个需求错误，那你就得改变设计，使之符合更改后的需求。你可能需要扔掉部分旧的设计，并且因为要与已经写好的代码相适应，可能导致新的设计，与在项目之初进行同样的设计相比，花费更长的时间。此外，还需要废弃那些受此次需求变更影响的代码和测试用例，还需要编写新的代码和测试用例。即便是未受影响的代码也需要重新测试，以确保其他地方的改变没有引入任何新的错误。

如表3-1报告的那样，来自众多组织的数据显示，在大型项目中，如果在架构阶段检测到需求错误，那么修复它的成本通常是“在需求阶段检测并修复该错误”的成本的3倍。如果在编码阶段检测到需求错误，修复成本是5至10倍；在系统测试阶段，成本是10倍；在发布之后，成本陡增为10至100倍（以在需求分析阶段检测并修复错误的成本为基数）。对于小型项目，管理成本较低，那么发布之后的修复成本倍数更接近5~10，比100小得多（Boehm and Turner 2004）。无论哪种情况，你都不愿意拿自己的薪水来支付这些成本。

充分详尽地描述(specify)需求，是项目成功的关键，它甚至很可能比有效的构建技术更重要（见图3-6）。关于如何清楚地描述(specify)需求，已经有了很多优秀书籍。因此，下面几节不打算讲解如何把“详细描述需求”这件事做好，而打算讲述如何判断是否已经很好地完成了需求分析，以及如何充分利用已有的需求。

图3-6 如果没有好的需求，你可能对问题有总体的把握，但却没有击中问题的特定方面

The Myth of Stable Requirements

稳定需求的神话

稳定的需求是软件开发的圣杯5。一旦需求稳定，项目就能以有序的、可预测的、平稳的方式，完成从架构到设计到编码到测试等一系列工作。这是软件的天堂！你能预测开支，而且根本无须担心实现某项特性的开销增大为原先计划的100倍——因为在你完成调试之前，用户根本没有想到这项特性。

“一旦客户接受了一份需求文档，就再也不做更改”是一个美好的愿望。然而，对一个典型的项目来说，在编写代码之前，客户无法可靠地描述他们想要的是什么。问题并不在于客户是低级生物。就如同你做这个项目的时间越长，对这个项目的理解也就越深入一样，客户参与项目的时间越长，他们对项目的理解也就越深入。开发过程能够帮助客户更好地理解自己的需求，这是需求变更的主要来源（Curtis, Krasner, and Iscoe 1988; Jones 1998; Wiegers 2003）。计划严格依照需求行事，实际上就是计划不对客户的要求做出回应。

典型情况下需求会有多少改动？IBM和其他公司的研究发现，平均水平的项目在开发过程中，需求会有25%的变化（Boehm 1981, Jones 1994, Jones 2000）。在典型的项目中，需求变更导致的返工占到返工总量的75%到85% （Leffingwell 1997, Wiegers 2003）。

也许你会认为Pontiac Aztek是至今制造的最伟大的汽车6，也许你属于地平协会（Flat Earth Society）7，并且每四年要到外星人降落的地点——新墨西哥州的Roswell——朝圣一次。假如你真的是这样，干吧，并坚信项目的需求永不改变。反过来，如果你不再信仰圣诞老人和牙齿仙女，或者至少不再承认它，那么你就可以采取一些步骤来使需求变更的负面影响最小化8。

Handling Requirements Changes During Construction

在构建期间处理需求变更

在构建期间，要最好地应对需求变更，有以下一些可以采用的方式。

使用本节末尾的需求核对表来评估你的需求的质量如果你的需求不够好，那么就停止工作，退回去，先把它做好，再继续前进。当然，因为在此期间你会停止编码，所以感觉似乎进度会落后。不过，假设你正开车从芝加哥到洛杉矶，突然看到纽约的路牌，那么停下来查看路线图是浪费时间吗？当然不是，如果没有对准正确的方向，那就要停下来检查一下路线9。

确保每一个人都知道需求变更的代价客户只要想到一个新功能就会很兴奋。在兴奋时血液会涌向大脑，人会晕头晕脑，他会把所有你们开过的讨论需求的会议、签字仪式，以及已经完成的需求文档统统抛诸脑后。最简单的对付这种新功能中毒症患者的办法是说：“咦，这听起来是一个很不错的主意。不过由于它不是需求文档里的内容，我会整理一份修订过的进度表和成本估计表，这样你可以决定是现在实施，还是过一阵子再说。”“进度”和“成本”这两个字眼比咖啡和洗冷水澡都要提神，许多“必须要有/must haves”很快会变成“有就最好/ nice to haves”。

假如你的组织对于“先做需求分析”的重要性并不敏感，那你就指出在需求阶段进行修改，要比之后进行修改的代价低得多。使用本章“关于构建之前要做前期准备的绝对有力且简明的论据”。

建立一套变更控制程序如果你的客户激情不减，那就要考虑建立一个正式的变更控制委员会，评审提交上来的更改方案。客户改变他们的想法，认识到他们需要更多的功能，这不是坏事。问题是他们提出更改方案太频繁了，让你跟不上进度。如果有一套固定的变更控制程序，那么大家都会很愉快——你知道自己只需在特定时候处理变更；而客户知道你打算处理他们的提议。

使用能适应变更的开发方法某些开发方法让你“对需求变更做出响应”的能力最大化。演进原型(evolutionary prototyping)法能让你在投入全部精力建造系统之前，先探索系统的需求。演进交付(evolutionary delivery)是一种分阶段交付系统的方法。你可以建造一小块、从用户获得一点反馈、调整一点设计、做少量改动，再多建造一小块。关键在于缩短开发周期，以便更快地响应用户的要求。

放弃这个项目如果需求特别糟糕，或者极不稳定，而上面的建议没有一条能奏效，那就取消这个项目。即使你无法真的取消这个项目，也设想一下取消它之后会是怎样的情况。在取消它之前想想它有可能会变得多糟糕。假如在某种情况下你可以放弃这个项目，那么至少也要问问自己，目前的情况和你所设想的那种情况有多大距离。

注意项目的商业案例在提到实施这个项目的商业理由的时候，许多需求事项就会从你眼前消失。有些需求作为功能特色来看是不错的想法，但是当你评估“增加的商业价值”时就会觉得它是个糟透了的主意。那些记得“考虑自己的决定所带来的商业影响”的程序员的身价与黄金相当——不过我更乐意为此建议获得现金报酬。

Checklist: Requirements

核对表：需求

这张需求核对表包含了一系列的问题——问问自己项目的需求工作做得如何。本书并不会告诉你如何做出好的需求分析，所以列表里面也不会有这样的问题。在开始构建之前，用这份列表做一次“心智健全”检查，看看你的地基到底有多坚固——用“需求里氏震级”来衡量。

并不是核对表中所有的问题都适用于你的项目。如果你做的是一个非正式项目，那么你会发现有些东西根本就不需要考虑。你还会发现一些问题你需要考虑，但不需要做出正式的回答。如果你在做一个大型的、正式的项目，你也许就要逐条考虑了。

针对功能需求

q 是否详细定义了系统的全部输入，包括其来源、精度、取值范围、出现频率等？

q 是否详细定义了系统的全部输出，包括目的地、精度、取值范围、出现频率、格式等？

q 是否详细定义了所有输出格式（Web页面、报表，等等）？

q 是否详细定义了所有硬件及软件的外部接口？

q 是否详细定义了全部外部通信接口，包括握手协议、纠错协议、通信协议等？