在增量开发中，你首先设计系统可以运行的最简单版本。它甚至可以不接受实际数据输入，
或者对数据进行处理。它也可以不产生输出，只需要成为一个坚实的骨架结构，以便能承受将
要在它之上发展的真实系统。它可以调用任何一个实现预定功能而设立的伪子程序。就像河蚌
刚开始产生珍珠的核——一粒沙子。
当你搭好骨架后，逐渐地往上添加肌肉和皮肤。你把每一个伪子程序变成真正的子程序。
此时你不必再假设产生结果了，你可以随意访问一个代码来产生结果。也不必使其假设接
收输入，你可以用同样的方法让它接收输入。你每次加入一点儿代码直到你最终完成它。
这种方法的发展是令人印象非常深刻的。Fred Brooks，在1975年时还认为：“应做好建造
一个扔掉一个的准备”，在1987 年时，却说在过去的岁月里，还没有一样东西像增量概念这样
如此深刻地改变了他自己的实践或效率。
增量隐喻的力量在于：作为一个隐喻，它并没有过分作出许诺，它不像耕种隐喻那样容易
被错误延伸。河蚌育珍珠的联想对理解增量发展法或积累法有很大帮助。
2.3.4 软件创建：建造软件（ building software）
“建造”一词的想象比“写”或者“种植’软件的想象更为贴切，它与“增量”软件的想
法是基本一致的。建造隐喻暗示了许多诸如计划、准备、执行等工作阶段。如果你仔细研究这
个隐喻，你还会发现它还暗示着其它许多东西。
建造一个四英尺高的塔需要一双稳健的手、一个平台和十个完好的啤酒罐。而建造一个四
百英尺高的塔却决不仅仅是需要一千个啤酒罐就够了，它还需要一种完全不同的计划和创建方
法。
如果你想建一个简单的建筑物，比如说一个狗舍，你买来了木板和钉子，到下午的时候，
你已经给你的爱犬造好了一幢新房子，假设你忘了修一个门，不过这没关系，你可以补救一下
或推倒一节重新开始。你所浪费的不过是一个下午的时间罢了。这与小型软件的发展失败非常
类似。如果你有25 行代码设计错了。那你重新再来一遍好了，你不会因此浪费许多的。
然而如果你是在造一幢房子，那修建的过程就要复杂些了，而拙劣设计的后果也严重得多。
首先，你必须决定造一幢什么样的房子，这就像软件开发中的问题定义。然后，你与建筑师必
须搞出一个你们都同意的总体方案，这和软件的总体设计是一样的。接着，你又画出细节蓝图
并找来一位承包商，这相当于软件中的详细设计。下面的工作是选好房址、打地基、建造起房
屋的框架、建好墙壁并加上屋顶、用千斤锤检查墙壁是否垂直，这同软件创建基本差不多。当
房屋的绝大部分工作已经完成时，你请来园艺师和装修师，以便使你的房间和空地得到最好的
利用，这可以与软件优化相类似。在整个过程中，会有各种监督人员来检查房址、地基、框架、
供电系统和其它东西，这也可以与软件开发中的评审和鉴定相类似。
较大的规模和复杂性往往意味着可以产生较大的成果。在修房子的时候，材料可能比较贵，
但更大的花费是劳动力。拆掉一面墙并把它移到六英尺之外是很昂贵的，但并不是因为你浪费
了许多钉子，而是因为你需要付出劳动。你应该尽可能精心设计，以避免那些本可避免的错误，
以降低成本。在开发软件过程中，材料更便宜，然而劳动力成本却更高。改变一个报告的格式，
可能与移走一幢房子里的墙壁一样昂贵，因为二者成本的主要部分都是劳动力。

