正确性

　　 是否有需求与其它需求相冲突或重复?

　　 是否简明、简洁、无二义性地表达每个需求的?

　　 是否每个需求都能通过测试、演示、审查得以验证或分析?

　　 是否任一个特定的错误信息都具有唯一性和明确的意义?

　　质量属性

　　 是否合理地确定了性能目标?

　　 是否合理地确定了安全与保密方面的考虑?

　　 在确定了合理的折衷情况下，是否详实地记录了其它相关的质量属性?

　　可跟踪性

　　 是否每个需求都具有唯一性并且可以正确地识别它?

　　 是否可以根据高层需求(如系统需求或使用实例)跟踪到软件功能需求?

　　特殊的问题

　　 是否所有的需求都是名副其实的需求而不是设计或实现方案?

　　 是否确定了对时间要求很高的功能并且定义了它们的时间标准?

　　5、进入和退出审查的标准

　　当软件需求文档满足特定的前提条件时，你就可以进行需求审查了。这些标准还可以使审查小组避免把时间浪费在审查之前就应该解决的问题上。调解者在决定进行审查之前，可以把进入审查的标准作为一种清单，并以此作为判断的标准。

　　 文档符合标准模板，并且已经做过拼写检查和语法检查。

　　 在文档中打印了行序号以方便在审查中对特定位置的查阅。

　　 所有未解决的问题都被标记为(待确定)。

　　 包括了文档中使用到的术语词汇表。

　　相似地，在调解者宣布审查结束之前，你应该定义所满足的退出审查的标准。

　　 已经明确阐述了审查员提出的所有问题。

　　 已经正确修改了文档。

　　 修订过的文档已经进行了拼写检查和语法检查。

　　 所有(待确定)的问题已经全部解决，或者已经记录下每个待确定问题的解决过程，目标日期和提出问题的人。

　　 文档已经登记入项目的配置管理系统。

　　6、总结

　　基本上能做到以上说的几点，需求就应该很明确了。接下来的流程也会走的很顺了!