从理论上讲，上图中“需求”（S圆表示）、“可运行系统” （P圆表示）和“测试用例” （T圆表示）应该是重合，但实际上这三个圆很难重合。
从 上图可以看出：可能会有没有测试到的已描述行为（区域2和区域5）；经过测试的已描述行为（区域1和区域4）；对应未描述行为的测试用例（区域3和区域 7）；可能会没有测试的程序行为（区域2和区域6）；经过测试的程序行为（区域1和区域3）；对应于未通过程序实现的行为（区域4和区域7）。
由于我们今天讨论的主题是“测试人员为什么需要参加需求评审”，因此我们重点来看看与这一问题关系密切的区域2和区域5、区域3和区域7。
区域2和区域5这两部分是测试用例没有覆盖到的需求，即“没有正确的测试用例与该部分需求对应”。出现这种情况本人认为有三种可能：
1、 设计测试用例的测试人员对需求理解不完整，出现了应该被测试的需求而没有被测试用例覆盖到的现象；
2、 《用户需求说明书》中区域2和区域5对应的需求，具有不可测试性，测试人员无法设计用例；
3、 《用户需求说明书》中区域2和区域5对应的需求，不是用户的需求，是需求分析人员凭空增加的，测试人员无须设计与这部分需求对应的测试用例。
区域3和区域7这两部分是需求没有覆盖到的测试用例，即“没有正确的需求与该部分测试用例相对应”。出现这种情况本人认为有两种可能：
1、设计测试用例的测试人员对需求理解不充分，从而设计出了多余的测试用例；
2、《测试用例》中区域3和区域7的测试用例所对应的需求，是用户的真实需求，只是《用户需求说明书》中没有描述到而已。
从上面的分析可以看出，如果测试人员参加了“需求评审”，则上面出现的问题可以最大程度地避免，因为测试人员参加“需求评审”的重要作用正是针对产生这些问题的因素而进行的。
由此总结出，测试人员参加“需求评审”活动所需要达到的目标包括如下三个方面：
1、充分地理解需求，确保对需求的理解与需求分析人员是一致的；
2、从可测试的角度，努力发现《用户需求说明书》中不可测试的需求，从而提醒需求分析人员尽早修改；
3、从测试人员的角度努力发现《用户需求说明书》中的不完整性，从而提醒需求分析人员及时补充遗漏掉的这部分用户需求。
主要参考文献
[1] 《软件测试》 机械工业出版社
[2] 《软件测试经验与教训》（美）Cem Kaner,James Bach,Bret Pettichord著，韩柯 等译
[3]《编写有效用例》（美）Alistair Cockburn著，王雷、张莉译 机械工业出版社