来自《代码大全2》的摘抄
来自众多组织的数据显示，在大型项目中，如果在架构阶段检测到需求错误，那么修复它的成本通常“在需求阶段检测并修复该错误”的成本的3倍。如果在编码阶段检测到需求错误，修复成本是5至10倍：在系统测试阶段，成本是10倍：在发布之后，成本陡增为10至100倍（以在需求分析阶段检测并修复错的成本为基数)。对于小型项目，管理成本较低，那么发布之后的修复成本倍数更接近5~10，比100小得多
问题定义
需求是解决问题的，首先需要一个问题定义，问题定义只定义“问题是什么”而不涉及解决方案
例如：我们不知道订单流转各个阶段的时效
问题定义是为随后的过程打下基础
需求定义
然后才能列出相应的需求，需求用来描述软件系统应该做什么是达成解决方案的第一步
需求检查清单
这个需求检查清单包含一系列的问题，用于检查项目的需求工作做得如何
具体的功能需求
- 是否指定了系统的所有输入，包括其来源、精度、值的范围和出现的频率
- 是否指定了系统的所有输出，包括其来源、精度、值的范围、出现的频率和格式
- 是否为Web页面和报表等指定了所有输出格式
- 是否指定了所有外部硬件和软件接口
- 是否制定了所有外部通讯接口，包括握手、错误检查和通讯协议
- 是否指定了用户想要执行的所有任务
- 是否指定了每个任务中使用的数据和每个任务产生的数据
特定的非功能性（质量）需求
- 从用户的角度来看，是否为所有必要的操作指定了预期的响应时间
- 是否指定了其他时间考虑因素，比如处理时间、数据传输速率和系统吞吐量
- 是否指定了安全级别
- 是否指定了可靠性，包括软件故障的后果、需要在故障中得到保护的重要信息以及错误检测和恢复策略
- 是否指定了最小机器内存和空闲磁盘空间
- 是否指定了系统的可维护性，包括适应特定功能的更改、操作环境的更改以及与其他软件接口的更改能力
- 是否包括了成功和失败的定义
需求质量
- 需求是用用户的语言编写的么？用户这么认为么？
- 每个需求都避免了与其他需求的冲突么
- 是否详细说明了竞争属性之间的可接受的这种，例如健壮性和正确性的折中
- 是否避免了在需求中规定设计
- 需求在详细程度上是一致的么，是否有需求需要更详细的说明？是否有需求不需要那么详细的说明
- 需求是否足够清晰，以至于可以移交给一个独立的团队进行构建，且不会产生误解？开发人员这么认为么？
- 每个条款都与待解决的问题及其解决方案相关么？能从每个条款上溯到在问题域中对应的根源么
- 每个需求都是可测试的么？是否有可能通过独立测试来确定每个需求都被满足了
- 是否说明了需求的所有可能变更以及每种变更的可能性
需求的完整性
- 对于在开发中无法获得的信息，是否详细描述了信息不完整的区域
- 需求的完备程度是否可以达到这种高度：如果产品满足了所有需求，就说明它是可以接受的
- 对全部需求都感到满意么？是否已经去掉了那些不可能实现的需求，那些只是为了安抚客户和老板的东西