通过评审规格说明书来测试需求

        正确性：对照原始需求检查SRS 
        必要性：不能回溯到出处的需求项可能是多余的 
        优先级：恰当划分并标识 
        明确性：不使用含糊的词汇 
        可测性：每项需求都必须是可验证的 
        完整性：不能遗漏必要和必需的信息 
        一致性：与原始需求一致、内部前后一致 
        可修改性：良好的组织结构使需求易于修改 
        注意，其实现在很多公司做的所谓需求规格说明书评审并不是真正的需求评审，他们更多的是关注有没有需求，需求打算如何实现，而没有把精力放在评价上面的几个“性”上。

　SRS测试步骤

        第一步：获取最新版本的SRS，同时尽量取得用户原始需求文档 
        第二步：阅读和尝试理解SRS描述的所有需求项 
        第三步：对照SRS Review Checklist进行检查并记录 
        第四步：针对检查结果进行讨论、修订SRS后回到第一步，直到Checklist的所有项通过

        软件需求规格说明书评审检查单模板

        其他测试需求的方法

        通过用户调查来测试需求 
        通过设计测试用例来测试需求 
        利用现存的产品对需求进行测试
        通过用户调查来测试需求

        保证用户会对最终的设计感到满意的最简单和最可靠的方法就是开始设计时测量他们的满意度 
        周期性地调查、关注变化 
        对于任何评论都要给予关注，尤其是他们表达了强烈的愿望时
        注意，其实很多时候调查用户是不现实的，或者调查的机会不多，这时候应该邀请业务专家、领域专家、业务市场人员对需求进行评审和检查。

        通过设计测试用例来测试需求

        构建并回答黑盒测试主要是为了测试需求的完备性、准确性、明确性以及简明性 
        通过想象产品已经制造出来，构建一系列的测试用例，并且问“假设”问题 
        回答这些用例并且与设计人员讨论答案 
        试图认同答案通常会导致其他“假设”问题，引发的“假设”问题都必须得到很好的回答
        实践证明，这种方法是非常有效的，但是前提是测试人员需要投入足够的精力和时间进行测试用例的编写，并且不能被动地接受和相信需求规格说明书，要对其抱着怀疑的态度。

        利用现存的产品对需求进行测试

        比较产品，提出一份在新需求中可能遗漏的功能列表 
        访谈一些旧产品的使用者，提出一份在当前系统中不需要的功能列表 
        比较旧产品和其原始的需求，准备一份新产品开发中的潜在问题的列表。尤其要注意那些没有被实现的或是实现了之后又被丢弃的需求 
        避免因为每个旧产品而把产品做成一把瑞士军刀的诱惑。不要让那些不属于整个需求过程的特征悄悄混进来。