第三章：前期准备
前期准备的重要性
准备工作的中心目标是降低风险，架构、设计以及项目规划都需要前期准备。
数据表明，发现错误的时间要尽可能接近引入该错误的时间。缺陷在软件食物链里面呆的时间越长，它对食物链的后级造成的损害就越严重。
而需求的缺陷可能在系统中潜伏很长的时间。早发现，早治疗。
迭代开发可以减少缺乏前期准备的影响，但是会造成一定的返工成本。
定义问题的先决条件
对这个系统需要解决的问题做出清楚的陈述。问题定义应该用客户的语言来书写，应该从客户的角度描述问题。
明确的需求有助于确保用户驾驭系统的功能。充分详尽地描述需求，是项目成功的关键。
演进交付是一种分阶段交付系统的方法，你可以建造一小块，从用户获得一点反馈，调整一点设计，做少量改动，再建造一小块。
可以更快地响应用户的需求，缩短开发周期。
针对功能的需求
- 是否详细定义了系统的输入、输出（来源，精度，取值范围）
- 是否详细定义了输出格式
- 是否详细定义了所有硬件和软件的外部接口
- 是否列出了用户想要做的全部事情
- 是否详细定义了每个任务所用的数据，以及得到的数据
针对非功能需求
- 是否从用户视角定义了响应时间
- 是否详细定义了可靠性，发生故障时需要保护的至关重要的信息
- 是否详细定义了系统的可维护性
需求的质量
- 需求是用用户的语言写得吗？用户也这么认为吗？
- 需求之间不冲突吗
- 需求是否足够清晰
- 是否描述了可能对需求进行的改动
需求的完备性
- 是否详细描述了信息不完全的区域
程序架构
架构应该定义程序的主要构造块。每个构造块可能是单个类，也可能是一组协同工作的类，也可能是一个子系统，它们共同实现一种高层功能，诸如用户交互、显示web页面、解释命令、封装业务规则、访问数据等。应该明确定义各个构造块的责任。
主要的类
架构应该详细定义所用的主要的类
数据设计
架构应该描述主要的文件和数据表的设计。以及解释为什么要这么做，这些信息可以让团队的其他人洞察架构师的思想。
资源管理
架构应该描述一份管理稀缺资源的计划。比如数据库、线程、句柄等。
安全性
架构应该描述实现设计层面和代码层面安全性的方法。建立威胁模型，加密，处理用户输入数据等
还有性能，可伸缩性，互用性，输入输出，错误处理等