需求评审规范.docx

需求评审规范.docx

《需求评审规范.docx》由会员分享，可在线阅读，更多相关《需求评审规范.docx（7页珍藏版）》请在冰点文库上搜索。

需求评审规范

需求评审规范

文件状态：

[]草稿

[√]正式发布

[]正在修改

产品标识：

文件标识：

需求评审规范

当前版本：

V1.0

作者：

陈洁

完成日期：

2016-12-02

变更记录

序号

完成日期

修改内容

作者

审查

1

2016-10-28

初稿完成

陈洁

2

2016-11-07

细化内容，添加了内部评审

粟涛

3

2016-11-08

添加需求声明，增加附件

陈洁

4

2016-12-02

根据反馈进行优化修改

粟涛

一、概要

1、规范化需求评审的目的

1.1、提升需求质量，保障产品质量；

1.2、提高评审会议效率和质量；

2、明确需求评审目的

2.1、让技术及测试对产品方案有详细的了解，以便后续开发更高效；

2.2、让与会者清晰的知道自己在整个发开过程中处于什么位置，职责是什么，需要做什么，准备什么，提供什么帮助，对各自负责部分的实现难度及排期有一定的心理预期；

2.3、需求评审只对本次需求进行讨论，不深入，不发散。

3、明确需求评审的与会人员

3.1、提前核实和通知本次需求参与的相关人员

4、每周需求评审次数

4.1、提前询问测试本周是否有时间进行需求评审，不要因为需求评审而导致测试计划打乱。

4.2、原则上需求评审每周最多2次。

二、评审准备

1、人员职责

产品：

a）准备《产品需求文档》《产品原型文件》《美术需求文档》《美术效果图》。

b）编写《产品需求文档》《产品原型文件》时提前和相关的程序负责人进行沟通，将一些不确定的方案给确定下来，探讨方案实现的难易程度，确保某些需求的可行性，还可以发现可能与原有产品逻辑相冲突的地方等，提前将这些工作做好，确保需求评审会议的高效。

c）涉及运营的需要和运营提前进行沟通，确定运营需求细节并明确是否需要运营平台支持。

d）《美术需求文档》要和美术详细描述需求，明确功能。

在需求评审前制作出效果图。

f）至少提前一天将资料以邮件形式发出并通知与会人员，让与会者提前查看。

g）会议的发起至少提前半天进行通知，最好是和资料一并提前1天发送，好做好提前的协调，保证都能准时参会。

开发：

a）提前熟悉资料，查看需求是否易于理解，细节有没有说清楚，逻辑是否成立。

b）对技术可行性进行分析，能不能做，成本多大规模，有多大风险。

c）提前给产品提出开发的问题反馈，产品可以提前补充完善，保证会议的高效。

测试：

a）提前熟悉资料，查看需求是否易于理解，细节有没有说清楚，逻辑是否成立。

b）对后期的用例编写和是否需要设计评审做到心中有谱。

c）提前给产品提出问题反馈，产品可以提前补充完善，保证会议的高效。

2、材料

2.1、产品需求文档

产品需求文档要把需求的逻辑表达清楚没有歧义，对各个细节描述清晰。

各输入输出项、业务流程、计算规则、判断逻辑 、以及特殊情况都要写清楚。

可以整理一份适合自己的需求文档自查清单，每次写完后从头到尾对照一遍。

2.2、产品原型文件

产品原型文件尽量做到最高的保真度，每一个点击事件，业务流程最好都可以直接呈现出，以便开发理解。

产品原文件的元件管理要合理，要易于查询和修改。

2.3、美术图

美术效果图需要在需求评审前出图，效果图要保证为定稿，不会再做修改。

3、内部评审

产品内部评审就是在产品团队内部进行小范围评审，确保需求逻辑的一致性。

规避大部分需求不合理的地方，可以直接有效的提升需求评审的效率。

也可以在产品内部进行复查，看是否有涉及多个产品的需求点，需要协调配合的。

4、准评审条件

a）需求带有完整的效果图；

b）与会人员对于需求内容没有异议；

c）材料至少提前1天发出，复杂需求的评审需要至少提前2天发出；

d）会议至少提前1天发起；

e）所有需求提前沟通，已确认可实现；

f）主要成员前期准备妥当，无缺席；

三、会议流程

1、评审中

1.1、讲解内容：

a）明确本次需求评审会的背景及目标；

b）从功能点开始，告诉大家我们这个需求要为用户提供什么，这个需求是怎么来的，这个需求有什么价值。

然后讲原型，结合需求文档每个功能点逐一讲解。

1.2、讨论/提问规范：

a）仅需求范围，可涉及基本技术方案，但不涉及具体技术实现；

b）需求细节问题不展开；

c）如果讨论了5分钟以上仍然没有结论，产品就记下这个问题，先进行后面的内容，最后再掉回头来讨论之前有争议的问题。

如还不能解决则记下来，会后协调。

1.3、是否需要概设评审：

a）如果有，则要确认版本概设时间

b）如没有，则要确认版本提测时间

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：

需求评审流程图