这两个活动之间还有什么类似之处呢？在建房子中，你不会去建造那些你可以现成买来的
东西，比如洗衣机、烘干机，电冰箱、吸尘器等，除非你是个机械迷。同时，你也会去购买已
经做好的地毯、门、窗和浴室用品，而不是自己动手建。如果你正在建造一个软件，你也会这
样做。你会推广使用高级语言的特点，而不是去编写操作系统一级的代码。你也会利用已经存
在的显示控制和数据库处理系统，利用已经通过的子程序。如果样样都自己动手是很不明智的。
如果你想修建一幢陈设一流的别墅，情况就不同了，你可能定做全套家具，因为希望洗碗
机、冰箱等与你的协调一致，同时你还会定做别具风格的门和窗户。这种定做化的方式与一流
软件开发也是非常类似的。为了这一目的，你可能创建精度更高、速度更快的科学公式。你也
会设计自己的显示控制、数据库处理系统和自己的子程序，以使整个软件给人以一气呵成，天
衣无缝的感觉。
当然这两种建造方法也要付出代价，工作的每一步都要依据事先制定好的计划进行。如果
软件开发工作的顺序有误，那么这个软件将是难以编码、难以测试和难以调试的。这可能会使
整个计划延误甚至失败，因为每个人从事的工作都非常复杂，把它们综合到一起后会使人无所
适从。
如果你在盖办公楼时工作做得不好，那么在楼内办公的人便可能面临危险。同样，如果你
在创建医药、航空电子、空中交通管制、加工控制等软件时工作做得不好，后果也可能是灾难
性的。危及别人生命是劣质软件的最可怕后果，但并不是它的唯一危害。如果公司的股东们因
为你编写了错误软件而赔钱，那也是令人遗憾的。无论如何，无辜的人们没有义务为你的工作
失误而付出代价。
对于软件作修改与建造建筑物也有类似之处。如果你要移走的那面墙壁还要支撑其它东西
而不仅仅是隔开两个房间，那么你要付出的成本将会更高。同样，对软件做结构性的修改也将
比增加或减少外设特征付出更高昂的代价。
最后，建筑类比对于超大型软件也是同样适用的。一幢超大型建筑物存在错误的后果将是
灾难性的，整个工程可能不得不返工。建筑师们在制定和审查计划时是非常仔细的，他们往往
留出安全裕度，多用10％的材料来加强结构总比一幢大楼坍塌要好得多，同时还必须仔细注意
工时计划，在修建帝国大厦时，每辆卡车的每次卸货时间都留出了十五分钟的裕度。因为如果
有一辆卡车不能在指定时间到达指定的位置，整个计划就有可能被延误。
同样，对于超大型软件来说，计划工作需要比一般的大型软件在更高的层次上进行。1977
年，CapersJones 估计说，对于一个拥有750，000 行代码的系统来说，可能需要多达600 页的
功能定义文件。对于一个人来说，不要说理解这种规模全部的设计，就是读完它也是非常困难
的。安全系数对于这种项目是必须的，制定该系统的工时计划尤为重要。当我们在建造与帝国
大厦同等经济规模的软件时，我们也需要同等严密的计划。而我们现在才刚刚开始考虑这种规
模项目的计划技术。
这两者之间的相似还可以推广到其它方面，这就是为什么建筑物创建隐喻是如此强有力的
原因。许多常用的软件词汇来源于建筑学，如：软件体系结构、搭结构架、构造、分割代码、
插入子程序等等。
2.3.5  实用软件技术：智能工具箱（ The Intellectual Toolbox）
在过去的十几年中，优秀的软件开发人员们积累了几十条关于开发软件的技术和技巧，有

些像咒语般灵验，这些技术不是规则，它们是分析工具。一个优秀的工匠知道用什么样的工
具干哪一样工作，而且知道该如何使用它们。程序员也是如此，关于编程你理解得越深入，
你的工具箱里的工具也就越多，何时何地该如何运用它们的知识也就越多。
把方法和技巧当作工具是很有益处的，因为这样可以使我们对其有一个正确的态度。不
要把最新的“面向对象设计技术”当作上帝赐予的法宝，它不过是一件在某些场合下有用，
而在某些场合下又无用的技术。如果你拥有的唯一工具就是一把锤子，那么你就会把整个世
界都当作一个钉子。好在没有人会花500 美元一天的费用来雇佣一个仅告诉你去买一把可以
解决一切问题的锤子的研究小组，也没有人建议你丢掉你的改锥、手钻和电烙铁。
在软件开发中，常常会有人告诉你用一种方法来代替另外一种方法。这实在不幸，如果
你仅仅采用一种方法，那你就会把整个世界都当成那个工具的作用对象。你会失去用更适合
的方法解决问题的机会。工具箱隐喻有助于我们保留一切方法、技巧、技术等，并在适当的
时候使用它们。
2.3.6 复合隐喻（ Combing Metaphors）
因为隐喻更像是一种启发，而不是公式，所以，它们并不是互相排斥的。你可以同时使
用增量隐喻和建筑隐喻。如果你愿意的话，你也可以采用“写”隐喻，或者把写隐喻与耕种
隐喻一起使用。只要能激发你的思想，你尽可以采用一切你认为合适的隐喻。
使用隐喻是一项模糊的事情。你不得不把它们外推到可以从中受到启发的外延中。如果
你把它过分外推或者推广到了错误方向，它很可能使你误入歧途。就像是再好的工具也有可
能被误用一样，你也可能错误使用隐喻。但是，它们的作用将无可置疑地使其成为你的智能
工具箱中的一件有力工具。
2.4  小  结
隐喻仅仅是启发，而不是公式，因此，它们更倾向于比较随便，无拘无束。
•  隐喻通过把软件开发与你所熟知的事情联系在一起，从而使你对其有更深刻的理解。
•  一些隐喻要好于其它隐喻。
•  把软件创建与建造建筑物类比，表明开发软件前要精心准备，并表明了大规模项目与小
规模项目之间的差别。
•  认为软件开发实践是智能工具箱中的工具进一步表明，每个程序员都有许多自己的工
具，没有任何一种工具是万能的。为每件工作选择合适的工具，是成为一个优秀程序员
的首要素质之一。

