需求管理规范V

密级：内部公开

文档编号：SL_RD_XQGLGF

需求管理规范

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

目录

1.目的

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

期获得有效的输入，特制订本规范。

2．范围

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

3．术语

4.部门/角色与职责

5.内容

5.1流程图

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

5.2主要活动

需求管理的目的是在客户与项目组之间建立对需求的共同理解，维护需求与其它工作成果的一致性，并控制需求的变更。需求管理的主要活动包括：需求确认，需求变更和需求跟踪控制。

（需求的收集和整理）

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

（这个过程需要对产品的业务建立起一个概念模型，以便对其进行抽象描述。用户很多时候都不懂专业术语，所以需要尽可能的使用场景化的语言描述方式去进行描述。比如想调研用户的理财方式，很多用户可能不清楚“理财”的具体意思，但你问他“平时是如何管理多余的资金，是变成银行存款还是有别的方式？”可能他会更容易明白。）

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

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

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

根据需求调研和需求分析的结果，进一步定义准确无误的产品需求。完成需求的分解工作，并输出产品功能需求文档，包括但不限于以下内容：详细的《产品需求说明书》，《功能列表》，《技术指标参加资料》等。

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

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

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

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

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

需求确认包含两个重要工作：“需求评审”和“需求承诺”。

需求的评审

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

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

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

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

（评审过程本身也是一个知识传递过程，评审人员与产品经理一起讨

论用户需求，这有助于评审人员获得用户需求的前期认识。

1.评审过程中可能发现不明确的或者遗漏的需求，这需要产品经理

进行二次需求分析和定义。

2.评审过程中可能发现某些特殊需求，这时产品经理和评审人员可

以群策群力共同思考解决问题的方式。

3.当局者迷、旁观者清。再有经验的产品经理也可能犯错，评审人

员可以提出更合理或者更有建设性的想法供产品经理参考。）需求承诺

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

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

章确认。

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

予以回复则默认为确认通过）；

发送会议纪要函：如果承诺方参加了评审会议并在会上达成了共识，则

可以编制会议纪要在纪要中描述参加评审的人员、评审的结论等，并通

过纪要函的方式发送给承诺方。

5.2.5需求的实现

根据需求的评审结果，项目经理输出需求实现的计划表，明确各阶段的时间节点和人员安排。在开发设计阶段，需输出设计文档，并评审；测试部门应按时间节点输出测试用例，并评审。

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

5.2.6需求的测试

测试部门按照测试流程，进行需求的测试和验证。同时根据《缺陷处理规程》来处理测试过程是发现的bug，直至灰度测试完成。