XXXX-需求管理规范V11

1、密 级：内部公开文档编号：sl _rd_xqglgf需求管理规范编制：xx生效日期：2018-03-09审核：xxx批准：xxx科技公司对本文件资料享受著作权及其它专屈权利，未经书面许可，不得将该等文件资料（其全部或任何部分）披露予任何第三方，或进行修改后使用。www.sunhght-日期版本号修订说明修订人审核人批准人2017-07-210创建xxxxxee8bbmj2目录1. 目的32. 范围-33. 术语34. 部门/角色与职责-35. 内容45.1 流程图-45.2 主要活动-5521需求获取（需求的收集和整理）-55.2.2需求分析-55.2.3需求定义-55.2.4需求的确认-65

2、.2.5需求的实现-75.2.6需求的测试-75.2.7需求跟踪-75.2.8需求变更-76. 相关附件、表单-8sunlignt-tech.c1.目的为了保证需求得到有效的处理，客户的需求得到准确的理解和实现，同时也 为了规范需求的管理过程，明确需求各个阶段的活动和输出，保证项目的开发前 期获得有效的输入，特制订本规范。2.范围本规范适用于公司所有产品研发类、产品开发类、合同开发类以及维护开发 类项目。3术语术语或缩略语解释需求管理管理项目收到或产生的所有需求，包括技术和非技术的需求，以及 组织对项目的需求。需求追溯需求与其來源，开发和验证z间关联性的证据。4.部门/角色与职责部门/角色职责

3、产品经理产品经理作为产品的需求的唯一接入口，负责主导需求阶段的i切 活动，包括获取需求、需求分析、需求说明书的编写、原型输出、 相关需求评审会议的支持。设计部参与需求评审，根据产品部的需求说明书和原型进行ui效果的输 出,包括但不限于psd、效果图、切图等等。研发中心参与需求评审，对需求的实现开发工程师负责维护设计阶段的需求跟踪矩阵，参与需求评审。测试工程师负责维护测试阶段的需求跟踪矩阵，参与需求评审。项目工程师负责组织软件开发项目的管理工作客户进行需求确认。研发总监对涉及到基线的变更进行审批。s8b0科披-ww.sunlight-5.内容5.1流程图阶段 输出1、需求的收集 和获取2需求分析

4、3需求定义4、需求确认5、需求实现6、需求测试产品经理汇总需求、规 划版本、报告 需求清单1、确定优先级2、召集需求分析讨论会1、输岀产品需求文档2、召集产品设计启动会1、输出原型/ui2、召集产品开发启动会需 求 变 更研发人员参加需求分析讨论会参加产品设计启动会参加产品开发启动会1、安装包2、release notes3、测试说明文档修复bug测试参加产品开发启动会1、测试用例测试需求跟踪图1盂求开发与管理过程活动示意图sunlignt-tech.c5.2主要活动需求管理的目的是在客户与项目组之间建立对需求的共同理解，维护需求与 其它工作成果的一致性，并控制需求的变更。需求管理的主要活动包

5、括：需求 确认，需求变更和需求跟踪控制。5.2.1需求获取（需求的收集和整理）产品经理作为需求的唯一接入口，应基于现有产品的业务发展方向，通过与 用户的交流、问卷调查等方式，收集用户对于该产品业务的看法，并对这些看法 进行归类整理和登记，达成口头或者是书面的需求意向协议书。（这个过程需要对产品的业务建立起一个概念模型，以便对其进行抽彖描 述。用户很多时候都不懂专业术语，所以需耍尽可能的使用场景化的语言描述方 式去进行描述。比如想调研用户的理财方式，很多用户可能不清楚“理财”的具 体意思，但你问他“平时是如何管理多余的资金，是变成银行存款还是有別的方 式？"可能他会更容易明白。）522

6、需求分析产品经理就获得的需求意向或者意向协议书，围绕产品的业务核心，进行初 步的评估，预判其成本、时间、资源、技术等可行性和必要的风险评估，以确认 需求是否要接受。除了要从收集回来的需求当中找到要做的真实需求外，还要基于需求的业务 价值评判出需求执行的优先级。其评估的过程，产品经理可以召集研发负责人，组织一次需求的分析讨论会, 以便对需求更全面的分析。523需求定义根据需求调研和需求分析的结果，进一步定义准确无误的产品需求。完成需 求的分解工作，并输出产品功能需求文档，包括但不限于以下内容：详细的产 品需求说明书，功能列表，技术指标参加资料等。产品功能需求文档编写完成后，产品经理召集产品设计启

