需求检查清单

来自《代码大全2》的摘抄
来自众多组织的数据显示，在大型项目中，如果在架构阶段检测到需求错误，那么修复它的成本通常“在需求阶段检测并修复该错误”的成本的3倍。如果在编码阶段检测到需求错误，修复成本是5至10倍：在系统测试阶段，成本是10倍：在发布之后，成本陡增为10至100倍（以在需求分析阶段检测并修复错的成本为基数)。对于小型项目，管理成本较低，那么发布之后的修复成本倍数更接近5~10，比100小得多

问题定义

需求是解决问题的，首先需要一个问题定义，问题定义只定义“问题是什么”而不涉及解决方案

例如：我们不知道订单流转各个阶段的时效

问题定义是为随后的过程打下基础

需求定义

然后才能列出相应的需求，需求用来描述软件系统应该做什么是达成解决方案的第一步

需求检查清单

这个需求检查清单包含一系列的问题，用于检查项目的需求工作做得如何

具体的功能需求

• 是否指定了系统的所有输入，包括其来源、精度、值的范围和出现的频率
• 是否指定了系统的所有输出，包括其来源、精度、值的范围、出现的频率和格式
• 是否为Web页面和报表等指定了所有输出格式
• 是否指定了所有外部硬件和软件接口
• 是否制定了所有外部通讯接口，包括握手、错误检查和通讯协议
• 是否指定了用户想要执行的所有任务
• 是否指定了每个任务中使用的数据和每个任务产生的数据

特定的非功能性（质量）需求

• 从用户的角度来看，是否为所有必要的操作指定了预期的响应时间
• 是否指定了其他时间考虑因素，比如处理时间、数据传输速率和系统吞吐量
• 是否指定了安全级别
• 是否指定了可靠性，包括软件故障的后果、需要在故障中得到保护的重要信息以及错误检测和恢复策略
• 是否指定了最小机器内存和空闲磁盘空间
• 是否指定了系统的可维护性，包括适应特定功能的更改、操作环境的更改以及与其他软件接口的更改能力
• 是否包括了成功和失败的定义

需求质量

• 需求是用用户的语言编写的么？用户这么认为么？
• 每个需求都避免了与其他需求的冲突么
• 是否详细说明了竞争属性之间的可接受的这种，例如健壮性和正确性的折中
• 是否避免了在需求中规定设计
• 需求在详细程度上是一致的么，是否有需求需要更详细的说明？是否有需求不需要那么详细的说明
• 需求是否足够清晰，以至于可以移交给一个独立的团队进行构建，且不会产生误解？开发人员这么认为么？
• 每个条款都与待解决的问题及其解决方案相关么？能从每个条款上溯到在问题域中对应的根源么
• 每个需求都是可测试的么？是否有可能通过独立测试来确定每个需求都被满足了
• 是否说明了需求的所有可能变更以及每种变更的可能性

需求的完整性

• 对于在开发中无法获得的信息，是否详细描述了信息不完整的区域
• 需求的完备程度是否可以达到这种高度：如果产品满足了所有需求，就说明它是可以接受的
• 对全部需求都感到满意么？是否已经去掉了那些不可能实现的需求，那些只是为了安抚客户和老板的东西