3.5.1.1 需求变更控制
　　对许多项目来说，一些需求的改进是合理的且不可避免。业务过程、市场机会、竞争性的产品和软件技术在开发系统期间是可以变更的，管理部门也会决定对项目做出一些调整，在你的项目进度表中应该对必要的需求改动留有余地。若不控制范围的扩展将使我们持续不断地采纳新的功能，而且要不断地调整资源、进度、或质量目标，这样做极其有害。这儿一点小的改动，那儿一点添加，很快项目就不可能按客户预期的进度和预期质量交付使用了。事实上，控制范围的扩展的方法是要敢于说"不"。通过评估每一项建议的需求和特性，将它与项目的视图和范围相比较，最终决定是否应该采纳它。
　　不被控制的变更是项目陷入混乱、不能按进度执行或软件质量低劣的共同原因，因此，需求变更应该实现以下要求：
＊ 应仔细评估已建议的变更；
＊ 挑选合适的人选对变更做出决定；
＊ 变更应及时通知所有涉及的人员；
＊ 项目要按一定的程序来采纳需求变更。

3.5.1.2 需求文档的版本控制
　　版本控制是管理需求的一个必要方面。需求文档的每一个版本必须被统一确定，组内每个成员必须能够得到需求的当前版本，必须清楚地将变更写成文档，并及时通知到项目开发所涉及的人员。为了尽量减少困惑、冲突、误传，应仅允许指定的人来更新需求。
　　每一个公布的需求文档的版本应该包括一个修正版本的历史情况，即已做变更的内容、变更日期、变更人姓名以及变更原因，可以考虑给每个需求标记上版本号，当修改需求后就增加版本号。
　　版本控制的最有力方法是用一个商业需求管理工具的数据库存储需求，这些工具可以跟踪和报告每个需求的变动历史，特别是当需要恢复早期的需求时非常有意义。另外，在添加、变动、删除、拒绝一个需求后，附加一些评语描述变更的原因在将来需要讨论时将会很有用。