第三章-三思而后行：前期准备

第三章-三思而后行：前期准备

一、需求

1.为什么要有正式的需求

（1）明确需求有助于确保用户（而非程序员）驾驭系统的功能。避免程序员在编程期自行决定需求。

（2）重视需求有助于减少开始编程开发之后的系统变更情况。如果在编码阶段发现需求错误，你可能得改变设计，重新编码，重新测试。花费大量时间。

2. 需求分析阶段主要考虑的问题

   a功能需求：

    （1）系统的输入输出是否详细定义（输入输出格式，精度，取值范围等）？

    （2）是否详细定义了软件的外部接口，相关协议（通信协议，握手协议等）？

    （3）是否包含了用户想要的所有功能？

  b. 非功能需求：

    （1）是否从用户的视角，对每一个操作描述了期望相应时间？

    （2）是否考虑了系统的处理时间，数据传输率，系统吞吐量，机器内存和磁盘空间的最小值？

    （3）是否定义了系统的安全级别和可靠性，如软件失灵的后果，发生故障时数据保护，错误检测与恢复策略等？

    （4）是否定义了系统的可维护性，如操作环境的变更，功能变更以及与其他软件接口的变更能力？

  c. 需求的质量

    （1）需求是用用户语言写的吗？用户也这样认为吗？

    （2）每条需求与需求之间存在冲突吗？

    （3）是否定义了相互竞争的特性之间的权衡，如健壮性与正确性之间的权衡？

    （4）是否每条需求都是课测试的？是否可能进行独立测试？

    （5）需求是否足够清晰？能让开发者或其他成员理解。

    （6）需求的描述是否粗细得当？

      (7)  每一条需求是否都与待解决的问题或解决方案相

  d.  需求的完备性

    （1）对于开发前无法获得的信息，是否对信息不完全的区域做了详细描述？

    （2）需求的完备度是否能达到这种程度：如果产品满足所有需求，那么它就是可接受的？

    （3）是否去掉了不可能实现的需求？

二、架构

1. 架构的典型组成部分

（1）程序组织：即系统架构的组织结构综述。

（2）主要的类

（3）数据设计：注意信息隐藏

（4）业务规则

（5）用户界面设计

（6）资源管理：管理稀缺资源

（7）安全性

（8）性能

（9）可伸缩性：能满足未来需求的能力

（10）互用性

（11）国际化、本地化

（12）输入输出：I/O错误检测

（13）错误处理：仅仅检测还是进行纠正？主动检测还是被动检测？如何处理错误？错误处理的相关约定？如何处理异常，记录log？

（14）容错性

（15）架构的可行性。

（16）过度工程

（17）“买”还是“造”？：利用开源软件，购买软件还是自己开发软件？

（18）关于复用的决策

（19）变更决策

（20）架构的总体质量