软件需求是保证最终软件质量最为关键的一环，也是软件测试的基础。高质量的软件需求，为产品的最终质量打下了坚实的基础。那么高质量的需求具备哪些关键因素呢？
可理解
需求必须是可以理解的，可理解的需求组织方式便于阅读、评审。下面是一些提高可理解性的方法：
1）根据对象（如用户、订单和发票）来组织需求。
2）用户需求应该按业务过程或者场景来进行组织，这样，行业专家就能快速判断是否有遗漏的需求。
3）将功能需求和非功能需求分开，例如，将功能需求和性能需求分开说明。
4）根据详细程度来组织需求。由需求对系统的影响来决定，例如“系统应该能够接收订单”与“系统应该能够接收销售点的零售订单”对系统就有不同的影响。
5）编写出来的需求应该符合语法规则，样式应该便于阅读、评审。如果需求是用word文档编写的，就应该启用拼写检查选项，同时注意上下文，因为word并不检查下文是否合适。
6）需求应该是明确的，在需求中应恰当的使用“应该”一词，而不要使用“将会”或者“应该会”，因为后面两个词讲的是目标，而不是需求。如果使用非命令式的词语，这样表明需求是可选的，可能会导致需求被误解，可能增加项目成本，也可能使时间周期增加，降低质量，或者出现合同纠纷。
必需性
需求应该是必需的。举个非必须需求的例子。假设下面这个需求已包含在需求规格说明书中：“如果有100个测试用例通过，那么系统应该是可接受的。”这实际是一个项目过程，而不是需求，不应该记录在需求规格说明里。需求必须与正在构建的目标应用或系统相关。
可修改
需求及相关信息必须是可以修改的。选用存储需求的技术影响着需求的可修改性，例如，字处理器中的需求比需求管理工具（如CaliberRM）中的更难修改。但是，针对非常小的项目，因为需求管理工具成本与学习曲线的关系，字处理器就成了最佳选择。
一致性也对可修改性有影响。需求的编写模板结构应该使需求很好呈现，从而方便修改。最佳实践应把每个需求用唯一标识符进行标记。任何需求的依赖关系都应该有标注，例如，需求X应该依赖于需求Y。
非冗余
不应该出现重复的需求，否则会引发问题。重复需求会加重维护工作，例如，每次修改某个需求时，也要修改与之重复的那个需求。重复需求还会提高出现注入需求错误的可能性。
简洁
一个好的需求必须杜绝出现冗词赘句或者多余信息。一个简洁的需求表达应该一语中的，诸如“另一方面”、“然而”、“回想起来”这类词眼应该杜绝。
可测试
可测需求必须可以被验证确认，也可以说，需求的意图应该是能够证明的。不可测试的需求适合测试人员要做客观解释的时候。最好就是带着问题：我是否可以测试这个需求，了解它能否行得通？
可跟踪
需求必须是可跟踪的，这是验证是否满足需求的关键。复合需求很难跟踪，可能导致产品测试失败。例如“系统应该计算出退休金和遗属抚恤金”就是一个复合需求。通过列表方法可以避免在评审各个需求的跟踪能力时造成误解。
在范围内
所有需求必须在指定范围内定义。项目的范围是根据为项目建立的所有需求而定的。项目范围按照对需求的标识、分析和基准线来定义和细化。“跟踪能力矩阵”有助于保证需求位于指定范围内。