## 第1章 欢迎进入软件构建的世界 　 > checklist for Requirements ### –核对表：需求 这张需求核对表包含了一系列的问题–问问自己项目的需求工作做得如何。本书并不会告诉你如何做出好的需求分析，所以列表里面也不会有这样的问题。在开始构建之前，用这份列表做一次“心智健全”检查，看看你的地基到底有多坚固–用“需求里氏地震”来衡量。 并不是核对表中所有的问题都适用于你的项目。如果你做的是一个非正式的项目，那么你会发现有些东西根本就不需要考虑。你还会发现一些问题你需要考虑，但并不需要做出正式的回答，如果你是在做一个大型的、正式的项目，你也许就要逐条考虑了。 ### 针对功能需求 - 是否详细定义了系统的全部输入，包括其来源、精度、取值范围、出现的频率等？ - 是否详细定义了系统的全部输出，包括目的地、精度、取值范围、出现频率、格式等？ - 是否详细定义了所有输出格式（WEB页面、报表等）？ - 是否详细定义了全部外部通信接口，包括握手协议、纠错协议、通信协议等？ - 是否列出了用户想要做的全部事情？ - 是否详细定义了每个任务所用的数据，以及每个任务得到的数据？ ### 针对非功能需求（质量需求） - 是否为全部必要的操作，从用户的视角，详细描述了期望响应时间？ - 是否详细描述了其他与计时有关的考虑，例如处理时间、数据传输率、系统吞吐量？ - 是否详细定义了安全级别？ - 否详细定义了可靠性，包括软件失灵的后果、发生故障时需要保护的至关重要的信息、错误检测与恢复的策略等? - 是否详细定义了机器内存和剩余磁盘空间的最小值？ - 是否详细定义了系统的可维护性，包括适应特定功能的变更、操作系统的变更、与其他软件的接口的变更能力？ - 是否包含对“成功”的定义？“失败”的定义呢？ ### 需求的质量 - 需求是用用户的语言书写的吗？用户也这么认为吗？ - 每条需求都不与其他需求冲突吗？ - 是否详细定义了相互竞争的特性之间的权衡—例如，健壮性与正确性之间的权衡？ - 是否避免在需求中规定设计（方案）？ - 需求是否在详细程度上保持相当一致的水平？有些需求应该更详细地描述吗？有些需求应该更粗略地描述吗? - 需求是否足够清晰，即使转交给一个独立的小组去构建，他们也能理解吗？开发者也这么想吗？ - 每个条款都与待解决的问题及其解决方案相关吗？能从每个条款上溯到它在问题域中对应的根源吗？ - 是否每条需求都市可测试的？是否可能进行独立的测试，以检测满不满足各项需求？ - 是否详细描述了所有可能的对需求的改动，包括各项改动的可能性吗？ ### 需求的完备性 - 对于在开始开发之前无法获知的信息，是否详细描述了信息不完全的区域？ - 需求的完备度能否达到这种程度：如果产品满足所有的需求，那么它就是可接受的？ - 你对全部需求都感到舒服吗？你是否已经去掉了那些不可能实现的需求—那些只是为了安抚客户和老板的东西？ ### 中文要点： - 软件构建是软件开发的核心活动;构建活动是每个项目中唯一一项必不可少的工作. - 软件构建的主要活动包括:详细设计,编码,调试,集成,开发者测试(包括单元测试和集成测试). - 构建也常被称作”编码”和”编程”. - 构建活动的质量对软件的质量有着实质性的影响. - 最后,你对”如何进行构建”的理解程度,决定了你这名程序员的优秀程度. ### English Key Points： - Software construction the central activity in software development;construction is the only activity that’s guaranteed to happen on every project. - The main activities in construction are detailed design, coding, debugging, and developer testing. - Other common terms for construction are “coding and debugging” and “programming.” - The quality of the construction substantially affects the quality of the software. - In the final analysis, your understanding of how to do construction determines how good a programmer you are, and that’s the subject of the rest of the book.