正确性：

用户评审用于确保SRS中规定的要求的正确性。如果SRS涵盖了系统实际预期的所有要求，则称SRS是正确的。

完整性：

SRS的完整性表示每种完成感，包括所有页面的编号，尽可能多地解析待确定的部分以及适当地覆盖所有功能和非功能要求。

一致性：

如果任何一组要求之间没有冲突，则称SRS中的要求是一致的。冲突的例子包括在不同地方使用的术语的差异，逻辑冲突，如报告生成的时间段等。

明确性：

如果所述的所有要求仅有1个解释，则称SRS是明确的。防止明确性的一些方法包括使用ER图表，适当的评论和伙伴检查等建模技术。

重要性和稳定性的排名：

应该有一个标准将需求分类为更少或更重要，或更具体地将其分类为理想或必要。标识符标记可以与每个要求一起使用以指示其等级或稳定性。

可修改性：

SRS应尽可能地修改，并且应该能够在一定程度上容易地接受对系统的更改。修改应正确编入索引并交叉引用。

可验证性：

如果存在特定技术来量化地衡量系统满足每个要求的程度，则SRS是可验证的。例如，声明系统必须是用户友好的要求是不可验证的，应该避免列出这些要求。

可追溯性：

应该能够跟踪设计组件的需求，然后跟踪程序中的代码段。同样，应该能够跟踪对相应测试用例的要求。

设计独立性：

应该有一个选项可以从最终系统的多种设计方案中进行选择。更具体地说，SRS不应包括任何实现细节。

可测试性：

SRS应该以这样的方式编写，即从文档中生成测试用例和测试计划很容易。

客户可以理解：

最终用户可能是他/她特定领域的专家，但可能不是计算机科学专家。因此，应尽可能避免使用正式符号和符号。语言应该保持简单明了。

正确的抽象级别：

如果SRS是针对需求阶段编写的，则应明确说明详细信息。然而，对于可行性研究，可以使用更少的细节。因此，抽象级别根据SRS的目的而变化。