图解项目产品需求评审流程及具体的评审规范实例

需求评审中你都碰着什么问题呢？

请横屏不雅观看

1. 项目卖力人与各干系人未界定:

卖力人该当在项目启动时确定（需求方的高层管理职员、中层管理职员、详细操作职员、IT主管、采购主管；供方的市场职员、需求剖析职员、设计职员、测试职员、质量担保职员、履行职员、项目经理以及第三方的领域专家等等。
）

2. 需求文档的背景、目的未解释，部分项目成员并未理解业务目标:

项目背景、项目目标、需求概述和需求详细描述，必要的时候可以带上项目风险（解释这次版本可能带来的问题或考虑不足完善的地方）和业务流程图（对某些繁芜功能/逻辑的分解）。

（在项目确定初期，由需求方供应需求概要，列出主干功能并简要描述，研发与测试卖力人来判断需求功能要不要实现。
在需求交出初稿的时候，研发与测试卖力人即可以进行分工和排期）

3. 需求文档归档至SVN/Git（需求文档+原型图）:

发布在云真个需求文档哀求最新版本，每次假如有需求改动的部分，在禅道上，SVN/Git要将原有的需求文档更换覆盖，并且整理出干系的修正点（如第几章第几点修正，方便定位需求变动部分）（需求统一解释细节问题：如金额保留两位小数、模糊查询、跳转页面）

（减少隐蔽需求：如果是功能改造或优化的需求，供应原有的需求解释，如邮费部分的功能，供应之前的干系需求如满500包邮、XXX免邮等）

4. 需求定版不明确，会后常有改动和变更：

开拓过程中不愿定或歧义需求太多，未走正规需求变更，直接给研发加任务。
研发与测试都不明白的功能找产品理解时，直接转换成新需求。

（避免口头需求，提成需求反馈，或者bug指派、抄送给产品）

需求变动不可避免，变动记录和折衷问题，按照变动大小：

4.1 有些改个字啥的，不用做变更记录。

4.2 超过10分钟以上的需求，和项目卖力人商量，确定这一期变更，再添加对应需求，变动项目排期；

4.3 再者一些很大变更，不许可变更的情形，直吸网络记录下来由下一期做。

5. 需求卖力人变动时，需求交卸;

争议问题，目前由于没有项目卖力人，还是须要产品、研发、测试的卖力人进行谈论得出。

PS：统计各主流系统的项目流量，并在新增需求项目上线后再次统计项目流量。

在需求初稿的时候，研发与测试卖力人分工安排，对付需求完成稿发送后给干系职员阅读文稿的前置韶光：（供应参考韶光）

难易程度正常（难易程度等其他成分时长偏差为0.5h）

熟习新增：0.7~1h

熟习修正：1.4~2h

陌生新增：2.1~3h

陌生修正：2.8~4h

网站流量剖析：（热力争、眼动热点图、条形图、饼状图、曲线图）

网站访问量的增长趋势图、用户访问最高的时段、访问最多的网页、时段访问量统计剖析、日段访问量统计剖析以及周月访问量统计剖析

需求评审时常发生的情形 ：

1、与会职员对需求的目标不明确，易发散思维，终极偏离方向。

2、对某个需求点相持不下，认为该需求不合理/开拓周期长不划算，从而导致场面混乱，永劫光僵持下去。

3、对技能方案磋商不定，对问题点无限引申。

4、遗漏评审时的待改动的需求点，会后找干系职员再次确认。

需求文档：

1. 项目背景

2. 项目目标

3. 需求概述

3. 需求详细描述

4. 业务流程图（对某些繁芜功能/逻辑的分解）

5. 项目风险（解释这次版本可能带来的问题或考虑不足完善的地方）

需求检讨单可以分成2类：需求形式的检讨单和需求内容的检讨单。

需求形式的检讨可以由QA职员卖力，紧张是针对需求文挡的格式是否符合质量标准来提出的

需求内容的检讨是由评审员卖力的，紧张是检讨需求内容是否达到了系统目标、是否有遗漏、是否有缺点等等，这是需求评审的重点。

需求文档自查清单：

1. 需求的逻辑表达清楚没歧义

2. 对各个细节描述清晰（如金额保留两位小数）

3. 业务流程（功能的交互步骤和数据的流转）

4. 各输入输出项（涉及到表单/数据的输入输出）

5. 打算规则（某些特定须给出打算的规则）

6. 判断逻辑 （业务流程中涌现的一些判断逻辑、各种判断下的反馈情形、账号的权限范围）

7. 分外情形（如是否支持横屏啊之类的）

图解项目产品需求评审流程及详细的评审规范实例