第三章软件创建的先决条件
目录
  3.1  先决条件重要性
    3.2  问题定义先决条件
    3.3  需求分析先决条件
    3.4  结构设计先决条件
    3.5  选择编程语言先决条件
    3.6  编程约定
    3.7  应花在先决条件上的时间
    3.8  改变先决条件以适应你的项目
3.9  小结
相关章节
· 不同规模程序的不同条件：见第21 章
· 管理创建：见第22 章
· 设计：见第7 章
在开始修造一幢房屋之前，建筑工人会评审蓝图，确认所有用料已经备齐，并检查房子的
地基。建筑工人为修建摩天大楼和修建狗舍所做的准备工作是截然不同的。但不管是什么样的
项目，准备工作总是和需要相适应的，并且应在工程正式开始前做完。
本章主要论述在软件创建之前所要做的准备工作，对于建筑业来说，项目的成败往往在开
工前就已经决定了。如果基础打得不好，或者项目计划进行得不充分，你所能做的最多也就是
防止计划失败，根本谈不上做好。如果你想做一件精美的首饰，那么就得用钻石作原料。如果
你用的是砖头，那你所能得到的最好结果不过是块漂亮的砖头而已。
虽然本章讲的是软件创建基础工作，但并没有直接论述创建工作。如果你觉得不耐烦，或
是你对软件工程生存期循环已经很熟悉了，那么请跳过本章而直接进入下一章。
3.1  先决条件重要性
优秀程序员的一个突出特点是他们采用高质量的过程来创建软件。这种过程在计划的开始、
中间和末尾都强调高质量。
如果你只在一个计划即将结束时强调质量，那你注重的只是测试。当某些人一谈起软件质
量时，他们首先想到的便是测试。然而，事实上测试只是全部质量控制策略的一部分。而且并
不是最重要的部分。测试既不能消除在正确方向上的错误工作，也不能消除在错误方向上的正
确工作的错误，这种错误必须在测试开始之前就清除掉，甚至在创建工作开始之前就要努力清
除掉它们。

