一、 注意对需求规格说明的正确性进行评审
需求规格说明的正确性通常可以从如下方面得以体现：
1、是否有需求与其他需求相互冲突或者重复？
2、是否清晰、简洁、无二义地表达了每个需求?
“清晰”是让人能够读懂；“简洁”是让人愿意去读；“无二义”决定”读”的效果,是让大家对需求描述的理解能够达成一致 。
3、是否每个需求都通过了演示、测试、评审，分析是否得到了验证?
4、是否每个需求都在项目的范围内?
5、是否每个需求都没有内容和语法上的错误?
6、在现有的资源内, 是否能实现所有的需求?
7、每一条特定的错误信息，是否都是唯一的和具有含义的?
二、 注意对需求规格说明的实践性进行评审
所谓实践性是指需求本身是否来源于目前企业的相关业务规则和文件制度,而非源于分析师们经验主义的臆测。实践性是判断需求规格说明是不是理论联系实践、密切和用户联系的一个关键性指标。
本文出自51Testing软件测试网，感谢会员archonwang在每周一问（08-11-10）中的精彩回答。
http://bbs.51testing.com/forum-157-1.html
三、 注意对需求规格说明的完整性进行评审
我们经常由下面的问题清单来评审需求说明书是否”完整” 。
1、编写的所有需求，其详细程度是否一致和合适?
2、需求是否能为设计提供足够的基础?
3、所有对其他需求的内部引用是否正确?
4、是否包含了每个需求的实现优先级?
5、是否定义了功能说明的内在算法?
6、是否包含了所有已知的客户需求或系统需求?
7、是否遗漏了必要的信息?如果有遗漏的话,把他们标记为待确定的问题(TBD) ?
8、是否对所有预期的错误条件所产生的系统行为都编制了文档?
需求说明的完整性主要体现在需求说明的详细程度上，我们怎样判断该需求的描述是否详细呢?我认为需求需要精化，而不是仅仅提出精化功能、对象要考虑涉众参与者、做些什么、需要什么数据信息、受什么业务规则和条件限制、系统会有什么响应，等等。
四、 注意对需求方案的可行性和成本预算进行评审
五、 注意对需求的质量属性进行评审
我们需要评审需求规格说明是否合理地确定了所有的性能目标，是否合理地确定了安全性方面要考虑到的问题。
本文出自51Testing软件测试网，感谢会员archonwang在每周一问（08-11-10）中的精彩回答。
http://bbs.51testing.com/forum-157-1.html
六、 注意对需求的可实施性进行评审
是否对每个需求都设置了惟一性并且可以正确地识别它？是否每个功能需求都可以跟踪到高层需求（比如系统需求或用例）?
需求必须可以测试,每个需求在特定的输入条件下应当能给出已知的输出结果。同时,需求应当层次分明,需要把单个需求下面的相关需求综合在一起形成一组需求功能。
需求的可实施性除了可跟踪性还包括可测试性。事实上, 分析人员和测试人员在编写代码以前把需求模型,分析模型和测试用例综合起来通盘考虑，检查出遗漏的、错误的和不必要的需求。软件需求在概念上的测试是一种很必要的技术，它可以在项目早期阶段发现需求的歧义和错误。
七、 注意对需求包含的用例文档进行评审
用例是参与者对系统和参与者的交互过程所达成的一种契约。需求说明书基于用例的分析方法是也是当前较为流行的需求开发方式。用例文档作为需求重要的成果性文档也是需求评审主体之所在。需求评审确认的重点是对关键用户的最常用和最重要的用例进行深入和细致的评审,首先要通过测试用例的主干过程。而我们是否撰写有效的用例则要从以下方面着手评审。
1、用例的目标或价值度量是否明确?
2、用例是否是独立的分散任务?
3、是否明确说明可用用例会给哪些参与者带来用处?
4、编写用例的详细程度是否恰当?是否有不必要的设计和实现细节?
5、所有预期的分支过程是否都编写了文档说明?
6、所有预估的异常过程是否都编写了文档说明?
7、是否存在一些普通的动作序列可以分解成独立的用例?
8、每个路径的步骤是否都清晰明了,无歧义而且完整?
9、用例中的每个参与者和步骤是否都与所执行的任务有关?
10、用例中定义的每个可选路径是否都可行和可验证?
11、用例的前置条件和后置条件是否合理?
分析师必须确认用例的前置条件和后置条件准确界定了用例的边界范围,区分了用例和用例之间的界限。
本文出自51Testing软件测试网，感谢会员archonwang在每周一问（08-11-10）中的精彩回答。
http://bbs.51testing.com/forum-157-1.html
八、 注意需求评审会的过程和结束标准
需求评审会的结果是对需求规格书完成了评审过程,那我们又如何判断审查的结束标准呢?请看如下几条建议:
1、审查期间评审员们提出的所有问题都已经解决。
2、相关文档中的所有更改都已经正确完成。
3、修订过的文档进行了拼写检查。
4、所有标识为TBD(待确定)的问题已经全部解决, 或者已经对每个TBD的问题的解决过程、计划解决的目标日期和责任解决人等编制了文档。
5 需求文档正式进入了配置库。
以上来自51testing
需求评审是我们项目立项之前的一条必经之路，是项目经理，开发，测试，架构师等等的同学针对自己将要开展的工作内容，进行检查并提出问题；只有评审通过的需求才能立项，但是我们的评审总带有一定的盲目性；
在公司里面，需求评审的时候，我们常可以看到这样的一个情况，一堆人，在一间会议室里面，吵得脸红脖子粗；大家都在强调：“你没有明白我的意思，我的意思是。。。”上午吵不完，下午继续吵，今天吵不完，明天再吵。。。最后，一个旁观的人突然说：“你们争论的根本不是同一个东西。”
在此同时，至少有五个与这个功能完全没有关系的人在看着别人脸红脖子粗。。。哀哉。我们需要改进现有的评审方式。
1、评审要有目的
在需求评审的时候，与会的同学关注的需求功能点都是分散的，我们很难将偏离用户需求的功能点找出。
我的意见是在评审之前，发出会议邀请的时候，分清必须参与评审的人员和选择参与评审的人员。必须参与评审的人员必须在需求评审之前发出自己认为需求中存在的问题；选择与会人员，可以自主选择是否发出评审意见；
一期的评审就以大家发出的问题为范围，由相关问题引申出来的问题，可以在相关人员查找资料之后，再进行二期评审；直到大家问题都解决完了为止。
2、评审要控制时限
我们也常见到这样一种情况，PM和PD两个人就一个问题争执不下，其余的同学都在下面看着两个人争执不下。可能还有这样一种情况，我说服不了你，但是我就默默唧唧的不答应，你也别想说服得了我。或者我们也在评审的时候发现：我们从A问题引申到B问题，再到C问题，直到大家一起偏离主题讨论N久，原定的计划还没有完成，还浪费大家的时间。
所以，对于每次评审中的提出的问题，PD或者PM设定一个讨论的最大时长，比如十五分钟。如果对一个问题讨论的时间太长，那么，在一定的程度上，这个功能点的实际存在着问题，考虑还不周全、不完善，有必要大家回去再思考。
3、及时作出评审的界定
在PD轮岗期间，在制定搜的需求评审期间，和项目的UED同学对项目的流程争执不下，连带着各自的一帮人都在争论不休；我们当时有叫来需求方，各自对需求方讲诉我们各自的出发点，结果需求方被我们讲得头晕脑胀，不知所言。
即使是辩论赛，我们也会有一个主持人进行中间调停。此时，我们当需要公推一个能拍板的人来，为此时做个不偏不倚的公断！
拍板的结果，双方必须当场无条件信服。如果争执的一方还认定自己的观点，本次会议中不可以再次提出，但是可以在搜集证据之后，再次召集有关人员讨论这个问题。
4、跟踪评审中问题的结果
在需求评审的时候，肯定还存在一些，例如调用存储访问等留待沟通之后再议的问题，但是评审之后是烟云缭绕，不知下文。如果没有一个发起人催一下问题解决的结果，甚至可能项目上线了，都没有让所有相关的人员知道问题是否得到解决，以及问题具体的解决方法。
在我们项目中的一些主要角色中，需求方太遥远，PD太忙太没有时间，开发太飘忽太随意，当然，我们的测试可能因为影响力等原因，太没有力度。要建立自己的威信和对项目的责任感，我们需要从跟踪评审问题的结果开始，让大家都看到你对项目的关注程度，你对项目的责任感。
5、设定需求变更联系人
在淘宝，拥抱变化的思想深入人心；我遇到过这样一件事情，后台CRM需要跟流程平台打通，调用流程平台的审批系统；我们当时跟流程平台的同学一起讨论可行性，讨论接口的内容等。突然，有一天我询问项目进度的时候，开发同学说，我们决定不用流程平台的审批系统了。
我们也常听到测试的同学怒吼一声，你们需求又变了，我为什么不知道。这些是什么原因导致的呢？
一直以来，大家都很随意，没有一种明确的需求变更的机制；如果需求变化了，应该告诉谁，对谁可能有影响，这些我们都没有想；我们只想到，我们实现这个功能更加简单了。这种片面性的想法导致了以上的种种问题。
故而，上到一个项目，下到一个小日常，我们需要确定项目需求变更的通知人。一旦遇到变更情况，需要马上通知到相关的变更联系人。
6、评审的结果——基线
基线是项目储存库中每个工件版本在特定时期的一个“快照”。它提供一个正式标准，随后的工作基于此标准，并且只有经过授权后才能变更这个标准。建立一个初始基线后，以后每次对其进行的变更都将记录为一个差值，直到建成下一个基线。
而我们现在评审完毕之后，顶多发出一个会议的纪要出来，上面写明，今天的评审中提出了哪些问题，哪些问题是需要进一步跟踪的会议纪要，再也没用进一步的东东。所以，这个不是基线，至少不是完整的基线，不是正式的基线。
我觉得，基线还应该包含以下几个方面的内容：
1） 需求变更的联系人
2） 公开评审中问题的结果
3） 修改后，大家达成共识的PRD。现在我们评审的结果只有输入值，一个初始版本的PRD,但是没有基线版本的PRD。
评审是我们项目和日常的第一步，熟话说，好的开始是成功的一半。一个良好的，有序的评审方法，有利于我们发现更多的问题。
http://blog.sina.com.cn/s/blog_4b6578120100yz22.html