一、评审机制
1、规范化需求评审的目的
提升需求质量、保障产品质量、提高评审会议效率，评审不通过的回炉更新。
2、明确需求评审目的
让技术及测试对产品方案有详细的了解，以便后续开发更高效；
让与会者清晰自己在整个发开过程中处于什么位置，职责是什么，需要做什么，准备什么，提供什么帮助
对各自负责部分的实现难度及排期有一定的心理预期；需求评审只对本次需求进行讨论，不深入，不发散。
3 、明确需求评审的与会人员
提前核实和通知本次需求参与的相关人员、包括项目总监，产品经理，项目经理，技术经理，测试经理
4、每周需求评审次数
原则上需求评审每周最多3次，以免浪费时间。
二、评审准备
1、人员职责
（1）项目经理
准备《需求文档》
（2）产品经理
准备《原型文件》，《美术效果图》
编写《原型文件》时提前和相关的项目经理、技术经理进行沟通，将一些不确定的方案给确定下来，
探讨方案实现的难易程度，确保某些需求的可行性，还可以发现可能与原有产品逻辑相冲突的地方等，
提前将这些工作做好，确保需求评审会议的高效。
至少提前一天将资料在项目群里发出并通知与会人员，让与会者提前查看。
会议的发起至少提前半天进行通知，最好是和资料一并提前1天发送，做好提前协调，保证都能准时参会。
（3）技术经理
提前熟悉资料，查看需求是否易于理解，细节有没有说清楚，逻辑是否成立。
对技术可行性进行分析，能不能做，成本多大规模，有多大风险。
提前给产品提出开发的问题反馈，产品可以提前补充完善，保证会议的高效。
（4）测试经理
提前熟悉资料，查看需求是否易于理解，细节有没有说清楚，逻辑是否成立。
对后期的用例编写和是否需要设计评审做到心中有谱。
提前给产品提出问题反馈，产品可以提前补充完善，保证会议的高效。
2、材料
（1）需求文档
产品需求文档要把需求的逻辑表达清楚没有歧义，对各个细节描述清晰。
各输入输出项、业务流程、计算规则、判断逻辑 、以及特殊情况都要写清楚。
可以整理一份适合自己的需求文档自查清单，每次写完后从头到尾对照一遍。
（2）原型文件
产品原型文件尽量做到最高的保真度，每一个点击事件，业务流程最好都可以直接呈现出，以便开发理解。
产品原文件的元件管理要合理，要易于查询和修改。
（3）美术效果图
美术效果图需要在需求评审前出图，效果图要保证为定稿，不会再做修改。
3、内部评审
产品内部评审就是在产品团队内部进行小范围评审，确保需求逻辑的一致性。规避大部分需求不合理的地方
可以直接有效的提升需求评审的效率。也可以在产品内部进行复查，看是否有涉及多个产品的需求点，需要协调配合的。
4、准评审条件
（1）需求带有完整的效果图
（2）与会人员对于需求内容没有异
（3）材料至少提前1天发出，复杂需求的评审需要至少提前2天发
（4）会议至少提前1天发
（5）所有需求提前沟通，已确认可实现
（6）主要成员前期准备妥当，无缺席
三、会议流程
1、评审中
（1）讲解内容
明确本次需求评审会的背景及目标；
从功能点开始，告诉大家我们这个需求要为用户提供什么，这个需求是怎么来的，这个需求有什么价值。
然后讲原型，结合需求文档每个功能点逐一讲解。
（2）讨论/提问规范
仅需求范围，可涉及基本技术方案，但不涉及具体技术实现；
需求细节问题不展开；
如果讨论了5分钟以上仍然没有结论，产品就记下这个问题，先进行后面的内容，最后再掉回头来讨论之前有争议的问题。
如还不能解决则记下来，会后协调。
2、准出标准
（1）需求合理，无异议
（2）无逻辑错误
（3）可遗留待确认需求细节问题，不影响整个需求正常流程
（4）技术可行性分析后是可行的
3、评审后
（1）会议纪要
会后及时整理输出会议纪要，罗列清楚问题或者争议点，
已经形成结论的地方就不再赘述，待确定的问题继续找相关负责人进行讨论，直到得出最后的结论。
（2）需求文档更新
将所有修改和变更的需求点在产品需求文档上写清楚，同步到协作中心。
（3）公布会议纪要
将整理好的会议纪要和《需求文档》发送给项目总监，同步到协作中心。
四、需求变更
需求变更既消耗我们团队的时间，还消耗我们的士气，需慎重处理，严格评审，避免拍脑袋决策。
1、准更时间
（1）逻辑类问题：提测前允许变更，提测后不允许变更；
（2）细节类问题：提测前后均可变更；
2、需求变更来源
需求变更是谁提出的以及需求变更的原因是什么。
如内部人员发现了逻辑，需求上的问题，或功能上的建议以及开发、测试人员提出的需求和用户体验不符合等。
3、需求变更类型
需求有误、需求遗漏、需求不明确、需求建议；
4、需求变更审核
需求变更需要产品、开发、测试一起进行审核，共同确认是否进行需求变更。
审核包括对需求变更的影响程度，难易度，必要性，对开发周期的影响进行综合评估。
5、需求变更同步
需求变更后需要及时同步到协作中心，并在《需求文档》中修改，记录下本次变更的内容。
6、变更申明
需求变更后，需要将变更来源，类型，变更审核等内容，公布到协作中心。
7、特殊说明
需求涉及到逻辑，不变更则完全影响版本质量及发布的，经项目组所有人员知晓并同意，允许变更，不受准更时间限制，
但必须出具：需求重大变更说明书（需含变更原因、变更结果、责任划分、影响范围、总结），并同步到协作中心。
五、声明
以上所有需求提出、变更，都会形成文档，并附加到对应的项目档案，随时可以复查。