第一部分：失败案例
案例一
某领域专家A先生就某企业的成本管理系统做用户需求报告的评审工作，在评审会开始时间不长，就被在场的企业的一位副总B先生打断，认为A先生提出的方案不适合本企业，A先生提出的管理改进方案在企业中无法实施。该副厂长提完意见后，与会的用户方人员纷纷跟随B先生的提出了他们的反对意见，致使评审会无法再进行下去，最终该报告被用户否决。
案例二
某软件公司内部举行产品的需求评审会，主要是公司内部的领域专家参加，在评审会开始后不久，某领域专家就对需求报告中的某个具体问题提出了自己的不同意见，于是，与会人员纷纷就该问题发表自己的意见，大家争执不下，结果，致使会议出现了混乱状况，主持人无法控制局面，会议大大超出了计划评审时间。
案例三
某软件公司为某公司A做业务流程管理系统的需求评审会，当项目组人员在会议上宣读多达上百页的需求报告时，用户明确提出听不懂，致使会议不得不改日进行。
案例四
某软件公司在用户处开完物资管理系统的需求评审会后，与会人员离开会议室时，纷纷摇头，认为本次会议没有多少实际效 果，完全是在走过场。
案例五
某软件公司在公司内部举行产品的需求评审会时，需求报告的执笔人与产品策划主要策划人员的想法差别很大，致使需求评审会没有必要继续进行下去。
第二部分：需求评审中常见的问题
◇ 需求报告很长，短时间内评审者根本就不能把需求报告读懂，想清楚；
◇ 没有作好前期准备工作，需求评审的效率很低；
◇ 需求评审的节奏无法控制；
◇ 找不到合格的评审员，与会的评审员无法提出深入的问题；
第三部分：如何做好需求评审
建议一：分层次评审
目标性需求：定义了整个系统需要达到的目标；
功能性需求：定义了整个系统必须完成的任务；
操作性需求：定义了完成每个任务的具体的人机交互；
目标性需求是企业的高层管理人员所关注的，
功能性需求是企业的中层管理人员所关注的，
操作性需求是企业的具体操作人员所关注的。
建议二：正式评审与非正式评审结合
建议三：分阶段评审
分阶段评审可以将原本需要进行的大规模评审拆分成各个小规模的评审，降低了需求返工的风险，提高了评审的质量。
建议四：精心挑选评审员
需求评审可能涉及的人员包括：需方的高层管理人员、中层管理人员、具体操作人员、IT主管、采购主管；供方的市场人员、需求分析人员、设计人员、测试人员、质量保证人员、实施人员、项目经理以及第三方的领域专家
首先要保证使不同类型的人员的都要参与进来，否则很可能会漏掉了很重要的需求。
其次在不同类型的人员中要选择那些真正和系统相关的，对系统有足够了解的人员参与进来
建议五：对评审员进行培训
对于主持评审的管理者也需要进行培训，以便于参与评审的人员能够紧紧围绕评审的目标来进行，能够控制评审活动的节奏，提高评审效率
建议六：充分利用需求评审检查单
需求形式的检查单和需求内容的检查单。需求形式的检查可以由QA人员负责，主要是针对需求文挡的格式是否符合质量标准来提出的，需求内容的检查是由评审员负责的，主要是检查需求内容是否达到了系统目标、是否有遗漏、是否有错误等等，这是需求评审的重点
建议七：建立标准的评审流程
建议八：做好评审后的跟踪工作
在需求评审后，需要根据评审人员提出的问题进行评价，要形成书面的需求变更的申请，进入需求变更的管理流程，并确保变更的执行，在变更完成后，要进行复审。
建议九：充分准备评审
评审质量的好坏很大程度上取决于在评审会议前的准备活动。常出现的问题是，需求文档在评审会议前并没有提前下发给参与评审会议的人员，没有留出更多更充分的时间让参与评审的人员阅读需求文档。
摩兜公司-IT赋能中心-需求评审标准
前提：主持者明确本次评审内容及评审的级别、参会者名单确立、文件无低级错误（文字、页面）
目标：会议中对下一阶段做的内容中功能性、操作性需求进行讨论
1：评审内容需要有清单（思维导图）
2：评审清单内要求对评审内容做文字性或流程图或思维导图或原型图的描述（建议用流程图、原型图）
3：评审前至少半个小时将评审内容分发给参会人员（将准备好的文件打包）
4：会议内容：介绍需求，头脑风暴对内容进行补充（做好记录），主持者进行引导，将所有的建议进行判定并作出决定（记录）。
5：会后整理文档，绘制成project、思维导图、禅道需求记录等进行管理，并整理会议纪要，通过邮件进行确认。
来源：https://www.cnblogs.com/zhaokunbokeyuan256/p/9663134.html