文档编号：
业务需求管理办法
（试行稿）
2010-03
修订文档历史记录
1. 目的及定义
第一条 为规范信息系统业务需求的提出、变更及维护管理，保障
信息系统开发、测试、上线及运行管理等工作的顺利进行，特制定本规定；
第二条 本规定适用于所有业务信息化项目的需求分析阶段；
第三条
定义： 、 业务需求：需要在公司信息系统平台中实现的、包括整个项目范围内的业务功能说明或描述。 、 业务需求部门：为公司信息系统提出所要实现功能（即业务需求）的部门，包括各业务部门、技术部门、综合行政部门等部门。 、 业务需求承接部门：承接业务需求的部门，目前为数据信息部。 、 业务需求的重要程度：业务需求部门所需业务功能对整体业务系统影响程度，可分为非常重要、重要和一般三个级别，非常重要为最高级别。 a) 非常重要：业务系统所需的该项功能对整体业务系统影响非常大，如该需求为关键流程的关键环节说明等； b) 重要：业务系统所需的该项功能对整体业务系统影响大； c) 一般：业务系统所需的该项功能对整体业务系统影1234
响一般，如页面显示文字、字体、颜色等。
5、 业务需求的紧急程度：业务需求部门所需业务功能的急迫程度，可分为非常紧急、紧急和一般三个级别，非
常紧急为最高级别。
a) 非常紧急：业务系统所需的该项功能非常急迫，如
不尽快实现，关键业务流程不能被正确执行、且无
可替代措施；
b) 紧急：业务系统所需的该项功能比较急迫，如不尽
快实现，业务流程不能被正确执行，但存在可替代
措施或方法；
c) 一般：业务系统所需的该项功能急迫性一般，不会
对业务流程存在较大影响。
6、 业务需求的粗细粒度：业务需求部门所需业务功能的粗细程度，一般情况下粒度越细越好。
7、 业务需求的版本管理：数据信息部对业务需求以时间为基线实行版本管理。在业务需求文档中，会明确业务
需求的紧急程度、重要程度，并尽量细化需求。一般情
况下，以三周为时限发布一个版本。
2. 业务需求的提出
第四条 业务需求部门通过“业务需求任务书”向数据信息部提出
业务需求，详细填写项目需求信息，并经部门领导审批通过，必要时由公司分管领导、董事长审批。若为首次提出
需求、需要进行系统软件开发，则需要部门领导、公司分管领导、董事长审批通过；
第五条 “业务需求任务书”（附件1）用于说明书项目业务需求，
为更加清楚地说明业务需求，可附带附件、附图、附表等文档；
第六条 业务需求粒度应尽量细小；
第七条 提出业务需求时应说明业务需求的重要程度和紧急程度；
第八条 提出业务需求时应认真考虑业务需求的合理性、完整性和
前瞻性，充分考虑各种流程、各个环节以及异常流程的处理；
第九条 当期未提出的业务需求在交付开发前可以提出变更，若已
交付开发须纳入下一版本；
3. 业务需求的变更
第十条 在当期业务需求交付开发前业务需求部门可以对需求进行
变更，可通过“业务需求变更说明书”向数据信息部提出业务需求变更说明，详细填写项目问题、需求变更内容等信息，并经部门领导审批通过。必要时须由公司分管领导审批通过；
第十一条 “业务需求变更说明书”（附件2）用于项目业务需求
提出后的需求变更，为更加清楚地说明业务需求变更情况，可附带附件、附图等文档；
第十二条 提出业务需求变更时应说明业务需求的重要程度和紧
急程度。若为重大变化，则需要董事长进行审批；
第十三条 提出业务需求变更时应说明对应的业务需求任务书的
编号；
第十四条 若当期业务需求已交付开发，不可对业务需求进行变
更，只能纳入下一期版本；
4. 业务需求的版本管理
第十五条 数据信息部接到业务需求部门的“业务需求任务书”后，
将组织业务需求分析工程师、设计工程师、开发工程师编制“系统需求规格说明书”并进行版本管理和控制，必要时将组织相关人员进行系统需求评审；
第十六条 数据信息部以时间为基线对业务需求进行规划，在当前
时间内的业务需求称为“当期业务需求”；
第十七条 数据信息部须维护业务需求版本，保持“业务需求任务
书”、“系统需求规格说明书”、“系统设计报告”、“软件代码”、“系统测试报告”、“系统部署说明书”、“数据库脚本”、“系统缺陷报告”、“系统使用手册”、“培训手册”等相关文档的版本一致性；
第十八条 一般情况下，信息系统每月5日、20日各发布一次完
整版本。紧急情况下，需按紧急发布流程进行发布；
5. 本规定的执行
第十九条 本规定自发布之日起执行；
第二十条 本规定由数据信息部负责解释。
6. 附件
a) 附件1：业务需求任务书
b) 附件2：业务需求变更说明书
c) 附件3：业务需求管理过程示意图
文档编号：
业务需求管理办法
（试行稿）
2010-03
修订文档历史记录
1. 目的及定义
第一条 为规范信息系统业务需求的提出、变更及维护管理，保障
信息系统开发、测试、上线及运行管理等工作的顺利进行，特制定本规定；
第二条 本规定适用于所有业务信息化项目的需求分析阶段；
第三条
定义： 、 业务需求：需要在公司信息系统平台中实现的、包括整个项目范围内的业务功能说明或描述。 、 业务需求部门：为公司信息系统提出所要实现功能（即业务需求）的部门，包括各业务部门、技术部门、综合行政部门等部门。 、 业务需求承接部门：承接业务需求的部门，目前为数据信息部。 、 业务需求的重要程度：业务需求部门所需业务功能对整体业务系统影响程度，可分为非常重要、重要和一般三个级别，非常重要为最高级别。 a) 非常重要：业务系统所需的该项功能对整体业务系统影响非常大，如该需求为关键流程的关键环节说明等； b) 重要：业务系统所需的该项功能对整体业务系统影响大； c) 一般：业务系统所需的该项功能对整体业务系统影1234
响一般，如页面显示文字、字体、颜色等。
5、 业务需求的紧急程度：业务需求部门所需业务功能的急迫程度，可分为非常紧急、紧急和一般三个级别，非
常紧急为最高级别。
a) 非常紧急：业务系统所需的该项功能非常急迫，如
不尽快实现，关键业务流程不能被正确执行、且无
可替代措施；
b) 紧急：业务系统所需的该项功能比较急迫，如不尽
快实现，业务流程不能被正确执行，但存在可替代
措施或方法；
c) 一般：业务系统所需的该项功能急迫性一般，不会
对业务流程存在较大影响。
6、 业务需求的粗细粒度：业务需求部门所需业务功能的粗细程度，一般情况下粒度越细越好。
7、 业务需求的版本管理：数据信息部对业务需求以时间为基线实行版本管理。在业务需求文档中，会明确业务
需求的紧急程度、重要程度，并尽量细化需求。一般情
况下，以三周为时限发布一个版本。
2. 业务需求的提出
第四条 业务需求部门通过“业务需求任务书”向数据信息部提出
业务需求，详细填写项目需求信息，并经部门领导审批通过，必要时由公司分管领导、董事长审批。若为首次提出
需求、需要进行系统软件开发，则需要部门领导、公司分管领导、董事长审批通过；
第五条 “业务需求任务书”（附件1）用于说明书项目业务需求，
为更加清楚地说明业务需求，可附带附件、附图、附表等文档；
第六条 业务需求粒度应尽量细小；
第七条 提出业务需求时应说明业务需求的重要程度和紧急程度；
第八条 提出业务需求时应认真考虑业务需求的合理性、完整性和
前瞻性，充分考虑各种流程、各个环节以及异常流程的处理；
第九条 当期未提出的业务需求在交付开发前可以提出变更，若已
交付开发须纳入下一版本；
3. 业务需求的变更
第十条 在当期业务需求交付开发前业务需求部门可以对需求进行
变更，可通过“业务需求变更说明书”向数据信息部提出业务需求变更说明，详细填写项目问题、需求变更内容等信息，并经部门领导审批通过。必要时须由公司分管领导审批通过；
第十一条 “业务需求变更说明书”（附件2）用于项目业务需求
提出后的需求变更，为更加清楚地说明业务需求变更情况，可附带附件、附图等文档；
第十二条 提出业务需求变更时应说明业务需求的重要程度和紧
急程度。若为重大变化，则需要董事长进行审批；
第十三条 提出业务需求变更时应说明对应的业务需求任务书的
编号；
第十四条 若当期业务需求已交付开发，不可对业务需求进行变
更，只能纳入下一期版本；
4. 业务需求的版本管理
第十五条 数据信息部接到业务需求部门的“业务需求任务书”后，
将组织业务需求分析工程师、设计工程师、开发工程师编制“系统需求规格说明书”并进行版本管理和控制，必要时将组织相关人员进行系统需求评审；
第十六条 数据信息部以时间为基线对业务需求进行规划，在当前
时间内的业务需求称为“当期业务需求”；
第十七条 数据信息部须维护业务需求版本，保持“业务需求任务
书”、“系统需求规格说明书”、“系统设计报告”、“软件代码”、“系统测试报告”、“系统部署说明书”、“数据库脚本”、“系统缺陷报告”、“系统使用手册”、“培训手册”等相关文档的版本一致性；
第十八条 一般情况下，信息系统每月5日、20日各发布一次完
整版本。紧急情况下，需按紧急发布流程进行发布；
5. 本规定的执行
第十九条 本规定自发布之日起执行；
第二十条 本规定由数据信息部负责解释。
6. 附件
a) 附件1：业务需求任务书
b) 附件2：业务需求变更说明书
c) 附件3：业务需求管理过程示意图