iniip|[ii|tpI—1>4mL2016-12-02sm宦{|R把 AfigWW•;帼巳出毂「>「“\、111111«|世4m4mL阳 CiO-{IRD|PI—1CXICO寸目录一、概要 31、规范化需求评审的目的 32、明确需求评审目的 33、明确需求评审的与会人员 34、每周需求评审次数 3二、评审准备 41、人员职责 42、材料 53、内部评审 64、准评审条件 6三、会议流程 61、评审中 62、准出标准 73、评审后 7四、需求变更 81、准更时间 82、需求变更来源 83、需求变更类型 84、需求变更审核 85、需求变更同步 96、变更申明 97、特殊说明 9五、声明 9一、概要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）提前熟悉资料，查看需求是否易于理解，细节有没有说清楚，逻...
