产品需求流程管理规范

产品需求管理规范

文档修订记录

*变化类型：创建、增加、修改、删除、审核

【说明】：这里只保留上一个版本到当前版本变更的内容

目录

文档概述 (2)

1.1编写目的 (2)

1.2读者对象 (2)

1.3术语与名词解释 (2)

整体合作流程 (3)

2.1需求设计 (3)

需求设计管理规范 (4)

3.1需求开发管理 (6)

3.1.1需求调研 (6)

3.1.1需求设计 (6)

3.1.2需求评审 (7)

3.1.3需求质量跟踪 (7)

3.2需求变更管理 (8)

3.2.1提出变更需求； (8)

3.2.2需求响应： (8)

3.2.3需求变更确认： (8)

3.2.4是否需要评审： (8)

3.2.5更新基线库： (8)

3.2.6通知： (8)

文档概述

1.1编写目的

供需求设计、UI、设计开发、测试等各个环节了解互相合作的流程1.2读者对象

对于不同用户所关心的部分有所不同，我们建议您：

用户类别重点章节说明

1.3术语与名词解释

序号术语、名词解释

1基线一个已经被正式评审和批准的规格或产品，它作为进一步开发的一个基础，并且必须通过正式的变更流程来变更。

2 3

整体合作流程

流程图如下：

2.1需求设计

1、需求内部正式评审

1)需求负责人通知开发负责人，测试负责人；

2)开发负责人熟悉业务功能；

3)测试负责人安排相关人员熟悉业务功能

2、需要交互设计、或视觉设计的业务模块，需要在交互设计、视觉设计完成后，进行外部

评审；

3、外部评审后，如果有重大变更，需要重新循环内部评审

4、几个环节就需求达成一致后，需求人员把原型和文档放入基线库，并通过邮件通知开发、

测试负责人。后续环节可以基于此正式开展工作。

需求设计管理规范

3.1需求开发管理

3.1.1需求调研

1、由需求人员确定每次调研的主题，并制定《需求调研计划》。需求人员确认需求调研计

划后，提前3天左右把计划以正式邮件的形式发给客户确认，并通知客户携带需要的资料。

2、在需求调研之前，需求人员可通过研究原有系统、已有业务资料、搜索互联网等方式，

提前熟悉调研相关的业务知识，搜集业务资料。搜集到的资料文档需存放到svn文件夹中。

3、每次调研之前把计划从客户处搜集的资料在《需求调研资料搜集清单》列出，便于调研

时与客户核对。调研完成后补充完善资料记录，统一存放到svn文件夹中。

4、调研完成后，需求人员对调研的记录进行汇总整理，由项目负责人、产品经理对资料进

行审核。

5、如果调研要分多次进行，对当次调研内容的整理应该立刻进行，最迟不能超过下次调研。

这样做可避免调研内容的遗漏和遗忘，在进行下次调研时可针本次调研后的一些问题进行再次调研。

6、调研全部完成后，需要把整理的调研内容记录整理细化到结构化的《用户需求汇总表》

中。并在该表中标注出存在疑问的业务点，以便后续通过电话、QQ等方式与客户沟通清楚。

3.1.1需求设计

1、需求人员开始编写需求文档和制作原型之前，务必要先仔细查看《用户需求汇总表》。

在了解对应业务模块的用户需求之后，再对用户需求进行分析。可通过Excel、Mind Manager等工具辅助需求分析。

2、需求人员完成需求分析后，项目经理/产品经理必须与其沟通确认，以确保需求人员对

用户需求理解正确。

3、需求人员在需求设计过程中可根据个人的工作习惯可虑优先产出《需求规格说明书》或

系统原型，常用系统原型工具Axure RP、Justinmind、Visio，系统原型设计至少保证软件关键界面的主要菜单、功能、按钮、列表、等元素信息完整，其余页面尽量也使用原型进行展示，如受到时间及精力限制也可以考虑使用纯文字描述或将互联网已有图片截取进行描述，截图内容不可与实际界面存在过大差异，可以使用画图软件进行标记。

原型界面中通常会涉及到一些业务逻辑及业务规则，建议在界面空白处进行标注。

PC

APP

3.1.2需求评审

1、需求内部评审需要项目组人员全部参加；需求外部评审需要产品经理、技术总监及相关

公司领导参加。

2、每次评审前，需求人员至少提前一天以邮件或消息的形式通知参与人员。评审会上，经

相关人员讨论确认后的问题或缺陷，由需求人员记录《评审缺陷记录表》。项目经理、产品经理对评审缺陷的状态进行跟踪，直至缺陷关闭。

3、评审的参与人员达成一致后，可以给出如下三种评审结论：

1)完全合格-直接评审通过，无需修改。

2)基本合格-需要作少量的修改，之后通过审核即可。

3)不合格-存在较大问题（如整个功能业务理解错误等），需要做较大的修改，之后必

须重新对其评审。

4、评审完成后，需求人员完成对《评审缺陷记录表》的整理，并通过邮件方式将记录表发

送给所有评审人员，如存在缺陷需调整建议明确缺陷修改完成时间。

3.1.3需求质量跟踪

在整个需求开发过程中，项目经理或产品经理对需求质量进行持续监督和跟踪。每一个需求迭代周期对各个需求人员的需求文档、原型进行质量分析。《评审缺陷质量分析表》、《需求变更统计分析表》

对于需求产出质量较差的需求人员，项目相关负责人要及时与之面谈，帮助其分析问题

所在，以便后续提升需求质量。

3.2需求变更管理

3.2.1提出变更需求；

需求变更发起通常发生在用户对原有需求产生新的想法，或需求人员在后续系统设计及开发讨论过程中对产品有更好的想法或发现产品的设计缺陷。

3.2.2需求响应：

需求人员首先对需求变更内容进行分析，同时可以要求项目经理或产品经理对需求变更的可行性及合理性进行评估。

3.2.3需求变更确认：

确认变更后，需求人员填写《需求变更记录表》，并完成系统原型及需求规格说明书的修改。

3.2.4是否需要评审：

由需求人员、项目负责人、开发负责人讨论确定是否需要评审。

3.2.5更新基线库：

评审通过或执行不评审流程后，由需求人员与用户通过邮件或签字完成需求变更说明书的确认工作。需求人员也可以考虑将多次的需求变更与用户一次性确认，具体流程可以与用户或公司领导协商。基线库必须保存历史版本的系统原型及《需求规格说明书》。

3.2.6通知：

更新基线库后以邮件形式通知项目组相关人员，包括：开发、测试、UI、项目经理、产品经理等。