我们可以将一份好需求整体总结为以下8个特点：完整性、可行性、可验证性、不含糊性、一致性、正确性、可理解性、可修改性。
1、完整性
所有外部需求都应被确认。
需求包含功能、性能、设计限制、接口等关键要素。
软件外部的输入数据类别应完整，要明确指定对有效和无效输入值的响应，比如，对于“电压大于20V时，......”，应该增加“电压小于20V时，......”。
术语应明确定义。
2、可行性
能够在系统及其使用环境的已知能力和限制范围内实现。
技术上能不能做。
不需要以过高的成本或其他突出损失来实现。
3、可验证性
每一条需求都是可验证的。
不需要以太高的成本去验证。
需求应定义明确，比如，“经常会出现”、“性能良好”、“HMI美观”就不可验证。
理论上要成立，比如，“车机永远不能死机”是无法去验证的。
4、不含糊性
每条需求只有一种解释。
应有明确定义的术语表。
对于创建者和使用者都是明确的。
动词更胜于名词。
应有主语，比如，“每50ms发送一次信号”就语焉不详。
不要使用“和”、“或”、“如果”、“但是”这些承接词，比如，“在遇到故障时，控制器应记录DTC，并点亮仪表灯”应拆分为两条。
自然语言自带含糊性，需独立第三方评审。
5、一致性
需求内部没有冲突。
需求与上级文档一致。
使用的术语要统一。
6、正确性
需求描述是针对产品的。
与相关文档进行比对，比如，上级规范、base项目文档以及相关标准。
客户或用户视角下的评审。
基于追溯关系来检查。
工具或流程无法确保正确性。
7、可理解性
足够精简，内容有任何删减都会导致含义变化。
不需要以过高的成本去理解。
应增加适当的注释。
使用这些需求的角色都能理解。
充分使用图和表，比如，时序图、功能块图、真值表等。
8、可修改性
容易修改并还能保持原有的结构和风格。
具有连贯且易于阅读的结构，包括目录和引用。
不冗余，即同一需求在需求规范中仅出现一次。
需要出现多次时，可以使用引用的方式。
每条需求都是独立的，而不是与其他需求混在一起。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
