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

，
4. 流程图
图1：需求开发流程图
5. 主要活动
需求定义的目的是需求提出人通过收集、调查与分析，获取用户业务需求并定义需求。

需求定义的主要活动包括：需求收集、需求分析&定义。

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

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

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

5.1.3 需求优先级
需求分析员应确定每个需求的优先级，需求的优先级判定标准如下：
●确保所描述的需求可以通过适当的手段得到验证，即需求的可测试性；
●考虑了各个层次的需求影响，确定了需求的优先级，以确保需求的可行性。

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

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

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

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

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

至少应包含以下成员：
●评审组长：总裁及总裁办相关领导、信息技术总监；
●评审成员：项目经理、程序员及其他相关人员；
●输入：《立项需求说明书》初稿
●输出：《评审结果报告》
当需求文档评审通过后，程序开发方和需求提出方应须进行书面签字确认，使之生效。

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

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

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

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

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

这主要有以下几种原因：
1. 系统所应用的外部环境发生变化；
2. 随着对软件的熟悉和应用，又提出新的需求；
3. 进行需求分析时未能彻底分析原始需求，或分析错误；
4.在开始时不能很全面的知道所需软件的功能。

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

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

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

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

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

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

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

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

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

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

《变更申请表》的模板如下：
●立项需求说明书
●需求任务表
7. 附件：《用户需求确认书》。