XXXX需求管理规范V11.docx

XXXX需求管理规范V11.docx

《XXXX需求管理规范V11.docx》由会员分享，可在线阅读，更多相关《XXXX需求管理规范V11.docx（7页珍藏版）》请在冰豆网上搜索。

XXXX需求管理规范V11

密级：

内部公开

文档编号：

SL_RD_XQGLGF

需求管理规范

编制：

XX

生效日期：

2018-03-09

审核：

XXX

批准：

-------------------------------------------------------------------

XXX科技公司对本文件资料享受著作权及其它专属权利，未经书面许可，不得将该等文件资料（其全部或任何部分）披露予任何第三方，或进行修改后使用。

日期

版本号

修订说明

修订人

审核人

批准人

2017-07-21

0.1

创建

XX

XXX

1.目的

为了保证需求得到有效的处理，客户的需求得到准确的理解和实现，同时也为了规范需求的管理过程，明确需求各个阶段的活动和输出，保证项目的开发前期获得有效的输入，特制订本规范。

2．范围

本规范适用于公司所有产品研发类、产品开发类、合同开发类以及维护开发类项目。

3．术语

术语或缩略语

解释

需求管理

管理项目收到或产生的所有需求，包括技术和非技术的需求，以及组织对项目的需求。

需求追溯

需求与其来源，开发和验证之间关联性的证据。

4.部门/角色与职责

部门/角色

职责

产品经理

产品经理作为产品的需求的唯一接入口，负责主导需求阶段的一切活动，包括获取需求、需求分析、需求说明书的编写、原型输出、相关需求评审会议的支持。

设计部

参与需求评审，根据产品部的需求说明书和原型进行UI效果的输出,包括但不限于psd、效果图、切图等等。

研发中心

参与需求评审，对需求的实现

开发工程师

负责维护设计阶段的需求跟踪矩阵，参与需求评审。

测试工程师

负责维护测试阶段的需求跟踪矩阵，参与需求评审。

项目工程师

负责组织软件开发项目的管理工作

客户

进行需求确认。

研发总监

对涉及到基线的变更进行审批。

5.内容

5.1流程图

阶段

输出

1、需求的收集和获取

2、需求分析

3、需求定义

4、需求确认

5、需求实现

6、需求测试

产品经理

汇总需求、规划版本、报告需求清单

1、确定优先级

2、召集需求分析讨论会

1、输出产品需求文档

2、召集产品设计启动会

1、输出原型/UI

2、召集产品开发启动会

需

求

变

更

研发人员

参加需求分析讨论会

参加产品设计启动会

参加产品开发启动会

1、安装包

2、releasenotes

3、测试说明文档

修复bug

测试

参加产品开发启动会

1、测试用例

测试

需求跟踪

图1需求开发与管理过程活动示意图

5.2主要活动

需求管理的目的是在客户与项目组之间建立对需求的共同理解，维护需求与其它工作成果的一致性，并控制需求的变更。

需求管理的主要活动包括：

需求确认，需求变更和需求跟踪控制。

5.2.1需求获取（需求的收集和整理）

产品经理作为需求的唯一接入口，应基于现有产品的业务发展方向，通过与用户的交流、问卷调查等方式，收集用户对于该产品业务的看法，并对这些看法进行归类整理和登记，达成口头或者是书面的需求意向协议书。

（这个过程需要对产品的业务建立起一个概念模型，以便对其进行抽象描述。

用户很多时候都不懂专业术语，所以需要尽可能的使用场景化的语言描述方式去进行描述。

比如想调研用户的理财方式，很多用户可能不清楚“理财”的具体意思，但你问他“平时是如何管理多余的资金，是变成银行存款还是有别的方式？

”可能他会更容易明白。

）

5.2.2需求分析

产品经理就获得的需求意向或者意向协议书，围绕产品的业务核心，进行初步的评估，预判其成本、时间、资源、技术等可行性和必要的风险评估，以确认需求是否要接受。

除了要从收集回来的需求当中找到要做的真实需求外，还要基于需求的业务价值评判出需求执行的优先级。

其评估的过程，产品经理可以召集研发负责人，组织一次需求的分析讨论会，以便对需求更全面的分析。

5.2.3需求定义

根据需求调研和需求分析的结果，进一步定义准确无误的产品需求。

完成需求的分解工作，并输出产品功能需求文档，包括但不限于以下内容：

详细的《产品需求说明书》，《功能列表》，《技术指标参加资料》等。

产品功能需求文档编写完成后，产品经理召集产品设计启动会，向UE、UI、研发人员宣讲产品功能需求，讨论实现方案，启动开发设计工作。

（需求定义的过程更多的是对需求进行准确的描述，从用户使用场景的角度、功能操作流程的角度等方面，对分析出来的真实需求做出完整、无二义性的定义，让其他相关人员能准确的理解需求。

