一条很有用的经验规则是，计划好预先对大约80%的需求做出详细说明，并给“稍后再进行详细说明的额外需求”分配一定的时间。然后在项目进行过程中，实施系统化的变更控制措施——只接受那些最有价值的新需求。另一种替代方案是，预先只对最重要的20%的需求做出详细说明，并且计划以小幅增量开发软件的剩余部分，随着项目的进行，对额外的需求和设计做出详细说明.
在序列式开发法和迭代式开发法之间做出选择
前期准备预先要满足哪些条件，会随表3-2所列出的不同项目种类、项目的正式程度、技术环境、员工能力以及项目的商业目标变化而变化。你可能因为下列原因选择一个更加序列化的方法。
■ 需求相当稳定。
■ 设计直截了当，而且理解透彻。
■ 开发团队对于这一应用领域非常熟悉。
■ 项目的风险很小。
■ “长期可预测性”很重要。
■ 后期改变需求、设计和编码的代价很可能较昂贵。
你可能因为下列原因选择一个更加迭代（as-you-go，走着瞧）的方法。
■ 需求并没有被理解透彻，或者出于其他理由你认为它是不稳定的。
■ 设计很复杂，或者有挑战性，或者两者兼具。
■ 开发团队对于这一应用领域不熟悉。
■ 项目包含许多风险。
■ “长期可预测性”不重要。
■ 后期改变需求、设计和编码的代价很可能较低。
事实上，在软件开发中，适用迭代式开发法的情况比适用序列式开发法的情况多得多。你可以使前期准备适应某个特定项目，办法是调整其正式程度和完备程度，到你觉得合适为止。大型项目和小型项目有不同的开发方法（也称为正式项目和非正式项目有不同的开发方法），关于这点具体讨论请阅读第27章。
你应该首先确定哪些前期准备活动适合你的项目。有些项目在前期准备上面花的时间太少了，结果使得在构建活动中遇到大量不必要的反复修改，同时阻碍了项目的稳步前进。有些项目则预先做了太多的事情，固执地坚持原有的需求和计划，后来事实证明这些需求和计划是无效的，这同样阻止了构建活动的顺利进展。