问题描述：我们公司快要成立测试部了，之前我们一直是研发部下的测试小组，在成立之前，我们测试组集体讨论了下测试组成立前后的一些问题。其中一个难题就是需求，我们几个都没有相关的经验，所以我在此求助大家，邀大家来讨论下：如何进行需求评审？怎样的需求评审机制才是有效的？
精彩回答：
关于需求评审，首先我觉得应该解决的是可用的评审可用资源问题，只有把这个问题解决了，其评审结果才可以采信，否则不过形式尔耳。
关于需求评审的一些必备资源，我这里选列了相关角色，如下列：
* 业务专家或是熟悉该业务的人员（通常也叫业务方代表）
* 文档审查人员
* 架构师
* 需求分析师
* 需求评审组织人员及记录人员
当然，除了人员意外，必要的时间、场地和上层决策者的支持也是不可或缺的。
这些资源一旦准备停当，接下来就是如何安排评审事宜的问题了。我这里简单列下以往曾做过的一轮需求评审的过程：
* 准备阶段（P）
o 争取上层决策者的支持与谅解
o 筹备相关的资源，包括人力、时间计划，评审场地
o 在正式评审之前，将相关的需求记录（文档或其他形式）发布给每个参与评审的人员手中，并确保其有足够的时间可以通阅需求并做好评审前的相关质疑与确认记录
o 在正式评审之前，会议组织者应先收集相关评审人员的各项需求评审建议和意见，对存在争议和疑惑的需求说明必须做好讨论的安排
o 发布经确认后的评审计划或时间表
* 实施阶段（D）
o 由评审组织者召集各评审人员集中评议，可以以正式的会议等形式组织，此处以会议为形式做说明
o 与会人就某具体的问题进行讨论，讨论的优先级如下所列
* 最重要的业务内容，一般是按流程、功能、细节来排定
* 争议或疑问较多的地方
* 部分有争议的地方
* 对于没有提出疑义的地方，可以快速流过
o 最后，要注意一定要回顾已提出问题和有结论的地方
o 由会议记录人员整理会议的纲要，记录各与会人员的相关意见，并在会后递交纪要
* 检查再实施阶段（C）
o 对评审得出结论的问题进行再次确认和修正补充
o 确定下次评审的时间
o 按照第一阶段的流程再次进行组织，并确认结果
o 对大多数组织，两次评审可以解决大部分的问题，对于悬而未决的问题，如影响范围有限，则可以延后讨论解决
* 总结阶段（A）
o 就以上内容做最后的确认，需求定稿，各方签字确认。
o 今后的变更转入需求变更流程，其后产生的评审为小范围内评审。
4#给出了一项检查清单，作为文档审查人员审查需求的参考检查表使用，大家可以在进行需求评审时参考使用。
建议一：分层次评审
我们知道用户的需求是可以分层次的，一般而言可以分成如下的层次：
* 目标性需求：定义了整个系统需要达到的目标；
* 功能性需求：定义了整个系统必须完成的任务；
* 操作性需求：定义了完成每个任务的具体的人机交互；
目标性需求是企业的高层管理人员所关注的，功能性需求是企业的中层管理人员所关注的，
操作性需求是企业的具体操作人员所关注的。对不同层次的需求，其描述形式是有区别的，参与评审的人员也是不同的。如果让具体的操作人员去评审目标性需求，可能会很容易地导致“捡了芝麻，丢了西瓜”的现象，如果让高层的管理人员也去评审那些操作性需求，无疑是一种资源的浪费或者就会出现案例三的情形。
建议二：正式评审与非正式评审结合
正式评审是指通过开评审会的形式，组织多个专家，将需求涉及到的人员集合在一起，并定义好参与评审人员的角色和职责，对需求进行正规的会议评审。而非正式的评审并没有这种严格的组织形式，一般也不需要将人员集合在一起评审，而是通过电子邮件