一旦执行了软件过程评估，我询问项目组成员是如何接受产品的变更需求的，其中一位
回答说“无论何时市场代表对B r u c e或S a n d y提出变更要求，他们总是说同意，我们就只好努
力去做出来”。他并未正面回答我的问题。不被控制的变更是项目陷入混乱、不能按进度执行
或软件质量低劣的共同原因。为了使开发组织能够严格控制软件项目应确保以下事项：
• 应仔细评估已建议的变更。
• 挑选合适的人选对变更做出决定。
• 变更应及时通知所有涉及的人员。
• 项目要按一定的程序来采纳需求变更。
只有项目风险承担者在开发过程中能控制变更，他们才知道将交付什么，哪一项将会导
致与目标的差距。对项目越深入了解后，你就越能发现采纳变更需求条件的苛刻。在需求文
档中一定要反映项目的变更，需求文档应精确描述要交付的产品，这就是你的原则。要是软
件需求文档同产品不一致，那它就毫无用处，甚至就象没有一个软件需求文档来指导开发组
开发一样。
当你不得不做出变更时，应该按从高级到低级的顺序对被影响的需求文档进行处理。举
个例子，一个已建议的变更可能影响一个使用实例和功能需求但不影响任何业务需求。改动
高层系统需求能够影响多个软件需求。如果在最低层需求上做出变更，（典型的情况是一个功
能性需求），可能会导致需求同上层文档不一致。
17.1 控制项目范围的扩展
Capers Jones（1 9 9 4）在报告中声称扩展需求对百分之八十的管理信息系统项目和百分之
七十的军事软件项目造成风险。扩展需求是指在软件需求基线已经确定后又要增添新的功能
或进行较大改动。问题不仅仅是需求变更本身，而是迟到的需求变更会对已进行的工作有较
大的影响。要是每个建议的需求都被采纳，对于项目出资者（ s p o n s o r）、参与者与客户来说项
目将永远也不会完成—事实上，这是不可能的。
对许多项目来说，一些需求的改进是合理的且不可避免。业务过程、市场机会、竞争性
的产品和软件技术在开发系统期间是可以变更的，管理部门也会决定对项目做出一些调整。
在你的项目进度表中应该对必要的需求改动留有余地。若不控制范围的扩展将使我们持续不
断地采纳新的功能，而且要不断地调整资源、进度、或质量目标，这样做极其有害。这儿一
点小的改动，那儿一点添加，很快项目就不可能按客户预期的进度和预期质量交付使用了。
管理范围扩展的第一步就是把新系统的视图、范围、限制文档化并作为业务需求的一部
分，正如第6章所描述的。评估每一项建议的需求和特性，将它与项目的视图和范围相比较决
定是否应该采纳它。强调客户参与的有效的需求获取方法能够减少遗漏需求的数量，只在做
出提交承诺和分配资源后才采纳该需求(Jones 1996a)。控制需求扩展的另一个有效的技术是
原型法，这个方法能够给用户提供预览所有可能的实现，以帮助用户与开发者沟通从而准确