业务需求管理规定.doc

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