需求开发流程

密级：内部公开

文档编号：KKCQ-Proc-RDM

版本号：V1.0

分册名称：第1册/共1册

需求开发与管理说明

文档更改摘要：

1. 目的

通过此需求开发流程的定义，规范公司内部项目的需求开发和管理活动，提高需求质量，从而提高需求任务处理率，降低开发成本，改进系统质量。

通过对业务部提交的需求进行评审，确保需求的正确性和合理性，获得需求的承诺；控制需求的变更，并确保项目工作成果与需求的一致性。

2. 范围

适用于公司内部开发项目及已经通过《商业需求确认书》的项目，如未通过《商业需求确认书》，技术中心暂时无法参与需求立项，评审，分析等流程。附件一：《商业需求确认书》

3. 术语

4. 角色与职责

5. 流程图

图1：需求开发流程图

6. 主要活动

需求定义的目的是需求提出人通过收集、调查与分析，获取用户业务需求并定义需求。需求定义的主要活动包括：需求收集、需求分析&定义。

需求管理的目的是在需求方与程序组之间建立对需求的共同认识和理解，维护需求与程序开发成果的一致性，并控制需求的变更。需求管理的主要活动包括：需求评审确认、需求变更、需求跟踪控制。

6.1需求定义

由于在实际情况下，大部分原始需求都未完整地讲述其业务需求，需求获取的质量，对后续的需求分析和需求定义工作将会产生重大影响。

在完成需求收集所得到的记录与资料的分析与整理后，产品经理应对需求进行分类、排优先级等。

6.1.1 标识需求与命名规则

为了便于需求文档的统一管理，更好的识别每个项目的需求，需要明确需求文档的命名规则，具

体格式为：

[需求年月]-[项目类别]-[用途类别]

如，201310-综合信息项目-活动需求；

6.1.2 需求分类

在需求文档中，一般取二级类别进行标识。

6.1.3 需求优先级

时，正确地对需求实现的范围或实现的优先程度做出取舍。

6.1.4 编写《立项需求说明书》

在需求收集后，需求受理人应根据需求收集得到的记录与资料，整理编写《立项需求说明书》，其主要内容应该包括但不局限于：

●功能介绍：描述需求功能的用途和提出背景；

●功能的最终用户（群体）及其特征；

●功能需求的商业用途及数据报告；

●功能的具体需求说明；

●UE图。

编写需求说明书应遵循以下规则：

●相关的需求都得到了识别与描述，以确保需求的完整性；

●正确描述功能需求，引用的资料有正规的出处，以确保需求的正确性；

●定义必要的术语，适当结合图形、结构图等方式进行描述，以确保需求无二义性；

●使用较好的文档结构与需求标识，使需求能够方便地与其它工作产品相对应，以确保需求易

于跟踪；

●确保所描述的需求可以通过适当的手段得到验证，即需求的可测试性；

●考虑了各个层次的需求影响，确定了需求的优先级，以确保需求的可行性。

提醒：编制《立项需求说明书》应按网站内容进行功能需求的编写；对于页面调整、活动等不需要做过多业务流程更改的需求，采用《程序需求表》进行填写。

6.2 需求评审确认及产品开发流程

需求评审是指程序方和需求提出方共同对《立项需求说明书》进行评审，双方对需求与商业目的达成共识。

在需求说明书生成后，需求分析员将文档提交给需求受理人，由受理人进行初审，确保文档的正确性和合理性，并符合文档编写规范。

6.2.1 需求评审

评审的目的在于：使需求文档达到易读、无歧义、一致、必要、完整、可实现、可验证。

需求受理人（一般为部门总监，各个地区分站由技术中心受理）对提交的需求文档进行初审通过后，由技术中心组织和安排需求的评审工作：确定评审时间、地点、评审人员和其他参加人员。至少应包含以下成员：

●评审组长：CEO、技术总监；

●评审成员：产品经理、程序员及其他相关人员；

●输入：《立项需求说明书》初稿

●输出：《评审结果报告》

当需求文档评审通过后，程序方和需求提出方应须进行书面签字确认，使之生效。之后若需要调整需求，则须走需求变更控制流程。

未经书面确认的需求开发，若发生需求分歧，由未签字确认方及其上级承担主要责任。

经书面确认的需求开发，若发生预期需求与开发实现的功能不一致而影响开发质量的，责任归属界定： A. 因需求不明确、阐述遗漏、描述错误等，且后期没有对应的需求变更记录备案，而造成实现

的功能与预期需求不一致，由需求方承担主要责任。 B. 因需求不明确、阐述遗漏、描述错误等，而后期存在对应的需求变更记录备案，而造成实现

的功能与预期需求不一致的，由程序方承担主要责任。

6.2.2 产品宣讲

产品宣讲的目的在于：按开发规范并保证《需求功能白皮书》及《产品原型》技术人员能理解、可实现、可验证、无歧义。

产品经理（分为地方站产品经理与十度产品经理）对业务部门提出的需求按现有数据进行需求转化，并分辨优先级及开发级别，形成《需求白皮书》及《产品原型》后，由产品经理发起宣讲会议，安排宣讲时间、地点、程序负责人与其他相关人员参加，至少应包含以下成员：

● 程序负责人、程序员与需求发起人 ● 输入：《需求功能白皮书》及《产品原型》 ● 输出：《任务进度表》

6.3 需求变更

对一个软件项目来说，无论最初的需求分析有多么明确，开发过程中的需求变化也还是不可避免。这主要有以下几种原因：

1. 系统所应用的外部环境发生变化；

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

3. 进行需求分析时未能彻底分析原始需求，或分析错误；

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

需求变更的影响：对项目研发而言，变更需求意味着有可能需要重新分配任务、修改前期工作成果、调整工作计划和项目预算等。

只有当需求变更带来的好处大于坏处时，变更需求才是有意义的，但也须遵循变更控制流程：申请→审批→执行；如果需求变更带来的坏处大于好处，则应拒绝变更。

需求受理人应适当 拒绝一些不合理的变更。如：提出的变更不是由于程序方的过错引起的，此变更可能造成程序方占用额外的资源或成本，而需求方又不愿给出额外资源对变更进行处理等。

变更控制流程如图所示，主要包括：变更申请、评审和审批、填写执行记录。

申请变更变更评审及审批执行变更

终止变更

YES NO