花费在问题定义、需求分析、软件架构上的时间，依据项目的需要而变化。一般说来，一个运作良好的项目会在需求、架构以及其他前期计划方面投入10%~20%的工作量和20%~30%的时间（McConnell 1998, Kruchten 2000）。这些数字不包括详细设计的时间——那是构建活动的一部分。

如果需求不稳定，同时你从事的是一个大型的正式项目，那你就很可能需要与需求分析师合作，以解决构建活动早期指出的需求问题。你要为“与需求分析师协商”预留一些时间，还应预留时间给需求分析师修订需求，这样你才能得到一份可行的需求。

如果需求不稳定，同时你从事的是一个小型的非正式的项目，那你很可能需要自己解决需求方面的问题。要预留足够的时间，将需求定义足够清晰，让需求的不稳定性对构建活动的负面影响降至最低。

如果需求在任何项目上都不稳定——无论正式项目或非正式项目——那就将需求分析工作视为独立的项目来做。在完成需求之后，估计项目余下的部分要花多少时间。这是明智的办法，因为在弄清楚要做的是什么之前，没人相信你能估算出合理的进度表。这就好比你是一名承包商，有人请你建一栋房子。客户问你：“完成这项工作要花多少钱？”你会合理地询问：“你想要我做什么？”客户说：“我不能告诉你，不过我想知道需要花费多少钱？”你该明智地感谢他浪费了你的时间，然后转身回家。

对于建筑物而言，如果客户在告诉你要造什么样的建筑之前要求你给出报价，这很明显是毫无道理的。而你的客户也不会希望在建筑师完成蓝图之前，你就摆出木料、榔头和钉子开始忙活，并开始花费他们的金钱。然而，人们对于软件开发的理解，往往不如对于建筑用的木条或石膏板的理解；因此你的客户可能无法立刻理解，为什么你打算将需求分析立为单独的项目。你可能需要向他们解释你的理由。

在为软件架构分配时间的时候，要使用与需求分析类似的方法。如果软件是你以前没有做过的类型，应当为“在新的领域中做设计”的不确定性预留更多时间。你要确保创建良好架构所需要的时间，不会被“为做好其他方面工作所需要的时间”所挤占。如果有必要，将架构工作也作为独立的项目来对待。