需求评审规范.docx
- 文档编号:9764395
- 上传时间:2023-02-06
- 格式:DOCX
- 页数:7
- 大小:17.92KB
需求评审规范.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:
需求评审流程图
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 需求 评审 规范
![提示](https://static.bdocx.com/images/bang_tan.gif)