需求开发流程.docx

需求开发流程.docx

《需求开发流程.docx》由会员分享，可在线阅读，更多相关《需求开发流程.docx（12页珍藏版）》请在冰豆网上搜索。

需求开发流程

密级：

内部公开

文档编号：

KKCQ-Proc-RDM

版本号：

V1.0

分册名称：

第1册/共1册

需求开发与管理说明

编制：

胡杨

生效日期：

审核：

批准：

文档更改摘要：

日期

版本号

修订说明

修订人

审核人

批准人

V1.0

创建

胡扬

V1.0

更换变更控制报告的模板

胡扬

V1.0

更换商业需求确认书模板

胡扬

V1.0

增加产品流程及输出

胡扬

1.目的

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

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

2.范围

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

附件一：

《商业需求确认书》

3.术语

术语或缩略语

解释

需求

即用户的需要，它包括用户要解决的问题、达到的目标、以及实现这些目标所需要的条件，它是一个程序或系统开发工作的说明，表现形式一般为文档形式。

需求分析

是指在需求开发过程中，对所获取的需求信息进行分析，及时排除错误和弥补不足，确保需求文档正确地反映用户的真实意图。

4.角色与职责

角色

职责

程序负责人

负责审核需求内容和安排需求任务，并实现对需求任务跟踪和控制

需求负责人

1.负责对需求任务的跟踪和验证；

2.负责业务需求的收集和提交

5.流程图

图1：

需求开发流程图

6.主要活动

需求定义的目的是需求提出人通过收集、调查与分析，获取用户业务需求并定义需求。

需求定义的主要活动包括：

需求收集、需求分析&定义。

需求管理的目的是在需求方与程序组之间建立对需求的共同认识和理解，维护需求与程序开发成果的一致性，并控制需求的变更。

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

需求评审确认、需求变更、需求跟踪控制。

6.1需求定义

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

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

6.1.1标识需求与命名规则

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

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

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

6.1.2需求分类

由于需求来源广泛，为了便于区别，需要将需求进行分类，分类规则如下：

分类规则

具体类别

按项目分类

◆综合信息项目

◆行业频道项目

◆其他项目

按用途分类

◆界面需求

◆程序需求

◆系统级开发

◆活动需求

◆系统功能升级

◆系统性能优化

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

6.1.3需求优先级

需求分析员应确定每个需求的优先级，需求的优先级判定标准如下：

级别定义

判断标准

采取的措施

优先

满足以下任意一条时：

1）需求实现的紧急程度为特急或紧急

2）国家或行业法律法规、标准要求的，满足正常业务必须的

3）能够在短期内实现收益和目标突破的

在项目实施过程中需重点投入资源，优先实现，只有在这些需求上达成一致意见，功能才可用和被接受。

这类需求在当前版本必须实现。

一般

满足以下任意一条时：

1）对正常业务影响程度不大

2）需求实现的紧急程度为普通

3）支持必要的系统操作，实现这些需求将增强系统整体的用户满意度和加大竞争胜算，用户反馈建议添加的

此类需求必须被实现，但如果项目实施中出现进度、资源等方面的冲突时，若有必要，可以延迟到下一版本；需要付出努力，但不必做得太完美。

延缓

满足以下任意一条时：

1）功能或质量上的附加功能；

2）实现这些需求，会使系统整体上更显完美，若不实现也不影响系统功能与性能，属于锦上添花，增强用户体验的部分；

3）需求实现的紧急程度为建议；

实现或不实现均可；可以在项目组有足够的时间时考虑这些需求的实现

优先级的定义有利于帮助项目组在项目的范围、进度、资源、预算等相关制约因素之间产生冲突时，正确地对需求实现的范围或实现的优先程度做出取舍。

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

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

●功能介绍：

描述需求功能的用途和提出背景；

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

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

●功能的具体需求说明；

●UE图。

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

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

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

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

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

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

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

提醒：

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

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

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

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

6.2.1需求评审

评审的目的在于：

使需求文档达到易读、无歧义、一致、必要、完整、可实现、可验证。

需求受理人（一般为部门总监，各个地区分站由技术中心受理）对提交的需求文档进行初审通过后，由技术中心组织和安排需求的评审工作：

确定评审时间、地点、评审人员和其他参加人员。

至少应包含以下成员：

●评审组长：

CEO、技术总监；

●评审成员：

产品经理、程序员及其他相关人员；

●输入：