7、动会，向ue、ui、 研发人员宣讲产品功能需求，讨论实现方案，启动开发设计工作。（需求定义的过程更多的是对需求进行准确的描述，从用户使用场景的角 度、功能操作流程的角度等方面，对分析出来的真实需求做出完整、无二义性的 定义，让其他相关人员能准确的理解需求。）5.2.4需求的确认需求确认是指项日组和客户（或客户代表）共同对产品需求说明书、原 型等进行评审，双方对需求达成共识后做出承诺。ui/ue工程师在规定的时间内完成产品设计文档（效果图和原型），召集产 品设计评审会（同时也是产品开发启动会），向需求部门、产品经理、研发、测 试宣讲产品开发需求，各部门对产品设计文档进行评审确认，达成统一认知和共

8、 识，使需求能够推进实现落地。在需求评审的过程中，一定要说明清楚需求的背景、价值、意义，而不是纯 粹的需求讲解，这样有助于各方对需求的理解。需求确认包含两个重要工作：“需求评审”和“需求承诺”。5. 2. 4. 1需求的评审应对所形成的需求文档进行评审，以便作为下一阶段工作的基础。需求评审 的方式分为“技术评审会议”与“组内评审”两种。产品经理根据需求分析的进展情况，采用“组内评审”的方式分阶段对需求 分析的阶段成果进行评审，分阶段评审可以将原本需要进行的大规模评审拆分成 各个小规模的评审，降低了需求返工的风险，提高了评审的质量。当需要召开技术评审会议时，由产品经理向相关部门提出需求技术评审中

9、 请，由相关部门组织按“技术评审会议”的方式实施需求评审。（评审过程本身也是一个知识传递过程，评审人员与产品经理一起讨 论用户需求，这有助于评审人员获得用户需求的前期认识。1. 评审过程中可能发现不明确的或者遗漏的需求，这需要产品经理 进行二次需求分析和定义。2. 评审过程中可能发现某些特殊需求，这吋产品经理和评审人员可 以群策群力共同思考解决问题的方式。3. 当局者迷、旁观者清。再有经验的产品经理也可能犯错，评审人 员可以提出更合理或者更有建设性的想法供产品经理参考。）5. 2.4.2需求承诺产品经理将评审通过的产品需求说明书或原型提交给客户（或客户 代表）进行确认，确认的方式可以是以下方式

10、之一：直接签字：由承诺方在产品需求确认书或原型上育接签字或盖 章确认。 邮件方式：由项目经理将产品需求确认书或原型与评审报告 通过邮件发送给接收方，并明确确认通过的准则（如：如果在一周内未 予以回复则默认为确认通过）； 发送会议纪要函：如果承诺方参加了评审会议并在会上达成了共识，则 可以编制会议纪要在纪要中描述参加评审的人员、评审的结论等，并通 过纪要函的方式发送给承诺方。525需求的实现根据需求的评审结果，项fi经理输出需求实现的计划表，明确各阶段的时间 节点和人员安排。在开发设计阶段，需输出设计文档，并评审；测试部门应按时 间节点输岀测试用例，并评审。开发工程师完成编码、单元测试、联调测试

11、，在自测完成的情况下向测试部 门输出安装包、release notes和测试说明文档申请集成测试。526需求的测试测试部门按照测试流程，进行需求的测试和验证。同时根据缺陷处理规程 来处理测试过程是发现的bug,直至灰度测试完成。5.2.7需求跟踪跟进需求的设计实现过程，保证需求的实现不打折扣，并随时关注需求的变 化。通过比较需求定义与后续工作成果之间的对应关系，建立与维护需求跟踪列 表，确保产品依据需求的定义进行开发。产品经理毎天都需要跟进当前迭代中需求的实现进度，确保需求执行的过程 没有岀差错，一般而言，需求的跟踪分为两种：正向跟踪：检查已安排的每个需求是否都能在后续的实现过程中有相对应的 部分，确保没有漏做的需求，并保证需求的实现程度和需求定义要求的一样。这 就需要每天都与后续的各个负责实现的人员进行确认。逆向跟踪：根据已有的原型、ui、系统设计文档、测试用例文档等成果文档,反向检查是否包含了所有己安排的需求。5.2.8需求变更对一个软件项目来说，无论最初的需求分析有多么明确，开发过程中的需求 变化也还是不可避免的。这主要有以下几种原因：1. 软件所应用的外部环境发生变化；2. 随着用户对软件的熟悉和应用，又提出新的需求；3. 项目组进行需求分析时未能彻底分析用户的需求，或分析错误；4. 用户在开始时不能很全面的知道所需软件的功