需求评审规范

2、准出标准

1、需求合理，无异议； 2、无逻辑错误；

3、可遗留待确认需求细节问题，不影响整个需求正常流程； 4、技术可行性分析后是可行的；

3、评审后

1、会议纪要

会后及时整理输出会议纪要，罗列清楚问题或者争议点，已经形成结论的地方就不再赘述，待确定的问题继续找相关负责人进行讨论，直到得出最后的结论。

2、产品需求文档更新

将所有修改和变更的需求点在产品需求文档上写清楚，并同步到SVN。SVN要保证是最新的需求文档。

3、发送会议纪要

将整理好的会议纪要和《产品需求文档》通过邮件的方式发送给所有相关人员。

四、需求变更

1、准更时间

a) 逻辑类问题：提测前允许变更，提测后不允许变更； b) 细节类问题：提测前后均可变更；

2、需求变更来源

需求变更是谁提出的以及需求变更的原因是什么。如内部人员发现了逻辑，需求上的问题，或功能上的建议以及开发、测试人员提出的需求和用户体验不符合等。

3、需求变更类型

需求有误、需求遗漏、需求不明确、需求建议；

4、需求变更审核

需求变更需要产品、开发、测试一起进行审核，共同确认是否进行需求变更。审核包括对需求变更的影响程度，难易度，必要性，对开发周期的影响进行综合评估。

5、需求变更同步

需求变更后需要及时同步到redmine相关帖子中，并在《产品需求文档》中修改，记录下本次变更的内容。变更以redmine为准。

6、变更申明

需求变更后，需要以邮件形式向相关人员说明需求变更来源，类型，审核结果以及变更前后的内容。附上最新的产品需求文档地址和redmine地址

7、特殊说明

需求涉及到逻辑，不变更则完全影响版本质量及发布的，经项目组所有人员知晓并同意，允许变更，不受准更时间显示，但必须出具：需求重大变更说明书（需含变更原因、变更结果、责任划分、影响范围、总结），同时对相关文件以及版本计划进行修改并同步给所有成员。

五、声明

以上所有需求提出、变更，有redmine即同步redmine，没有的邮件发送至项目组成员，但最终都应该：以需求文档为标准；

附件1：需求评审流程图