需求评审规范总结.docx

精品文档 需求评审规范 产品标识： 文件状态： 文件标识： 需求评审规范 [ ] 草稿 当前版本： V1.0 [ √] 正式发布 作 者： 陈洁 [ ] 正在修改 完成日期： 2016-12-02 变更记录 序号 完成日期 修改内容 作者 审查 1 2016-10-28 初稿完成 陈洁 2 2016-11-07 细化内容，添加了内部评审 粟涛 3 2016-11-08 添加需求声明，增加附件 陈洁 4 2016-12-02 根据反馈进行优化修改 粟涛 . 精品文档 目录 一、概要 3 1、规范化需求评审的目的 3 2、明确需求评审目的 3 3 、明确需求评审的与会人员 3 4、每周需求评审次数 3 二、评审准备 4 1、人员职责 4 2、材料 5 3、内部评审 6 4、准评审条件 6 三、会议流程 6 1、评审中 6 2、准出标准 7 3、评审后 7 四、需求变更 8 1、准更时间 8 2、需求变更来源 8 3、需求变更类型 8 4、需求变更审核 8 5、需求变更同步 9 6、变更申明 9 7、特殊说明 9 . 精品文档 五、声明 9 一、概要 1、规范化需求评审的目的 1.1 、提升需求质量，保障产品质量； 1.2 、提高评审会议效率和质量； 2、明确需求评审目的 2.1 、让技术及测试对产品方案有详细的了解，以便后续开发更高效； 2.2 、让与会者清晰的知道自己在整个发开过程中处于什么位置，职责是什 么，需要做什么，准备什么，提供什么帮助，对各自负责部分的实现难度及排期 有一定的心理预期； 2.3 、需求评审只对本次需求进行讨论，不深入，不发散。 、明确需求评审的与会人员 3.1 、提前核实和通知本次需求参与的相关人员 4、每周需求评审次数 4.1 、提前询问测试本周是否有时间进行需求评审，不要因为需求评审而导 致测试计划打乱。 4.2 、原则上需求评审每周最多 2 次。 . 精品文档 二、评审准备 1、人员职责 产品： a）准备《产品需求文档》《产品原型文件》《美术需求文档》《美术效果 图》。 ）编写《产品需求文档》《产品原型文件》时提前和相关的程序负责人进 行沟通，将一些不确定的方案给确定下来， 探讨方案实现的难易程度， 确保某些 需求的可行性， 还可以发现可能与原有产品逻辑相冲突的地方等， 提前将这些工 作做好，确保需求评审会议的高效。 c）涉及运营的需要和运营提前进行沟通，确定运营需求细节并明确是否需 要运营平台支持。 d ） 《美术需求文档》要和美术详细描述需求，明确功能。在需求评审前制 作出效果图。 f） 至少提前一天将资料以邮件形式发出并通知与会人员，让与会者提前查 看。 g ）会议的发起至少提前半天进行通知，最好是和资料一并提前 1 天发送， 好做好提前的协调，保证都能准时参会。 开发： a）提前熟悉资料，查看 需求是否易于理解，细节有没有说清楚，逻辑是否 成立。 b ）对技术可行性进行分析，能不能做，成本多大规模，有多大风险。 . 精品文档 c）提前给产品提出开发的问题反馈，产品可以提前补充完善，保证会议的 高效。 测试： a）提前熟悉资料，查看 需求是否易于理解，细节有没有说清楚，逻辑是否 成立。 ）对后期的用例编写和是否需要设计评审做到心中有谱。 c）提前给产品提出问题反馈，产品可以提前补充完善，保证会议的高效。 2、材料 2.1 、产品需求文档 产品需求文档要把需求的逻辑表达清楚没有歧义，对各个细节描述清晰。各 输入输出项、业务流程、计算规则、判断逻辑 、以及特殊情况都要写清楚。可 以整理一份适合自己的需求文档自查清单，每次写完后从头到尾对照一遍。 2.2 、产品原型文件 产品原型文件尽量做到最高的保真度，每一个点击事件，业务流程最好都可 以直接呈现出， 以便开发理解。 产品原文件的元件管理要合理， 要易于查询和修 改。 2.3 、美术图 美术效果图需要在需求评审前出图，效果图要保证为定稿，不会再做修改。 . 精品文档 3、内部评审 产品内部评审就是在产品团队内部进行小范围评审，确保需求逻辑的一致 性。规避大部分需求不合理的地方， 可以直接有效的提升需求评审的效率。 也可 以在产品内部进行复查，看是否有涉及多个产品的需求点，需要协调配合的。 4、准评审条件 a）需求带有完整的效果图； ）与会人员对于需求内容没有异议； c）材料至少提前 1 天发出，复杂需求的评审需要至少提前 2 天发出； d ）会议至少提前 1 天发起； e）所有需求提前沟通，已确认可实现； f）主要成员前期准备妥当，无缺席； 三、会议流程 1、评审中 1.1 、讲解内容： a）明确本次需求评审会的背景及目标； ）从功能点开始，告诉大家我们这个需求要为用户提供什么，这个需求是怎么来的，这个需求有什么价值。 然后讲原型， 结合需