需求评审规范.docx

集团文件版本号：（M928-T898-M248-WU2669-I2896-DQ586-M1988） 集团文件版本号：（M928-T898-M248-WU2669-I2896-DQ586-M1988） 需求评审规范 需求评审规范 文件状态： [ ] 草稿 [ √ ] 正式发布 [ ] 正在修改 产品标识： 文件标识： 需求评审规范 当前版本： V1.0 作 者： 陈洁 完成日期： 2016-12-02 变更记录 序号 完成日期 修改内容 作者 审查 1 2016-10-28 初稿完成 陈洁 2 2016-11-07 细化内容，添加了内部评审 粟涛 3 2016-11-08 添加需求声明，增加附件 陈洁 4 2016-12-02 根据反馈进行优化修改 粟涛 目录 TOC \o 1-3 \h \z \u 一、概要 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天发送，好做好提前的协调，保证都能准时参会。 开发： 提前熟悉资料，查看需求是否易于理解，细节有没有说清楚，逻辑是否成立。 对技术可行性进行分析，能不能做，成本多大规模，有多大风险。 提前给产品提出开发的问题反馈，产品可以提前补充完善，保证会议的高效。 测试： 提前熟悉资料，查看需求是否易于理解，细节有没有说清楚，逻辑是否成立。 对后期的用例编写和是否需要设计评审做到心中有谱。 提前给产品提出问题反馈，产品可以提前补充完善，保证会议的高效。 2、材料 2.1、产品需求文档 产品需求文档要把需求的逻辑表达清楚没有歧义，对各个细节描述清晰。各输入输出项、业务流程、计算规则、判断逻辑、以及特殊情况都要写清楚。可以整理一份适合自己的需求文档自查清单，每次写完后从头到尾对照一遍。 2.2、产品原型文件 产品原型文件尽量做到最高的保真度，每一个点击事件，业务流程最好都可以直接呈现出，以便开发理解。产品原文件的元件管理要合理，要易于查询和修改。 2.3、美术图 美术效果图需要在需求评审前出图，效果图要保证为定稿，不会再做修改。 3、内部评审 产品内部评审就是在产品团队内部进行小范围评审，确保需求逻辑的一致性。规避大部分需求不合理的地方，可以直接有效的提升需求评审的效率。也可以在产品内部进行复查，看是否有涉及多个产品的需求点，需要协调配合的。 4、准评审条件 需求带有完整的效果图； 与会人员对于需求内容没有异议； 材料至少提前1天发出，复杂需求的评审需要至少提前2天发出； 会议至少提前1天发起； 所有需求提前沟通，已确认可实现； 主要成员前期准备妥当，无缺席； 三、会议流程 1、评审中 1.1、讲解内容： 明确本次需求评审会的背景及目标； 从功能点开始，告诉大家我们这个需求要为用户提供什么，这个需求是怎么来的，这个需求有什么价值。然后讲原型，结合需求文档每个功能点逐一讲解。 1.2、讨论/提问规范： 仅需求范围，可涉及基本技术方案，但不涉及具体技术实现； 需求细节问题不展开； 如果讨论了5分钟以上仍然没有结论，产品就记下这个问题，先进行后面的内容，最后再掉回头来讨论之前有争议的问题。如还不能解决则记下来，会后协调。 1.3、是否需要概设评审： 如果有，则要确认版本