）

5.2.4需求的确认

需求确认是指项目组和客户（或客户代表）共同对《产品需求说明书》、原型等进行评审，双方对需求达成共识后做出承诺。

UI/UE工程师在规定的时间内完成产品设计文档（效果图和原型），召集产品设计评审会（同时也是产品开发启动会），向需求部门、产品经理、研发、测试宣讲产品开发需求，各部门对产品设计文档进行评审确认，达成统一认知和共识，使需求能够推进实现落地。

在需求评审的过程中，一定要说明清楚需求的背景、价值、意义，而不是纯粹的需求讲解，这样有助于各方对需求的理解。

需求确认包含两个重要工作：

“需求评审”和“需求承诺”。

5.2.4.1需求的评审

应对所形成的需求文档进行评审，以便作为下一阶段工作的基础。

需求评审的方式分为“技术评审会议”与“组内评审”两种。

产品经理根据需求分析的进展情况，采用“组内评审”的方式分阶段对需求分析的阶段成果进行评审，分阶段评审可以将原本需要进行的大规模评审拆分成各个小规模的评审，降低了需求返工的风险，提高了评审的质量。

当需要召开技术评审会议时，由产品经理向相关部门提出需求技术评审申请，由相关部门组织按“技术评审会议”的方式实施需求评审。

（评审过程本身也是一个知识传递过程，评审人员与产品经理一起讨论用户需求，这有助于评审人员获得用户需求的前期认识。

1.评审过程中可能发现不明确的或者遗漏的需求，这需要产品经理进行二次需求分析和定义。

2.评审过程中可能发现某些特殊需求，这时产品经理和评审人员可以群策群力共同思考解决问题的方式。

3.当局者迷、旁观者清。

再有经验的产品经理也可能犯错，评审人员可以提出更合理或者更有建设性的想法供产品经理参考。

）

5.2.4.2需求承诺

产品经理将评审通过的《产品需求说明书》或《原型》提交给客户（或客户代表）进行确认，确认的方式可以是以下方式之一：

直接签字：

由承诺方在《产品需求确认书》或《原型》上直接签字或盖章确认。

邮件方式：

由项目经理将《产品需求确认书》或《原型》与《评审报告》通过邮件发送给接收方，并明确确认通过的准则（如：

如果在一周内未予以回复则默认为确认通过）；

发送会议纪要函：

如果承诺方参加了评审会议并在会上达成了共识，则可以编制会议纪要在纪要中描述参加评审的人员、评审的结论等，并通过纪要函的方式发送给承诺方。

5.2.5需求的实现

根据需求的评审结果，项目经理输出需求实现的计划表，明确各阶段的时间节点和人员安排。

在开发设计阶段，需输出设计文档，并评审；测试部门应按时间节点输出测试用例，并评审。

开发工程师完成编码、单元测试、联调测试，在自测完成的情况下向测试部门输出安装包、releasenotes和测试说明文档申请集成测试。

5.2.6需求的测试

测试部门按照测试流程，进行需求的测试和验证。

同时根据《缺陷处理规程》来处理测试过程是发现的bug，直至灰度测试完成。

5.2.7需求跟踪

跟进需求的设计实现过程，保证需求的实现不打折扣，并随时关注需求的变化。

通过比较需求定义与后续工作成果之间的对应关系，建立与维护需求跟踪列表，确保产品依据需求的定义进行开发。

产品经理每天都需要跟进当前迭代中需求的实现进度，确保需求执行的过程没有出差错，一般而言，需求的跟踪分为两种：

正向跟踪：

检查已安排的每个需求是否都能在后续的实现过程中有相对应的部分，确保没有漏做的需求，并保证需求的实现程度和需求定义要求的一样。

这就需要每天都与后续的各个负责实现的人员进行确认。

逆向跟踪：

根据已有的原型、UI、系统设计文档、测试用例文档等成果文档，反向检查是否包含了所有已安排的需求。

5.2.8需求变更

对一个软件项目来说，无论最初的需求分析有多么明确，开发过程中的需求变化也还是不可避免的。

这主要有以下几种原因：

1.软件所应用的外部环境发生变化；

2.随着用户对软件的熟悉和应用，又提出新的需求；

3.项目组进行需求分析时未能彻底分析用户的需求，或分析错误；

4.用户在开始时不能很全面的知道所需软件的功能。

5.2.6.1需求变更评审及实施

1.对于小修小改的需求，产品经理着急相关人员座位过审，相关人员知悉并同意后，更新Tapd上产品需求更改日志，并在需求详细阐述中，红色标示出修改点，以便下流部门知悉

2.对于大改的需求，召集评审会，待下流部门过审后，项目重新排期，再进入开发阶段，一样需要同步更新需求文档和TAPD上需求日志

6.相关附件、表单