1、评审需求时，尝试去理解每个功能名称是给来干嘛的、怎么用，理清业务流。
2、了解应用程序的哪些方面对最终用户来说是，最关键以及哪些元素的风险最大。
——避免对不经常使用的部分过度测试，而对重要的部分又测试不充分。
3、每条需求必须阐述得准确、明确，反向思考是否存在遗漏、矛盾、含糊之处。
——分析每条需求时，应当站在整条需求的目的去思考，即需求的标题。
——描述是否正确？是否能准确地反映用户的需要？
——表述是否完整，没有遗漏？
4、需求=功能性需求+非功能性需求。
——非功能性需求包括：性能、安全性、可使用性、兼容性、可访问性
5、用户界面类的文档需注意是否遗漏了如下描述
（1）反映了隐藏的功能性行为没？
（2）反映这种隐藏行为与界面交互的方式/体现没？
6、可以从以下几个属性验证需求：
（1）正确性
（2）完整性
（3）一致性
（4）可测试性（可验证性）
——保证需求的可能性，测试结果是预先知道的，并能通过编程或者人工加以验证。
——确认没有遗漏重要的需求信息，无法实现或测试的需求。
（5）可行性——在当前资源条件下是否可实现
（6）必要性
（7）优先级——需求存在时的正面影响；砍掉需求时的负面影响
（8）明确性
（9）可追溯性
7、利用反向叙述，加入需求反讲环节、开发反讲环节、需求定时验收环节，确保需求、测试、开发3方理解一致。