如果你在一个计划的中间强调质量，那么你强调的是创建活动，这一活动是本书论述的中
心。
如果在一个计划的开始强调质量，这意味着你计划并要求设计一种高质量的产品。假设你
在过程开始时要求设计的是一种菲亚特汽车，你尽可以用你所喜欢的各种手段测试它，但是无
论你怎样测试，它也决不会变成一辆罗尔斯——罗伊斯牌汽车。或许你所得到的是一辆最好的
菲亚特汽车，但如果你想要的是罗尔斯——罗伊斯车，你就不得不从计划开始时就提出要求。
在软件开发中，当你进行诸如问题定义、规定解决办法等等计划工作时，你所进行的就是这样
的工作。
由于创建工作处在一个计划的中间，所以，当你开始创建工作时，早期的工作已经奠定了
项目成败的基础。在创建工作中，至少你应该知道自己的处境如何，当你发现失败的乌云从地
平线上升起时，赶快返回第一阶段。本章其余部分主要讲述准备工作已经作好了。
3.1.l  造成准备不足的原因
你也许会认为所有的职业程序员都懂得准备工作的重要性，并且在开始正式工作之前确认
所有的先决条件都已得到满足。不幸的是，事实并非如此。
一些程序员并不作准备工作，因为他们抵制不了立刻开始进行编码工作的渴望。如果你就
是这种程序员，那我对你有两条忠告。第一，阅读一下下一部分工作的内容提示，或许你会从
中发现一些你没想到的问题。第二，要注意自己的问题。只要创建过几个大的程序，你就会明
白强调准备工作的必要性。不要忘记自己的经验教训。
程序员不重视准备工作的另一个原因是管理人员往往不理解那些在创建先决条件上花费时
间的程序员。Ed Yourdon和Tom DeMarco等人强调准备工作已经有十五年了。在这期间，他
们不时地敲响警钟，或许有一天，管理人员们最终会明白软件开发不仅仅是编写代码。
八十年代后期，我曾经在一项军用项目的某一部门中工作。当项目进行到需求分析阶段时，
负责这个计划的一位将军前来视察。我们告诉了他目前所处的阶段，并主要谈论了文件编写工
作，而这位将军却坚持要看一下代码，我们告诉他目前还没有代码，而他却走进一间正有一百
多人工作的房间，转了一圈，企图找到谁在编码。由于未能如愿以偿，他变得有些气急败坏，
这位身材高大的将军指着自己身边的工程师喊道：“他在干什么？他一定是在写代码。”事实上，
这位软件工程师正在进行文档格式编排的工作，由于这位将军想得到代码，认为那看起来像代
码并且想让工程师编码，所以我们不得不骗他说这位工程师写的确实是代码。
这可以称为WISCA 或WIMP 现象，即：为什么Sam 没有正在写代码？或Mary 为什么没
正在编程？
如果你正在从事的项目经理像那个将军一样，命令你立刻开始编码，说声“是，长官”是
很容易的。但这是一个坏的反应，你应该还有几个替代办法。
第一，你应该平静地拒绝按照错误顺序工作。如果你与老板的关系很正常的话，那么这太
好了。
第二，你可以假装正在编码而事实上没有。把一个旧的程序清单放到桌角上，然后埋头从
事你的要求和构想文件编写工作，不管你的老板同不同意。这样你可以把工作做得更快更好。
从你老板的观点来看，这个忽视是一个福音。
第三，你可以用技术项目的开发方式来教育一下老板。这是一个好办法因为这可以增加这

个世界上开明老板的数量。在下一部分，我们将给出更多在创建活动前做好准备工作的理由。
最后，你可以另找一份工作。优秀的程序员是非常短缺的。可以找到更好的工作，干吗非
要呆在一个很不开明的程序店里，徒损生命呢？
3.1.2 在进行创建工作之前必须做准备工作的论据
假设你已经登上了问题定义的山峰，与负责需求分析的人并肩走了一英里，在结构设计之
泉中，洗净了你沾满灰尘的衣服，并且沐浴在已经作好准备的纯洁之水中。那么你就会知道在
实现一个系统之前，你应该清楚需要一个系统干什么和需要怎样去干。
作为一个工程技术人员，教育你周围的人，让他们懂得技术项目的开发过程，也是你工作
的一部分。本书的这一部分可以帮你对付那些还不懂得技术项目开发过程的老板和管理人员。
它是关于进行构造设计和问题定义设计权利的延伸论据。在你进行编码、测试和调试之前，学
会这些论据，并且和你的老板推心置腹地谈谈技术项目的开发过程。
求助于逻辑推理
进行有效程序设计的关键之一就是认识到准备工作是非常重要的。在进行一项大的项目
之前，事先做好计划是明智的。项目越大，需要的计划工作量也越大，从管理人员的角度来看，
计划是指确定一个项目所需要的时间、人力、物力和财力。从技术人员的观点来看，计划是指
弄清楚你想要干什么，以免做出错误的工作而徒耗精力与钱财。有时候你自己并不十分清楚自
己想要的到底是什么？起码刚开始是这样。这时，就会比清楚知道用户需求的人要付出更多努
力，但是，这总比做出一件错误的东西，然后把它扔掉，再从头开始的成本要低得多。
建造一个系统之前，弄清楚怎样开始和如何建造它也是非常重要的，你当然不希望在完全
没有必要的情况下，浪费时间与钱财去钻死胡同而白白增加成本。
求助于类比
创建一个软件系统与其它需要耗费人力与财力的工程是一样的。如果你要造一幢房子，在
开始砌第一块砖之前，你必须事先画好建筑图与蓝图。在你开始浇铸水泥之前，你必须让人评
审你的蓝图并获得通过，在软件开发中事先做计划也与此类似。
在你把圣诞树立起来后，你才会开始装饰它，在没有修好烟囱之前你也不会点燃炉火的，
同样，也没有人会打算在油箱空空的情况下踏上旅程，在软件开发中，你也必须按照正确的顺
序来进行。
程序员处于软件开发食物链的最后一环。结构设计吃掉需求分析；详细设计者以结构设计
者为食，而他自己又成为编码者的食物。
比较软件食物链和真正的食物链，我们会发现如下事实，在一个正常的生态系统中，海鸥
以沙丁鱼为食，沙丁鱼吃鲜鱼，鲜鱼吃水虱，其结果会形成一个正常的食物链。在编程工作中，
如果软件食物链的每一级都可以吃到健康的食物，其结果是由一群快乐的程序员写出的正确代
码。
在一个被污染了的环境中，水虱在受到核沾染的水中游泳，鲫鱼体内积聚了滴滴涕，而沙
丁鱼生活的水域又遭受了石油污染，那么，不幸的海鸥由于处在食物链的最后一环，因此，它
吃的不仅仅是沙丁鱼体内的石油，还有鲜鱼体内的滴滴涕和水虱体内的核废料。在程序设计中,

