项目业务需求说明方案个贷系统需求.docx
《项目业务需求说明方案个贷系统需求.docx》由会员分享,可在线阅读,更多相关《项目业务需求说明方案个贷系统需求.docx(17页珍藏版)》请在冰豆网上搜索。
![项目业务需求说明方案个贷系统需求.docx](https://file1.bdocx.com/fileroot1/2022-12/13/8f8d4570-c7f9-4979-b46c-a3e3592ef459/8f8d4570-c7f9-4979-b46c-a3e3592ef4591.gif)
项目业务需求说明方案个贷系统需求
哈尔滨银行信息化建设
全流程信贷系统——个人消费信贷子项目
业务需求说明书
个人金融部
2013年3月12日
文件状态:
[]草稿
[√]正式发布
[]正在修改
文件标识:
当前版本:
1.0
编写人员:
郑诗明
负责部门:
个人金融部
授权人签字:
签署日期:
文档信息
标题
哈尔滨银行信息化建设全流程信贷系统——个人消费信贷子项目业务需求说明书
创建日期
2013年3月12日
打印日期
文件名
存放目录
所有者
作者
郑诗明
修订记录
日期
描述
作者
文档审核/审批
此文档需如下审核。
签署过的审批表将作为附件。
姓名
职务/职称
签名
签名日期
文档分发
此文档将分发至如下各人
姓名
职务/职称
孙兰
信贷管理部总经理助理
王超
个人金融部总经理助理
李俊龙
科技发展部运营维护中心总经理助理
谢天赐
科技发展部北京IT研发中心技术员
陈维克
科技发展部运营维护中心技术员
郑诗明
个人金融部业务人员
陈书宜
信贷管理部业务人员
1引言
1.1读者对象
本文档送达以下相关各方审阅。
日期
姓名
职位和部门
2013-3-12
孙兰
信贷管理部项目负责人
2013-3-12
王超
个人金融部业务经理
2013-3-12
郑诗明
个人金融部业务人员
2013-3-12
李俊龙
科技发展部技术经理
2013-3-12
谢天赐
研发中心人员
2013-3-12
陈维克
运营维护中心人员
2013-3-12
陈书宜
信贷管理部人员
1.2定义及术语
缩写、简称
或其他
定义
1
2
3
4
5
6
7
2概述
个人消费信贷系统是全行使用频率最高的系统之一,目前个人客户多达12万户,每年以10%以上的速度增长,行内使用人员多达300余人,因此,建立全流程信贷系统能够提高我行办公效率和加强内控。
2.1项目背景
以全行全流程信贷系统建设为契机,建立适合我行业务的个人消费贷款系统,在系统上建立自动化的风险控制措施,减少人为干预,从而提高运行效率。
2.2业务目标
随着科技的发展和客户日益多样化的需求,我行原有的信贷系统已经不能满足业务的发展需求,我行需要建立以总行为中心,覆盖全行信贷业务的数据及流程大集中平台,以客户管理为基础、以流程管理为主线、以信贷风险管理及防范为目标,实现全行信贷业务的管理、统计分析、监测、审批、控制的电子化和自动化,提供信贷及相关业务信息的存储、汇总、收集、反映,为各层次的经营管理提供监控、决策、分析、预警等功能,为我行信贷业务的创新、经营决策提供充分的信息支持。
2.3参考资料
主要由德勤专家结合我行需求与同业先进做法而撰写,详见《全流程信贷业务系统个贷业务条线系统需求说明书》。
3业务需求
3.1需求总体描述
本系统的设计及建设不仅要考虑到现在业务处理的操作性和与其它系统的相容性,还要考虑到将来业务的拓展,因而,在系统设计中,主要考虑以下几个方面:
一、使用人员操作的便利性
由于个人消费信贷系统使用的人数多,客户数量大,本系统设计时充分考虑到了这一点,在保证功能的同时,尽量减少信贷人员信息录入的时间,提高效率。
二、满足业务创新需求
由于个人消费贷款业务发展速度,一些新的功能和计息方式会增加,系统建成后,应该能够满足二次开发或添加新功能的需求。
三、提供了强大的分析功能和风险管理功能
本系统不仅能满足全部业务处理的需要,而且应提供了强大的统计分析功能和风险管理功能,包括统计功能、风险预警功能、不良资产管理功能、贷款五级分类功能和资信评估功能等。
3.2
业务处理流程说明
3.3与其他系统交互关系
一、与我行核心系统对接,完成账务处理。
二、与我行数据平台对接,提供业务数据。
三、通过数据平台,与我行其它系统对接,如:
征信系统、会计管理系统、资产负债系统。
四、与我行网络银行对接,完成贷款信息的查询。
五、个贷子系统的客户信息与ECIF进行对接,由ECIF对全行客户信息进行统一管理,并通过系统间实时/非实时接口对客户信息进行同步。
六、与影像平台的对接。
实现客户信息的上传,更新,查询,展示与归档。
并且支持对影像资料更新记录的展示。
七、与房产评估系统对接。
八、与ODS对接。
3.4目标用户
系统建成后,主要由总分行的管理人员和分支行的信贷员使用,2013年建成后,使用人员在300人左右,未来三年会以每年15%的递增速度增加用户数量。
4业务需求细化说明
系统功能描述
序号
模块
功能
备注
1
客户管理
1、客户信息录入。
客户信息录入应非常全面,包括重要联系人、贷款介绍人等,便于贷款管理。
支持批量信息导入
2、影像存储。
信贷人员将客户的原始材料及我行申请书等纸质材料通过影像系统传输到信贷系统中,形成电子档案,审查及管理人员可以根据客户身份证号码查询客户电子档案)
3、征信实现总对总查询,通过在信贷系统中录入客户姓名、身份证号号码,不用登陆征信查询界面,可以直接查询客户征信。
4、实现在信贷系统对客户身份进行联网核查(通过超链接网址实现)。
5、黑名单制度。
在我行内部形成逾期客户的黑名单,在信贷人员受理客户、录入客户姓名、身份证号码时,系统自动检索客户在我行贷款的还款情况,提示信贷人员。
2
贷款审查、审批
1、建立系统自动审批模型,对于符合条件的客户,实现系统自动审批,减少人工操作,提高我行贷款办理速度。
不使用系统审批时,可以跳过此功能。
2、评分卡,根据信贷员录入的客户基本信息,评分卡自动采集信息,形成打分数据,对于打分卡不能自动采集的数据,信贷人员手工填写打分。
3、分权限审批,不同的审批人有不同的审批权限(金额、利率等)。
3
合同签署、办理抵押
1、支持合同(两种方式)、借据、抵押品凭证打印功能;2、客户提前还款的相关凭证打印功能。
4
放款管理
1、贷款支付选项;2、同一笔贷款分次发放;3、利率管理(生效方式:
次年、次月;根据存款情况;设置浮动利率);4、可以实现美元等主流货币计息及放款的功能。
5
贷后管理
1、贷款录入信息的导出功能;2、催收管理;生成逾期客户信息表;3、提前还款;4、合同变更、5、还款方式变更、6、期限、利率、还款账号变更;7、抵质押物变更;8、借款人及其关系人信息变更。
9、五级分类情况;10、信息通知功能;11、提前还款收费
对于我行特色业务,可支持网银自助还款功能等(如助学贷款)。
6
风险管理
1、诉讼管理、2、核销管理3、风险分类
7
绩效管理
实现客户经理发放贷款所产品的模拟利润以及逾期、不良贷款情况;将贷款绩效与模拟利润、不良贷款挂钩。
8
系统核算
可以实现信贷系统的核算功能。
9
统计查询
1、当年、当月、当日的累投、累收。
2、新发放贷款利率定价情况、收息情况。
10
信息园地
开辟信息交流平台;总分行可以通过此平台交流信息;近期政策发布等;分支行信贷人员的照片、姓名等信息的发布;便于总行及时掌握分行情况。
11
授权管理
根据机构、个人等设置不同的审批权限,分级审批等
5非功能需求
5.1技术平台需求
●符合J2EE技术标准
●满足高并发,大数量的检索
●满足相关附件上传功能。
●可维护性高,健壮性强。
5.2性能要求说明
分类
名称
描述
指标
目标
性能(Performance)
基本性能需求
系统必需满足下列基本性能要求:
-一般点击响应速度不高于x秒
-一般查询响应速度不高于x秒
基本性能
一般点击响应速度不高于5秒;
一般查询响应速度不高于6秒
注册用户数
系统支持的注册用户数:
注册用户数:
XXXXXX
用户处理能力
注册用户数:
1500用户以上
并发用户数
能够同时连接到系统的用户数xxxx
并发用户的数量
系统联机应能支持100个以上的并发大规模交易请求
可扩展性
可扩展性
为了满足业务发展的需要,系统架构能在最小的服务中断和开发成本基础上,支持增长的用户数、更大的数据量等
解决方案是否需要考虑未来的规模扩展(是或否)
是
可用性
界面友好性和易用性
在最少的培训下,最终用户能够正确、快速地使用系统来执行任务的能力
很关键/重要/不需要
很关键
对客户的指引
系统的设计必须提供适当清晰的客户指引帮助客户使用
很关键/重要/不需要
很关键
容错能力
系统使用过程中发生错误时提供明确易懂的出错信息提示
很关键/重要/不需要
很关键
可靠性
最终用户的可用性(除计划停运)
系统有多少时间(包括计划停运时间,但不包括故障时间)对用户可用
小时x天x周
24x7x(一年的周数)
故障率或非计划停运率
预期的使得服务失效的故障频率。
本指标给出系统可靠性的一个度量
故障数量/时间周期
3次/年
一般故障的恢复能力
在故障发生后需要多久服务才能恢复正常
恢复系统到正常运营状态所需的时间
1天之内相应,5天之内恢复正常运行。
果无法在5天内远程解决,须在收到哈尔滨银行到现场服务要求后3天内提供现场支持服务。
严重故障的恢复能力
在故障发生后需要多久服务才能恢复正常
恢复系统到正常运营状态所需的时间
要求1小时内响应,1天之内恢复正常运行。
如果无法在1天内远程解决,须在收到哈尔滨银行到现场服务要求后2天内提供现场支持服务。
重大故障的恢复能力
在故障发生后需要多久服务才能恢复正常
要求30分钟内响应,4小时之内恢复正常运行。
如果无法在4小时内远程解决,须在收到哈尔滨银行到现场服务要求后24个小时内提供现场支持服务。
安全性(Security)
一般安全考虑
系统方案符合所有相关的安全和审计需求。
一般安全考虑
符合我行IT安全要求
知识产权
没有知识产权方面纠纷
知识产权
符合我行制度
合规性
遵守地方法规和行业规定
合规性
符合我行制度
系统流程
系统中仅运行获批的或者受控的任务和流程
系统流程
符合我行制度
身份识别和权限控制机制
所有用户,一旦需要访问受限内容或者专属内容时必需要求身份认证和权限控制
身份识别和权限控制机制
符合我行制度
可维护性
系统管理与维护
系统管理的一致性以及界面的易操作性
用来完全安装、打补丁和升级的补丁及安装工具
需要
•安装
提供安装手册及安装部署知识转移
•安全
提供备份、恢复策略
日志
应用程序常规日志
应用程序需要增加公用的日志模块来提供系统日志
需要
应用程序日志包括在系统运行期间发生的事件,如信息,警告或错误的重要性等。
这些信息被放到特定应用的日志中,能够被管理员直接访问或能够被用户开发的工具处理来生成报表。
需要
性能日志
应用程序需要增加公用日志记录模块来提供性能日志
需要
应用程序需要性能日志开关功能
需要
标准及规范
标准规范
•客户的企业标准(Customer’sSOE)
符合我行制度要求
•开放标准(Openstandards)
符合我行制度要求
•行业标准(IndustryStandards)
符合我行制度要求
•其他标准
符合我行制度要求
5.3硬件要求
●系统运行的硬件环境须满足软件性能的要求。
●测试环境尽量保证与正式投产的运行环境一致。
5.4软件要求
名称
型号
操作系统
支持:
AIX、HP_UX、LINUX、Windows等主流操作系统
数据库
支持:
ORACLE、DB2、SQLSERVER、Informix等主流数据库产品。
应用发布服务器
支持:
Weblogic、Websphere等主流产品。
5.5其他要求
5.5.1数据安全要求
数据安全要求描述信贷管理系统处理、存储、传输信息的内在安全要求。
∙针对不同密级的数据我们建议采用不同的安全保护措施:
∙商业机密数据,采用明文存储,密文传输,并施加数据对象级的访问控制。
∙商业绝密数据,采用密文存储和密文传输。
5.5.2访问管理
访问管理描述对系统的应用功能、数据资源进行授权管理和访问控制的安全要求。
∙系统提供基于角色的应用软件功能访问控制,包括角色定义、角色的权限管理、用户的角色管理等。
∙系统提供基于角色和组织机构的数据对象访问控制能力。
∙用户权限的分配应该遵循最小特权的原则。
5.5.3加密
加密描述信贷管理系统在处理、存储和传输数据时应该采取的加密措施。
5.5.4传输加密
所有的涉密信息在服务器集群的局域网外必须以密文的形式传输。
传输层加密采用SSL协议。
5.5.5存储加密
静态口令需要加密存储。
5.5.6应用核心安全事件的审计跟踪
应用核心安全事件的审计是强制的,不可关闭的,包括但不限于对下列可审计事件生成审计跟踪记录:
∙用户身份信息的创建、修改、删除
∙用户认证信息的修改
∙用户使用身份认证机制
∙应用业务交易相关的审计策略的变更
∙对每一个可审计事件,其审计记录包括:
∙序号
∙日期和时间
∙事件类型
∙主体身份
∙请求的源IP地址
∙事件结果(成功/失败)
∙数据的前映像和后映像
5.5.7应用访问的审计跟踪
应用访问的审计跟踪使用Web服务器的访问日志代替,可以记录时间、事件类型、主体身份、源IP地址、访问的URL等信息。
5.5.8应用错误或调试日志信息
信贷管理系统需要维护应用的错误和调试日志,并可以根据日志的级别设置启用相应的日志。
错误和调试日志采用文本文件存放在应用的日志目录中。
日志文件应该设置严格的访问控制权限,只允许应用系统的系统管理员访问。
系统可以定义日志文件的容量大小,当超过该容量时,就创建一个新的文件。
5.5.9备份恢复
∙应用备份恢复主要描述应用的代码、配置文件、日志和数据的备份要求。
∙应用的代码和配置文件采用全备份和增量备份结合的方式进行备份。
∙重大变更后,或每月进行一次全备份。
∙配置调整后,或每周进行一次增量备份。
∙应用的日志应该周期性全备份。
备份后清空在线应用日志文件。
日志备份应长期保留。
∙应用数据的备份不在应用软件层面实现,通过数据库的备份恢复机制来实现应用数据的备份。
5.5.10数据归档
数据归档描述信贷管理系统的数据归档、介质保存、归档查阅的方法和要求。
信贷管理系统的历史交易数据的归档方式是:
∙在归档前,对数据库做一致性备份,并存放到备份介质(磁带或光盘)。
此备份就是历史交易数据的归档介质。
∙运行归档逻辑,删除在线数据库中被归档的记录。
∙在归档后,对数据库做一致性备份,作为新的备份基准。
∙归档介质需要长期保存,并保证在归档保存期限内可用。
归档介质的可用性包括物理可用和逻辑可用。
∙物理可用是指要保证归档介质物理完整、可以读取,包括:
归档介质完好,归档介质读取设备完好,归档数据可以读取。
∙逻辑可用是指要保证恢复出来的归档记录可以通过应用进行查阅。
这要求保存归档时的应用版本和系统配置信息,以及运行应用的物理设备。
∙查阅归档记录的方式是在备用机上恢复数据和应用,使用应用访问恢复的数据来查询被归档的历史交易数据。
5.5.11异常管理
信贷管理系统异常管理的安全要求包括:
∙系统可捕获并处理异常。
当需要向系统管理员报告系统错误时,应使用定制的错误信息,并确保其中不含有任何可能被攻击者利用的信息,例如系统内部的实现细节。
∙当发生未捕获和处理的异常时,系统应该返回一个通用的错误信息。
∙所有报告给系统管理员的异常应该记录相应的日志。
6实施要求
日期
系统建设进度
2013年4月
立项、招标
2013年5月
系统需求细化
2013年6-7月
系统开发建设
2013年8月
系统测试验收
2013年9月
上线推广准备
2013年10月
系统上线
7附件
7.1附件
全流程信贷业务系统个贷业务条线系统需求说明书