业务需求管理规定

《业务需求管理规定》由会员上传分享，免费在线阅读，更多相关内容在工程资料-天天文库。

1、文档编号:业务需求管理办法（试行稿）2010-03修订文档历史记录日期版本说明作者1.目的及定义第一条为规范信息系统业务需求的提出、变更及维护管理，保障信息系统开发、测试、上线及运行管理等工作的顺利进行,特制定本规定；第二条本规定适用于所有业务信息化项目的需求分析阶段；第三条定义：1、业务需求：需要在公司信息系统平台中实现的、包括整个项目范围内的业务功能说明或描述。2、业务需求部门：为公司信息系统提出所要实现功能（即业务需求）的部门，包括各业务部门、技术部门、综合行政部门等部门。3、业务需求承接部门：承接业务需求的部门，目前为数据信息部。4、业务需求的重要程度：业务需求部门所需业务功能对

2、整体业务系统影响程度，可分为非常重要、重要和一般三个级别，非常重要为最高级别。a）非常重要：业务系统所需的该项功能对整体业务系统影响非常大，如该需求为关键流程的关键环节说明等；b）重要：业务系统所需的该项功能对整体业务系统影响大；C）一般：业务系统所需的该项功能对整体业务系统影响一般，如页面显示文字、字体、颜色等。5、业务需求的紧急程度：业务需求部门所需业务功能的急迫程度，可分为非常紧急、紧急和一般三个级别，非常紧急为最高级别。a）非常紧急：业务系统所需的该项功能非常急迫，如不尽快实现，关键业务流程不能被正确执行、且无可替代措施；b）紧急：业务系统所需的该项功能比较急迫，如不尽快实现，业

3、务流程不能被正确执行，但存在可替代措施或方法；C）一般：业务系统所需的该项功能急迫性一般，不会对业务流程存在较大影响。6、业务需求的粗细粒度：业务需求部门所需业务功能的粗细程度，一般情况下粒度越细越好。7、业务需求的版本管理：数据信息部对业务需求以时间为基线实行版本管理。在业务需求文档中，会明确业务需求的紧急程度、重要程度，并尽量细化需求。一般情况下，以三周为时限发布一个版本。1.业务需求的提出第四条业务需求部门通过“业务需求任务书”向数据信息部提出业务需求，详细填写项目需求信息，并经部门领导审批通过，必要时由公司分管领导、董事长审批。若为首次提出需求、需要进行系统软件开发，则需要部门领

4、导、公司分管领导、董事长审批通过；第五条“业务需求任务书”（附件1）用于说明书项目业务需求，为更加清楚地说明业务需求，可附带附件、附图、附表等文档；第六条业务需求粒度应尽量细小；第七条提出业务需求时应说明业务需求的重要程度和紧急程度；第八条提出业务需求时应认真考虑业务需求的合理性、完整性和前瞻性，充分考虑各种流程、各个环节以及异常流程的处理；第九条当期未提出的业务需求在交付开发前可以提出变更，若已交付开发须纳入下一版本；1.业务需求的变更第十条在当期业务需求交付开发前业务需求部门可以对需求进行变更，可通过“业务需求变更说明书”向数据信息部提出业务需求变更说明，详细填写项目问题、需求变更内

5、容等信息，并经部门领导审批通过。必要时须由公司分管领导审批通过；第十一条“业务需求变更说明书”（附件2）用于项目业务需求提出后的需求变更，为更加清楚地说明业务需求变更情况,可附带附件、附图等文档；第十二条提出业务需求变更时应说明业务需求的重要程度和紧急程度。若为重大变化，则需要董事长进行审批；第十三条提出业务需求变更时应说明对应的业务需求任务书的编号；第十四条若当期业务需求已交付开发，不可对业务需求进行变更，只能纳入下一期版本；1.业务需求的版本管理第十五条数据信息部接到业务需求部门的“业务需求任务书”后,将组织业务需求分析工程师、设计工程师、开发工程师编制“系统需求规格说明书”并进行版

6、本管理和控制，必要时将组织相关人员进行系统需求评审；第十六条数据信息部以时间为基线对业务需求进行规划，在当前时间内的业务需求称为“当期业务需求”；第十七条数据信息部须维护业务需求版本，保持“业务需求任务书”、“系统需求规格说明书”、“系统设计报告”、“软件代码”、“系统测试报告”、“系统部署说明书”、“数据库脚本”、“系统缺陷报告”、“系统使用手册”、“培训手册”等相关文档的版本一致性；第十八条一般情况下，信息系统每月5日、20日各发布一次完整版本。紧急情况下，需按紧急发布流程进行发布；2.本规定的执行第十九条本规定自发布之日起执行;第二十条本规定由数据信息部负责解释。1.附件a）附件1

7、:业务需求任务书b）附件2：业务需求变更说明书