如果需求定义遭受了污染，那么这又会影响结构设计，而这将最终影响创建活动。这将导
致程序员们脾气暴躁而营养不良，同时生产出遭受严重污染而充满缺陷的软件。
求助于数据
过去十五年的研究证明，一次完成是最好的选择，不必要的修改是非常昂贵的。
TKW的数据表明，在项目的初期阶段进行设计更改，比如在需求定义和结构设计阶段进行
更改，与在项目的后期，即创建和维护阶段进行更改相比较，其成本要低50 到100倍（Boehm
和Pappecio，1988）。
对IBM的研究也表明了同样结果。在设计开始阶段，如详细设计、编码或单元测试阶段就
消除错误，其成本要比在后期即系统测试和功能强化阶段低10 到100 倍（Fagan，1976）。
通常的准则是，一旦引人错误，就尽早发现和消除它。错误在软件食物链中存留的时间越
长，它的危害也就传播得越远。因为需求分析是我们做的第一项工作，因此这时引入的错误在
系统中存留时间最长，危害最大。在软件开发初期引入的错误往往比后来引入的错误传播的面
更广，这也使得早期错误会极大地提高成本。
由Robert Dunn 总结的表3-1，给出了由于错误引入和发现时间不同，而产生修复它们所
要耗费的相对成本差异。
表3-1
错误发现时间需求分析细节设计编码
需求分析1 — —
细节设计2 1 —
波动测试5 2 1
结构测试15 5 2
功能测试25 10 5
表3-1 的数据表明，在需求分析阶段引入的错误，如果马上发现并消除所耗费的成本是1000
美元的话，那么如果到了功能测试阶段才发现和消除，耗费的成本则会高达25000美元。这说
明我们应该尽早地发现并消除错误。
如果你的老板不相信这些数据，那你可以告诉他，立刻开始编码的程序员往往要比那些先
作计划、而后才编码的程序员花费更长的时间，由NASA 计算机科学公司和马里兰大学联合建
立的软件工程实验室的研究表明，过分地使用计算机（进行编辑、编译、链接、测试等）往往
与低生产率紧密相联。而在计算机旁花费较少时间的程序员，往往更快地完成工作。这是由于
频繁使用计算机的程序员在进行编码和测试之前，花在计划和设计上的时间较少。
老板的意愿测试
当你认为老板已经理解了在开始创建工作之前进行准备工作的重要性，那么情进行下面
的测验以证实这一点。
下面这些说法哪些是正确的？
· 我们最好马上就开始编码因为我们将会有许多测试工作要作。
错误引入时间

· 我们没有安排许多时间进行测试，因为我们不会发现很多错误。
· 我们已经在计划和设计上花费了这么多精力，我想我们的编码和测试时不会有什么
大问题了。
以上这些都是正确的。
在本章的其余部分我们将论述如何确定先决条件是否已经得到满足。
                  3.2  问题定义先决条件
