需求开发流程管理规定

专业资料

需求开发流程管理规定

1. 目的

通过需求开发流程的规定，规公司软件项目的需求开发和管理活动，提高需求质量，降低开发成 本，改进系统质量。

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

2. 围

适用于公司各软件开发项目及已经通过 《用户需求确认书》的项目，如未通过《用户需求确认书》

技术中心暂时无法参与需求立项，评审，分析等流程。附件一： 《用户需求确认书》

3. 释义

术语或缩略语 解释

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

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

4. 流程图

需求管理流程

图1需求开发流程图提出需求 需求立项阶段 产品阶段 开发阶

需求提出人 收集需4’ -------------- N-

rfz 1

需求整理N Z±± °

提交需求：

需求受理人 -需求评审会

信息中心

外包软件商 原型设计

度表

开发流程］ :初审通过

I _._ __________

商业价值评

讲

析

计 产品 任务进

安排任

指定负 专业资料

5. 主要活动

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

需求管理的目的是在需求与程序组之间建立对需求的共同认识和理解， 维护需求与程序开发成果

的一致性，并控制需求的变更。 需求管理的主要活动包括： 需求评审确认、需求变更、需求跟踪控

制。

5.1需求定义

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

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

5.1.1标识需求与命名规则

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

［需求年月］-［项目类别］-［用途类别］

女口， 201310-TMS项目-运单打印需求；

5.1.2需求分类

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

分类规则 具体类别

按项目分类 TMS项目

NC项目 OA项目 其他项目

按用途分类 界面需求 二次开发 系统功能升级 系统性能优化

其他功能需求

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

5.1.3需求优先级

需求分析员应确定每个需求的优先级，需求的优先级判定标准如下: 专业资料

级别定义 判断标准 采取的措施

优先 满足以下任意一条时：

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

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

3） 能够在短期实现收益和目标突破的 在项目实施过程中需重点投入资源，优先实 现，只有在这些需求上达成一致意见， 功能才

可用和被接受。

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

一般 满足以下任意一条时：

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

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

3） 支持必要的系统操作，实现这些需求将增强 系统整体的用户满意度和加大竞争胜算，用 户反馈建议添加的 此类需求必须被实现，但如果项目实施中岀现 进度、资源等面的冲突时，若有必要，可以延 迟到下一版本；需要付岀努力，但不必做得太 宀¥

完美。

延缓 满足以下任意一条时：

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

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

3） 需现的紧急程度为建议； 实现或不实现均可；可以在项目组有足够的时 间时考虑这些需求的实现

优先级的定义有利于帮助项目组在项目的 围、进度、资源、预算等相关制约因素之间产生冲突时,

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

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

在需求收集后，需求受理人应根据需求收集得到的记录与资料，整理编写 《立项需求说明书》

其主要容应该包括但不局限于：

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

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

功能的具体需求说明。

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

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

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

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

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

确保所描述的需求可以通过适当的手段得到验证，即需求的可测试性； 考虑了各个层次的需求影响，确定了需求的优先级，以确保需求的可行性。

提醒：对于版面调整、活动等不需要做过多业务流程更改的需求，采用《程序需求表》进行填写。

5.2需求评审确认及开发流程

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

成共识。

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

521需求评审

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

需求受理人（一般为部门总监，各个地区分站由技术中心受理）对提交的需求文档进行初审通过

后，由信息技术中心组织和安排需求的评审工作：确定评审时间、地点、评审人员和其他参加人员。 至少应包含以下成员：

评审组长：总裁及总裁办相关领导、信息技术总监；

评审成员：项目经理、程序员及其他相关人员；

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

输出：《评审结果报告》

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

整需求，则须走需求变更控制流程。

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

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

A.因需求不明确、阐述遗漏、描述错误等，且后期没有对应的需求变更记录备案，而造成实现

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

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

5.3需求变更

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

这主要有以下几种原因：

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

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

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

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

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

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

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

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

531变更申请

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

532变更评审及审批

将经过项目经理核实的申请依次提交给需求受理信息技术中心 /总监进行审批。

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

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

533执行变更

经审批同意变更后，由信息技术中心根据情况安排人员和时间执行变更工作，并调整任务计划

表，通知项目成员和受变更影响的相关人员，将 《变更申请表》 纸质档和电子档提交至信息技术中心

存档备案。

《变更申请表》 的模板如下: ；然后打印出纸质文 专业资料

变更申请

标题 申请部门

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

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

1. 说明变更的原由

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

3. 此变更可能带来的影响

变更内容 重要级别： 【】重要紧急 【】重要不紧急 【】紧急不重要 【】不重要不紧急

提示：

1. 需要变更的具体内容

2. 若此变更对原计划任务有影响，必须说明计划任务处理顺序的调整（如：取消或者延期一 分非重要和非紧急的需求任务）

变更申请人签字 日期：

变更审核

部门意见

签字： 日期:

信息中心意见

（月度重点、

季度重点） 签字： 日期：

总裁办意见

（年度重点） 签字： 日期：

输出

立项阶段输出：

《需求任务表》 产品阶段输出： 《任务时间计划表》

6. 使用模板

立项需求说明书 需求任务表

7. 附件:

《用户需求确认书》