（1）在开始构建之前，首先要满足的一个先决条件是，对这个系统要解决的问题做出清楚的陈述。问题定义只定义了问题是什么，而不设计任何可能的解决方案。问题定义应该用客户的语言来写，而且应该从客户的角度描述问题。
（2）需求详细描述软件系统应该做什么，这是达成解决方案的第一步。
         明确的需求有助于确保是用户（而不是程序员）驾驭系统的功能。如果需求明确，用户就可以进行自行评审，并进行核准。否则程序员就会在编程期间自行决定需求，明确的需求面对你去猜想用户需要的是什么。
         明确的需求有助于避免争论。在开始编程之前，先把系统的范围确定下来。如果你和另外一个程序员对于程序应该做什么，意见不一致，你们可以查看书面的需求，以解决分歧。
         重视需求有助于减少开始开发编程之后的系统变更情况。
         稳定的需求是软件开发的圣杯，但是这往往是软件开发人员的愿望。IBM和其他公司的研究发现，平均水平的项目在开发过程中，需求会有25%的变化。在典型的项目中，需求变更导致的返工占到返工总量的75%到85%。
（3）软件架构是软件设计的高层部分，适用于支撑更细节的设计的框架。架构的质量决定了系统的“概念完整性”，继而决定了继续的最终质量。一个慎重考虑的架构为“从顶层到底层维护系统的概念完整性”提供了必备的结构和体系，它为程序员提供了指引——其细节程度与程序员的技能和手边的工作相配。它将工作分为几个部分，使多个开发者或者开发团队可以独立工作。
         架构典型的组成部分：
         a、程序组织  
         b、主要的类：80/20法则（对构成系统的80%行为的20%的类进行详细说明）。
         c、数据设计  d、业务规则  e、用户界面设计  f、资源管理   g、安全性   
         h、性能    i、可伸缩性   j、互用性   k、国际化\本地化   l、输入输出
         m、错误处理   n、容错性   o、架构的可行性  p、过度工程   
         q、关于“买”还是“造”的决策   r、关于复用的决策   s、变更策略
（4）花费在前期准备上的时间长度：一个运作良好的项目会在需求、架构以及其他前期计划方面投入10%-20%的工作量和20%-30%的工作时间，这些时间不包括详细设计的时间，那是构建活动的一部分。