在进行创建工作之前你要满足的第一个先决条件，便是必须弄清楚你想要解决的问题是
什么。由于本书的中心内容是创建活动，因此我们不打算在这里论述如何进行问题定义。我们
只想告诉读者如何确认问题定义是否完成，这个定义的质量如何，是否足以作为创建活动的基
础。
问题定义只描述要解决的问题是什么，根本不涉及解决方法。它应该是一个简短的说明，
听起来像一个问题。比如“我们无法跟上指令系统”听起来像一个问题，也是一个好的问题定
义。而“我们需要优化数据入口系统以便跟上指令系统”则是一个糟糕的问题定义，它听起来
不像是个问题而更像是个解决方案。
问题定义的工作是在需求分析之前进行，后者是对问题的更为详尽的分析。
问题定义应该从用户的观点出发，使用用户的语言进行定义。一般来说，它不应该使用计
算机技术术语进行定义。因为最好的解决办法可能并不是一个计算机程序。比如说，你需要一
份关于年度利润的报告，而你已经拥有了一套能产生季度利润的计算机报表系统，如果你的思
路仅仅局限于计算机，那你可能会让人再写一个产生年度利润报告的程序加到这个系统中。为
达到这个目的，你不得不雇用一个程序员编写并调试出一段相应的程序。可是，要是你的思路
开阔一些的话，让你的秘书用计算器把四个季度的利润加到一起，问题不就解决了吗？
当然，如果问题是关于计算机本身时，就是个例外了。比如，计算机的编译速度太慢或者
编程工具的问题太多，那我们只能用技术术语来说明问题了。问题定义错误的后果是你可能浪
费许多时间精力去解决了一个错误问题。这种惩罚往往是双重的，因为真正的问题并没有解决。
                  3.3  需求分析先决条件
需求详细描述了一个软件系统需要解决的问题，这是找到问题答案的第一步。这项活动也
被称作“需求分析”、“需求定义”等。
3.3.1 为什么要有正式的需求
明确的需求是很重要的，因为：
明确的需求可以保证是由用户而不是程序员决定系统的功能。如果需求是很清楚的，那么
用户可以对其进行评定，并确认自己是否同意。如果需求不很清楚，那么程序员在编程过程中
就不得不自己决定系统功能，明确的需求防止对用户需求进行猜测。
明确的需求也可以避免引起争议。在开始编程之前，系统的范围已经明确确定了。如果在
编程过程中，两个程序员对系统干什么有争议，那么只要查阅一下写好的需求分析，问题就解

决了。
注意需求定义，也可以使得在开发工作开始之后，对系统作的改动最小、如果你在编码时
发现某几行有误，那么改掉这几行就是了。而如果在编码阶段发现需求有误，那么你很可能不
得不改变所有的代码以适应新的需求。
一些设计不得不被丢掉，是因为按它们要求写好的代码不具备兼容性。新设计可能要花费
很长的时间，被一同扔掉的还有受到要求变更影响的代码和测试用例，即使未受影响的代码部
分也不得不进行重新测试，以确认其他地方的变动没有引入新的错误。
IBM、GTE、TRW的数据表明．修正在总体结构阶段发现的需求错误，将比当时就发现并
修正的成本要高出5倍，如果是在编码阶段，要高出10倍，在单元或系统测试阶段，高20倍，
在验收测试阶段，高50倍，而在维护阶段，竟要比原来高出多达100倍！在较小规模的计划中，
在维护阶段修正错误的放大因子可能是20 而不是100，因为这时管理费用较低。但无论如何没
有人愿意从自己的收益中拿出这笔钱来。
充分进行需求分析是一个项目成功的关键，很可能比使用有效的创建技术还重要。关于如
何进行需求分析有许多好的论著。因此，我们不打算在随后的几部分中探讨如何进行需求分析。
我们只想告诉你如何确定需求分析已经完成，如何最充分地利用需求分析。
3.3.2 稳定需求的神话
稳定的需求可以说是软件开发的法宝。有了稳定的需求，软件开发工作可能从结构设计到
详细设计到编码，都平稳、顺利的进行。这简直是造就了软件开发的天堂。你可以预测开支，
不必担心最终会冒出一个让你多花100 倍钱的错误来。
用户一旦接受了写好的需求文件，便再也不会提出更改需求，这简直是太好了。然而事实
上，在实际项目中，用户在代码写出来之前，往往并不能确切可靠地描述出他想要的到底是什
么，这倒并不是说用户是一种低级生物。正如随着工作的进行，你对其理解越来越深刻一样，
用户对自己想要的东西，也是随着项目的进行而越来越清楚的，这也是要求变动的主要原因。
－个从不变更要求的计划，事实上是一个对用户的要求不予理睬的计划。
典型的变动有多少呢？根据IBM 的调查，对于一个典型的有一百万字的需求分析，大约
25%的内容在开发过程中要进行变动。
或许你认为卡迪拉克小汽车是空前绝后的，帝国大厦将万古永存，如果真是这样的话，那
你就相信你的项目要求永远不会更好了。如果不是这样，那么或许我们可以采取一些措施，使
得由于要求变更所造成的冲击最小。
3.3.3 在创建阶段如何对付需求变化
以下是在创建阶段，为应付需求变化而应该采取的措施。
用本部分后面的检查表来评估你的需求分析质量
如果你的需求分析不是很好，那么，停止继续工作，重新返回到需求分析阶段。当然，这
样会使人觉得你已经落后了。但是，如果你在开车从芝加哥到洛杉矶的途中，发现自己到了纽
约市郊，那么停下车来看一下地图是浪费时间吗？当然不是。因此，如果你发现方向不对，赶
紧停下来检查你的方向。

