银行信息系统应用需求管理办法模版.doc

《银行信息系统应用需求管理办法模版.doc》由会员分享，可在线阅读，更多相关《银行信息系统应用需求管理办法模版.doc（11页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、信息系统应用需求管理办法编制部门： 版 次 号： 生效日期：xx年06月01日目 录修改与审批记录3第一章总则4第二章信息系统应用需求的提出和受理4第三章信息系统应用需求的分类5第四章信息系统应用需求的分析6第五章信息系统应用需求的评审7第六章信息系统应用需求的下发和跟踪7第七章附则8附件：8附件1.软件开发/维护业务需求书（主件部分）9附件2.软件产品需求分析表10附件3.评审表11第一章 总则第一条 为统一银行（以下简称“本行”）各部门的信息系统应用需求，防范信息系统风险，合理调配信息技术资源，确保信息系统需求的实现，根据银行信息科技管理基本制度，特制定本办法。第二条 本办法中所称信息系统

2、应用需求，是指全行各部门、各分支机构在日常经营管理活动中需要涉及信息系统程序开发、功能升级、数据处理、查询统计等各类需要信息技术人员支持的需求。第三条 负责受理并为各部门、各分支机构的信息系统需求提供技术支持。第二章 信息系统应用需求的提出和受理第四条 设立需求管理岗，统一受理全行各部门的信息系统应用需求。其他技术岗位不直接接收信息系统需求。第五条 不直接接受各分支机构提出的软件产品开发、功能升级等需求。确有必要，各分支机构必须先向总行相关业务管理部门提出需求，并经业务管理部门审核批准后，再由业务管理部门向提出需求。第六条 可以根据系统运行的需要，并结合运行维护人员的信息统计和反馈，自行制定系

3、统优化、功能变更、功能升级等方面的需求，并告知总行各业务管理部门或经过总行业务管理部门审核后实施。第七条 各部门提出信息系统需求时，须指定一名与所提需求相关工作经验丰富的经办人，该经办人具体负责详细需求的拟定、联络、协调与验收等相关工作。第八条 各部门提出信息系统需求时，需填写软件开发/维护业务需求书（主件部分）（附件1）。主件主要体现审批、审核内容，为固定表格形式，所有软件产品开发需求必须提供该主件。附件部分主要描述客户对系统、产品的目标要求，附件内容应尽可能做到明确、具体。第三章 信息系统应用需求的分类第九条 需求管理人员受理需求之后，负责将需求分类管理。信息系统应用需求分为：生产问题改进

4、类需求、功能升级类需求和新产品开发类需求。第十条 本办法适用的生产问题改进类需求范围为：（一） 在已投产系统使用中发现的生产缺陷问题；（二） 在已投产系统使用中总结的有利于经营管理改进的建议；（三） 在已投产系统使用中经相关风险管理部门提出需要修改的风险提示建议；（四） 认为有必要归为此类的需求。第十一条 本办法适用的功能升级类需求范围为：（一） 需要改造关键信息系统系统的公用模块或重要模块的需求；（二） 需要改造涉及关键信息系统之间或关键信息系统系统与第三方系统接口的需求；（三） 需要改造涉及两套以上系统的需求；（四） 项目开发评估工作量在一个人月以上的需求；（五） 认为有必要归为此类的需求

5、。第十二条 本办法适用的新产品类需求范围为：（一） 需要新建应用系统的需求；（二） 需要在已投产系统中增加重大产品功能的需求；（三） 认为有必要归为此类的需求。第十三条 本办法涉及的关键信息系统系统范围为：（一） 核心业务系统；（二） 综合大前置系统；（三） 数据中心报表系统。第四章 信息系统应用需求的分析第十四条 对各部门提交的信息系统需求，原则上按需求提交的先后顺序处理。领导可以根据需求内容的重要程度合理地调配需求处理进度。第十五条 需求受理人员应认真进行需求分析，对于需求不够明确的应及时与需求提出部门沟通、确认。需求提出部门应落实人员，密切配合进行需求分析，负责解释需求内容，努力防止对业

6、务需求的误解。在业务需求有异议时，应负责确定出准确的解决方案。第十六条 生产问题改进类需求由需求管理人员转交给相关开发人员；功能升级类需求和新产品开发类需求在需求分析结束之后，应填写软件产品需求分析表（附件2）。第十七条 需求分析结束后，需求受理人员应联系相关人员评估实现该需求的工作量。第十八条 新产品类需求处理过程中，需求受理人员应联系架构安全人员做好项目架构安全的评估工作。第十九条 信息系统需求处理过程中，需求提出部门对已提交的需求需要变更的，应收回原有的需求，重新提交新的需求。第五章 信息系统应用需求的评审第二十条 本办法适用的需求评审范围为：(一) 新产品类需求；(二) 需求分析过程中

7、，各方无法达成一致的需求；(三) 需求涉及两套及两套以上关键系统的需求。第二十一条 需求评审人员由相关领导、各科室主管、需求分析人员、架构安全人员及相关技术人员组成。第二十二条 需求管理岗负责组织实施需求评审工作，评审会议的内容从需求背景、需求内容、技术实现可行性及风险等几方面展开，需求评审过程中，应指定相关人员做好会议纪录，评审结束后形成需求评审表（附件3）。第二十三条 需求评审过程中，相关人员可对评审内容提出具体意见，对于评审过程中提出的分歧意见或需要进一步确定需求内容的，需求管理人员负责跟踪解决方案，并提交下次需求评审会议审议。第六章 信息系统应用需求的下发和跟踪第二十四条 需求评审会议

8、结束两个工作日后，无反馈意见的，需求管理人员负责提交给主管需求的领导签字。第二十五条 信息系统需求处理结束后，需求受理人员负责将结果反馈至需求部门经办人。第七章 附则第二十六条 本办法由总行负责制定、解释与修订。第二十七条 本办法自公布之日起实施。附件：1.软件开发/维护业务需求书（主件部分）2.软件产品需求分析表3.评审表附件1.软件开发/维护业务需求书（主件部分）软件开发/维护业务需求书(主件部分)业务部门填写栏需求名称部门来源提交日期功能描述需求附件需求联系人姓名电话需求部门签字盖章：业务管理部门意见（如牵涉账务分录请业务部室签属意见）需求部门主管行长签字：科技部门填写栏需求受理人员需求

9、类别科技部门签字：生产问题改进类功能升级类新产品开发类附件2.软件产品需求分析表软件产品需求分析表需求编号需求名称需求类别新产品需求 重大功能升级 开发模式 自主开发 合作开发 外包开发功能归属 核心业务系统软件(K) 管理业务系统软件(M) 外围业务系统软件(P) 网络及通讯安全软件(N)复杂程度 复杂(A) 一般(B) 简单(C)项目实施预估工作量（需求涉及系统较多时，需分系统填写）项目架构安全评估及注意事项（新产品类需求转交网络安全人员填写）需求管理岗签名备注附件3.评审表评审表编 号名 称负 责 人评审日期评 审 人 员 ( 签 名 )被 评 审 内 容评 审 意 见评 审 意 见 执 行 情 况