《立项需求说明书》初稿

●输出：

《评审结果报告》

当需求文档评审通过后，程序方和需求提出方应须进行书面签字确认，使之生效。

之后若需要调整需求，则须走需求变更控制流程。

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

经书面确认的需求开发，若发生预期需求与开发实现的功能不一致而影响开发质量的，责任归属界定：

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

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

6.2.2产品宣讲

产品宣讲的目的在于：

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

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

●程序负责人、程序员与需求发起人

●输入：

《需求功能白皮书》及《产品原型》

●输出：

《任务进度表》

6.3需求变更

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

这主要有以下几种原因：

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

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

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

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

需求变更的影响：

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

只有当需求变更带来的好处大于坏处时，变更需求才是有意义的，但也须遵循变更控制流程：

申请→审批→执行；如果需求变更带来的坏处大于好处，则应拒绝变更。

需求受理人应适当拒绝一些不合理的变更。

如：

提出的变更不是由于程序方的过错引起的，此变更可能造成程序方占用额外的资源或成本，而需求方又不愿给出额外资源对变更进行处理等。

变更控制流程如图所示，主要包括：

变更申请、评审和审批、填写执行记录。

6.3.1变更申请

在开发过程中，所有人员均可提出变更申请，但必须说明“变更内容和原因”；然后打印出纸质档交由相关项目的经理核实。

6.3.2变更评审及审批

将经过项目经理核实的申请依次提交给需求受理部门经理/总监进行审批。

年度重点任务的页面设计需求需要由总裁确认，以确保需求的正确性、完整性和合理性。

对于项目的技术方案、进度、质量、成本会产生重大影响的变更申请，需求受理人无法单独做出决定时，应召开变更评审会议，并由评审人员填写评审意见，上级领导审批。

6.3.3执行变更

经审批同意变更后，由部门经理根据情况安排人员和时间执行变更工作，并调整任务计划表，通知项目成员和受变更影响的相关人员，将《变更申请表》纸质档和电子档提交至技术中心存档备案。

《变更申请表》的模板如下：

变更申请

标题

申请部门

变更类型

【】需求/任务增加【】需求/任务修改【】需求取消【】任务延期【】任务中断

变更原因

提示：

（关于需求内容的增加、修改、取消、延期、中断等都需要进行变更申请）

1.说明变更的原由

2.此变更可能对原计划任务造成的影响

3.此变更可能带来的利益

变更内容

重要级别：

【】重要紧急【】重要不紧急【】紧急不重要【】不重要不紧急

提示：

1.需要变更的具体内容

2.若此变更对原计划任务有影响，必须说明计划任务处理顺序的调整（如：

取消或者延期一部分非重要和非紧急的需求任务）

变更申请人签字

日期：

变更审核

部门总监意见

签字：

日期：

IT总监意见

（月度重点、

季度重点）

签字：

日期：

总裁意见

（年度重点）

签字：

日期：

7.输出

立项阶段输出：

●《立项需求说明书》

●《需求任务表》

产品阶段输出：

●《任务时间计划表》

●《产品原型设计》

●《需求功能白皮书》

8.使用模板

●立项需求说明书

●需求任务表

9.附件：

《商业需求确认书》

商业需求确认书

标题

合同编号

类型

【】新增资讯类频道【】新增垂直化频道【】新增个性化频道

需求原因

提示：

1.此需求原因

2.此需求跟现有网站的不同与影响

3.此需求可能带来的利益

需求内容

重要级别：

【】重要紧急【】重要不紧急【】紧急不重要【】不重要不紧急

提示：

3.需求的具体内容

4.若此需求对原计划任务有影响，必须说明计划任务处理顺序的调整

需求申请人签字

日期：

变更审核

市场总监意见

签字：

日期：

总裁意见

签字：

日期：

《程序需求表》的模板如下：

程序需求表

标题

申请部门

需求原因

提示：

1.此需求原因

2.此需求跟现有网站的不同与影响

3.此需求可能带来的利益

需求内容

重要级别：

【】重要紧急【】重要不紧急【】紧急不重要【】不重要不紧急

提示：

1.需要修改的具体内容

2.若此变更对原计划任务有影响，必须说明计划任务处理顺序的调整

需求申请人签字

日期：

变更审核

部门总监意见

签字：

日期：

IT总监意见

（月度重点、

季度重点）

签字：

日期：

总裁意见

（年度重点）

签字：

日期：