业务需求管理规定.docVIP

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