3.4 需求的先决条件 Requirements Prerequisite
需求详细描述软件系统应该做什么。
- 为什么要有正式的需求。明确的需求有助于：
- 确保是用户（而不是程序员）驾驭系统的功能
- 避免争论
- 减少开始编程开发后的系统变更情况
- 稳定需求的神话：稳定的需求是软件开发的圣杯（最高目标，渺茫希望），平均需求会有25%的变化
- 在构建期间处理需求变更：
- 使用需求核对表来评估需求的质量
- 确保每个人都知道需求变更的代价
- 建立一套变更控制程序
- 使用能适应变更的开发方法
- 放弃这个项目
- 注意项目的商业案例
核对表：
- 针对功能需求
- 针对非功能需求（质量需求）
- 需求的质量
- 需求的完备性
3.5 架构的先决条件 Architecture Prerequisite
软件架构是软件设计的高层部分，是用于支撑更细节的设计的框架。
架构的典型组成部分：
- 程序组织 Program Organization
- 系统架构首先要以概括的形式对有关系统做一个综述
- 选择最终组织结构的理由
- 主要构造块，各个块的功能和责任，之间的同行规则
- 主要的类 Major Classes
- 应指出每个主要的类的责任，如何与其他类交互
- 包含对类的继承体系、状态转换、对象持久化等的描述
- 数据设计 Data Design：描述所用到的主要文件和数据表的设计
- 业务规则 Business Rules：如果架构依赖于特定的业务规则，就应详细描述这些规则，并描述对系统设计的影响
- 用于界面设计 User Interface Design：详细定义Web页面格式、GUI、命令行接口等主要元素
- 资源管理 Resource Management：描述一份管理稀缺资源的计划（数据库连接、线程、句柄...）
- 安全性 Security：描述实现设计层面和代码层面的安全性的方法
- 性能 Performance：性能目标（速度、内存、成本和之间的优先顺序）
- 可伸缩性 Scalability：指系统增长以满足未来需求的能力（用户数、数据库记录数）
- 互用性 Interoperability：预计这个系统会与其他软件或硬件共享数据或资源
- 国际化/本地化 Internationlization/Localization
- 输入输出 Input/Output
- 错误处理 Error Processing：棘手，90%的代码处理异常，10%处理常规情况
- 纠正还是仅检测？
- 检测是主动的还是被动的？
- 如何传播错误？
- 处理有什么约定？
- 如何处理异常exceptions？
- 在什么层次上处理错误？
- 每个类在验证输入数据的有效性方面需要负何种责任？
- 用内置的还是自己建立一套？
- 容错性 Fault Tolerance：详细定义所期望的容错种类，增强系统的可靠性
- 架构的可行性 Architectural Feasibility：各种能力、性能目标、有限的资源...
- 过度工程 Overengineering：通常架构详细描述的系统会比需求更健壮
- 关于“买”还是“造”的决策 Buy-vs.-Build Decisions：说明自己定制的组件应该在哪些方面胜过现成的
- 关于复用的决策 Reuse Decisions：二次开发
- 变更策略 ChangeStrategy：让架构足够灵活，能够适应可能出现的变化
- 架构的总体质量 General Architectural Quality：整体，看上去自然而非拼凑
3.6 花费在前期准备上的时间长度 Amount of Time to Spend on Upstream Prerequisites
在需求、架构及其他前期计划方面投入：
- 10%~20% 工作量
- 20%~30% 时间