综合了很多公司的朋友的意见，他们的需求评审的内容一般为下：

　　1、需求的评审是在测试活动开始前进行的，首先是需求规格的描述是否是客户想要的

　　2、对需求内容的检查，也就是说需求的写作规格是否遵守需求6要素（正确性、无异议性、完整性、一致性、可验证性、可追踪性）

　　3、概念定义（所谓的字典：描述着合法或不合法的定义）

　　总知就是你写的SRS让别人检查呗，具体如何检查检查些什么内容，个人认为也是以上那些吧！

　　写在这里希望大家能提出不同的意见或建议，一起进步

　　以下是如何评审需求：

　　1.软件需求是软件开发最重要的一个输入，好的开始是成功的一半！所以，需求的质量很大程度上决定了项目质量或产品质量。

　　2.需求风险常常是软件开发过程中最大的一个风险，要降低需求阶段带来的风险，就要把需求评审做好。

　　3.需求评审做不好的后果：

　　· 需求变更

　　· 需求不明确

　　· 需求不可测

　　· 需求不可实现

　　导致后续工作难于开展或经常出现变更。

　　4、产品经理：不识庐山真面目，只缘身在此山中，需求是自己写的，容易受到固定思维的限制，所以，需要一双没有看过这个需求的眼睛来检查一下，有什么问题。

　　先大概说一下需求的不同类型：

　　需求的不同层次：

　　目标性需求：定义了整个系统需要达到的目标；

　　-高层关注

　　功能性需求：定义了整个系统必须完成的任务；

　　-中层关注

　　操作性需求：定义了完成每个任务的具体的人机交互；

　　-执行人员关注

　　在做需求评审的时候，应该根据不同的需求层次，进行不同的评审。

　　因为经常参加需求评审会议，所以对需求评审中常见的问题有所了解，现在举一些例子：

　　1、某产品经理在主持需求评审会，评审开始时间不长，就被一位主管打断，明确指出此方案与企业业务发展方向不符，不能实施。紧接着其他与会人员纷纷发言表示同意，结果评审会无法继续进行，需求最终被否决。

　　问题所在：

　　缺乏初步沟通，目标性需求尚未明确，功能性需求和操作性需求无从谈起。

　　2、某次需求评审会，主要是公司内部相关领域的专家参加，在评审会开始后不久，某专家就对需求中的某个具体问题提出了自己的不同意见，于是，与会人员纷纷就该问题发表自己的意见，大家争执不下，结果，致使会议出现了混乱状况，主持人无法控制局面，会议大大超出了计划评审时间。

　　问题所在：

　　前期沟通和准备不够，缺乏应对不同意见的准备，难以化解争执。

　　主持者不能有效把握会议目标，会议讨论过于关注细节，导致评审失控。

　　3、某产品经理主持需求评审会，在讲解需求说明书时，与会人员似懂非懂，没有提出任何有价值的问题，致使会议没有得到预期效果，不得不改日重新进行。

　　问题所在：

　　前期准备和沟通不够，评审变成了培训。

　　没有选择合适的评审人员，无法获得有价值的信息。

　　4、某需求评审会，与会人员各抒己见，气氛热烈，产品经理忙于收集意见，结果散会时发现对需求有价值的并不多，并且遗漏了许多要评审的问题，评审效果不佳。与会人员在离开会议室后，私下也认为评审没有多少实际效果，完全是在走过场。

　　问题所在：

　　评审缺乏有效依据和规范，不能保证评审的覆盖率和有效性。

　　产品经理没有把握好会议主题，评审变成了头脑风暴。

　　需求评审常见问题汇总

　　目标性需求没有沟通好，后面的需求变成空中楼阁。

　　缺乏评审的可操作依据，遗漏评审内容。

　　没有作好前期准备工作，导致评审时间长，效率低。

　　没有选择合适的评审人员，无法获得有价值的反馈。

　　参加人员过多，容易陷入细枝末节的讨论，会议演变成一场人人自由的混战。