让每个人都知道由于变化需求所付出的代价
雇员们往往由于自己有了新的设计想法而激动不已。在这种兴奋驱使之下，他们往往会热
血沸腾，得意忘形。什么讨论要求的会议，什么签约仪式、什么要求文件，统统都会被他们扔
在一边。对付这种人最简单办法就是对他说：“喂，先生，你的想法不错，但是由于它不在要求
文件之中，我想先做一个变动后的进度和成本估计，然后我们再决定是立刻就采用这个想法还
是以后再说”。“时间进度”和“成本”这两个词往往比咖啡和泼冷水更管用，这样说，往往会
把许多“立刻采用”变成“最好采用”。
如果你的组织机构还没有认识到需求分析的重要性，那么就请引述本章前面“进行创建活
动前满足先决条件的安全和必要论据”一节的内容，告诉他们，在要求阶段变更设计是成本最
低的办法。
建立一套更改控制过程
如果雇员们坚持更改的热情高涨，则可以考虑建立一个审查这种更改建议的正式委员会。
用户改变主意，意识到他们的软件需要更强的功能是非常正常的。但如果他们频繁地改变主意
以至于你无法跟上他们的速度，那就不正常了。这时如果拥有一套控制更改的正式过程，那将
使大家都会感到宽慰。你感到宽慰是因为现在你只在特定的时候处理变动问题。顾客也感到宽
慰是因为有专门机构处理他们的意见，会使他们感到自己倍受重视。
用开发的方法来容纳变动
一些开发方法可以极大地扩展你应付变更需求的能力。原型化开发的方法可能帮助你在
全力以赴投入工作以前，首先了解系统的需求。渐进开发的方法是指按阶段公布系统。每次你
只做一点儿，从用户那里得到一些反馈后，你再做一些调整的改动，然后再增加一些内容。这
种方法的关键是使用短周期开发方法，以便你对顾客的需求变更迅速作出反应。
放弃项目
如果需求特别稀奇古怪或者反复无常，上面那些办法全都不起作用，那就放弃这个项目。
即使你并不能真正地砍掉这个项目，你也可以考虑一下这样做会怎么样。考虑在你砍掉这个项
目之前，事情会发展到什么地步。假如在某一情况下，的确可以把这个项目扔进垃圾箱，那么
还可以考虑一下有或没有这个项目会造成什么区别。
3.3.4 检查表
需求
这个需求检查表包含一系列关于你的项目需求的自测题。本书并没有论及如何提出一份
好的需求文件，这个检查表也同样没有。但用这个检查表，你可以检验一下在创建工作时，你
的工作基础是否牢固可靠。
并不是表中所列出的每一个问题都适用于你的项目。如果你正在从事一个非正式项目，你
会发现根本不需要考虑这个问题，你也会在其中发现一些需要考虑但并不需要回答的问题。但
如果你正在从事一个大型的正视项目，我们建议你最好还是仔细考虑每一个问题。