项目估计（预估）的第一步就是要把需求和软件产品规模的大小相联系。你可以根据文本需求、图形分析模型、原型或用户界面设计来预估产品的大小。虽然对于软件大小没有完善的度量标准，但以下给出了一些常用的度量标准：
• 功能点和特性点的多少（ Jones 1996b），或者3 - D功能点的数量(Whitmire 1995)。• 图形用户界面（G U I）元素的数量、类型和复杂度。
• 用于实现特定需求所需的源代码行数。
• 对象类的数量或者其它面向对象系统的衡量标准（ Whitmire 1997）。
• 单个可测试需求的数量（ Wilson 1995）。
所有这些方法都可用于预估软件的大小，但不管采用什么方法你都必须根据经验进行选择。如果你没有记录当前项目所完成的真正结果，并和你所预估的进行比较，利用那些知识来提高你的预估能力，那么你所预测的将永远是一种猜测。积累数据是需要时间的，所以你可以把度量软件大小的标准与实际的开发工作量相联系。你的目标是建立可以使你从需求文档中预估整个软件大小的方程（等式）或者借助归纳等解决问题的方法。另一种方法是从需求中预测代码行、功能点或图形用户界面元素的数量，并使用商业预估软件作出人员水平与开发进度的合理安排。你可以从h t t p : / / w w w. m e t h o d - t o o l s . c o m获得一些可用的预估工具的信息。

含糊的和不确定的需求必定会引起你在软件大小预估中的不确定性，从而导致你的工作量和进度安排预估的不确定。因为在项目的早期阶段，需求的不确定性是不可避免的，所以在进度安排中应包括临时的事件并要合理预算资金以适应一些需求的增加和可能的超限。一个合理的住房改造项目包括了对不可预料的偶然事件，在你的项目中是否也要如法炮制呢？花一点时间考虑一下，哪些标准最适合你所主持的项目。应该意识到开发时间与产品大小或开发小组的大小没有线性关系。在产品大小、工作量、开发时间、生产率和人员技术积累时间之间是存在着复杂的关系（ Putnam and Myers 1997）。理解这种关系可以防止你陷入进度安排或人员任务安排承诺的误区（以前没有类似项目成功完成过），否则，项目开发将不会成功完成。