一旦执行了软件过程评估，我询问项目组成员是如何接受产品的变更需求的，其中一位回答说“无论何时市场代表对B r u c e或S a n d y提出变更要求，他们总是说同意，我们就只好努力去做出来”。他并未正面回答我的问题。不被控制的变更是项目陷入混乱、不能按进度执行或软件质量低劣的共同原因。为了使开发组织能够严格控制软件项目应确保以下事项：
• 应仔细评估已建议的变更。
• 挑选合适的人选对变更做出决定。
• 变更应及时通知所有涉及的人员。
• 项目要按一定的程序来采纳需求变更。
只有项目风险承担者在开发过程中能控制变更，他们才知道将交付什么，哪一项将会导致与目标的差距。对项目越深入了解后，你就越能发现采纳变更需求条件的苛刻。在需求文档中一定要反映项目的变更，需求文档应精确描述要交付的产品，这就是你的原则。要是软件需求文档同产品不一致，那它就毫无用处，甚至就象没有一个软件需求文档来指导开发组开发一样。
当你不得不做出变更时，应该按从高级到低级的顺序对被影响的需求文档进行处理。举个例子，一个已建议的变更可能影响一个使用实例和功能需求但不影响任何业务需求。改动高层系统需求能够影响多个软件需求。如果在最低层需求上做出变更，（典型的情况是一个功能性需求），可能会导致需求同上层文档不一致。