银行信息系统应用需求管理办法模版Word文件下载.docx

上传人:b****0 文档编号:12950108 上传时间:2022-10-01 格式:DOCX 页数:6 大小:13.42KB
下载 相关 举报
银行信息系统应用需求管理办法模版Word文件下载.docx_第1页
第1页 / 共6页
银行信息系统应用需求管理办法模版Word文件下载.docx_第2页
第2页 / 共6页
银行信息系统应用需求管理办法模版Word文件下载.docx_第3页
第3页 / 共6页
银行信息系统应用需求管理办法模版Word文件下载.docx_第4页
第4页 / 共6页
银行信息系统应用需求管理办法模版Word文件下载.docx_第5页
第5页 / 共6页
点击查看更多>>
下载资源
资源描述

银行信息系统应用需求管理办法模版Word文件下载.docx

《银行信息系统应用需求管理办法模版Word文件下载.docx》由会员分享,可在线阅读,更多相关《银行信息系统应用需求管理办法模版Word文件下载.docx(6页珍藏版)》请在冰豆网上搜索。

银行信息系统应用需求管理办法模版Word文件下载.docx

第二章信息系统应用需求的提出和受理

第四条设立需求管理岗,统一受理全行各部门的信息系统应用需求。

其他技术岗位不直接接收信息系统需求。

第五条不直接接受各分支机构提出的软件产品开发、功能升级等需求。

确有必要,各分支机构必须先向总行相关业务管理部门提出需求,并经业务管理部门审核批准后,再由业务管理部门向提出需求。

第六条可以根据系统运行的需要,并结合运行维护人员的信息统计和反馈,自行制定系统优化、功能变更、功能升级等方面的需求,并告知总行各业务管理部门或经过总行业务管理部门审核后实施。

第七条各部门提出信息系统需求时,须指定一名与所提需求相关工作经验丰富的经办人,该经办人具体负责详细需求的拟定、联络、协调与验收等相关工作。

第八条各部门提出信息系统需求时,需填写《软件开发/维护业务需求书(主件部分)》(附件1)。

主件主要体现审批、审核内容,为固定表格形式,所有软件产品开发需求必须提供该主件。

附件部分主要描述客户对系统、产品的目标要求,附件内容应尽可能做到明确、具体。

第三章信息系统应用需求的分类

第九条需求管理人员受理需求之后,负责将需求分类管理。

信息系统应用需求分为:

生产问题改进类需求、功能升级类需求和新产品开发类需求。

第十条本办法适用的生产问题改进类需求范围为:

(一)在已投产系统使用中发现的生产缺陷问题;

(二)在已投产系统使用中总结的有利于经营管理改进的建议;

(三)在已投产系统使用中经相关风险管理部门提出需要修改的风险提示建议;

(四)认为有必要归为此类的需求。

第十一条本办法适用的功能升级类需求范围为:

(一)需要改造关键信息系统系统的公用模块或重要模块的需求;

(二)需要改造涉及关键信息系统之间或关键信息系统系统与第三方系统接口的需求;

(三)需要改造涉及两套以上系统的需求;

(四)项目开发评估工作量在一个人月以上的需求;

(五)认为有必要归为此类的需求。

第十二条本办法适用的新产品类需求范围为:

(一)需要新建应用系统的需求;

(二)需要在已投产系统中增加重大产品功能的需求;

(三)认为有必要归为此类的需求。

第十三条本办法涉及的关键信息系统系统范围为:

(一)核心业务系统;

(二)综合大前置系统;

(三)数据中心报表系统。

第四章信息系统应用需求的分析

第十四条对各部门提交的信息系统需求,原则上按需求提交的先后顺序处理。

领导可以根据需求内容的重要程度合理地调配需求处理进度。

第十五条需求受理人员应认真进行需求分析,对于需求不够明确的应及时与需求提出部门沟通、确认。

需求提出部门应落实人员,密切配合进行需求分析,负责解释需求内容,努力防止对业务需求的误解。

在业务需求有异议时,应负责确定出准确的解决方案。

第十六条生产问题改进类需求由需求管理人员转交给相关开发人员;

功能升级类需求和新产品开发类需求在需求分析结束之后,应填写《软件产品需求分析表》(附件2)。

第十七条需求分析结束后,需求受理人员应联系相关人员评估实现该需求的工作量。

第十八条新产品类需求处理过程中,需求受理人员应联系架构安全人员做好项目架构安全的评估工作。

第十九条信息系统需求处理过程中,需求提出部门对已提交的需求需要变更的,应收回原有的需求,重新提交新的需求。

第五章信息系统应用需求的评审

第二十条本办法适用的需求评审范围为:

(一)新产品类需求;

(二)需求分析过程中,各方无法达成一致的需求;

(三)需求涉及两套及两套以上关键系统的需求。

第二十一条需求评审人员由相关领导、各科室主管、需求分析人员、架构安全人员及相关技术人员组成。

第二十二条需求管理岗负责组织实施需求评审工作,评审会议的内容从需求背景、需求内容、技术实现可行性及风险等几方面展开,需求评审过程中,应指定相关人员做好会议纪录,评审结束后形成需求《评审表》(附件3)。

第二十三条需求评审过程中,相关人员可对评审内容提出具体意见,对于评审过程中提出的分歧意见或需要进一步确定需求内容的,需求管理人员负责跟踪解决方案,并提交下次需求评审会议审议。

第六章信息系统应用需求的下发和跟踪

第二十四条需求评审会议结束两个工作日后,无反馈意见的,需求管理人员负责提交给主管需求的领导签字。

第二十五条信息系统需求处理结束后,需求受理人员负责将结果反馈至需求部门经办人。

第七章附则

第二十六条本办法由总行负责制定、解释与修订。

第二十七条本办法自公布之日起实施。

附件:

1.《软件开发/维护业务需求书(主件部分)》

2.《软件产品需求分析表》

3.《评审表》

附件1.《软件开发/维护业务需求书(主件部分)》

软件开发/维护业务需求书(主件部分)

业务部门填写栏

需求名称

 

部门来源

提交日期

功能描述

需求附件

需求联系人

姓名

电话

需求部门签字盖章:

业务管理部门意见(如牵涉账务分录请业务部室签属意见)

需求部门主管行长签字:

科技部门填写栏

需求受理人员

需求类别

科技部门签字:

□生产问题改进类

□功能升级类

□新产品开发类

附件2.《软件产品需求分析表》

软件产品需求分析表

需求编号

□新产品需求□重大功能升级

开发模式

□自主开发□合作开发□外包开发

功能归属

□核心业务系统软件(K)□管理业务系统软件(M)

□外围业务系统软件(P)□网络及通讯安全软件(N)

复杂程度

□复杂(A)□一般(B)□简单(C)

项目实施

预估工作量

(需求涉及系

统较多时,需

分系统填写)

项目架构安全评估及注意事项(新产品类需求转交网络安全人员填写)

需求管理岗签名

备注

附件3.《评审表》

评审表

编号

名称

负责人

评审日期

评审人员(签名)

被评审内容

评审意见

评审意见执行情况

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 医药卫生 > 药学

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1