用户需求说明书.docx
- 文档编号:18504966
- 上传时间:2023-08-18
- 格式:DOCX
- 页数:29
- 大小:208.66KB
用户需求说明书.docx
《用户需求说明书.docx》由会员分享,可在线阅读,更多相关《用户需求说明书.docx(29页珍藏版)》请在冰点文库上搜索。
用户需求说明书
中国金融电子化公司
文档编号:
版本号:
VER1.0
财税库行联网业务系统
用户需求说明书
中国金融电子化公司开发一部
二○○九年十二月
修订记录
序号
日期
章节号
简单描述
修订者
1
2009-12-05
草拟
李胜
目录
目录3
1.概述5
1.1.目的5
1.2.背景5
1.3.读者范围6
1.4.参考资料7
1.5.术语与缩写词7
1.6.假定与限制7
2.系统分析9
2.1.需求概述9
2.2.系统运行时序9
2.3.用例清单及优先级10
2.4.典型处理流程11
2.5.非功能性需求11
2.6.1系统性能需求11
2.6.2系统处理能力12
2.6.3存储要求13
2.6.3.1纯业务数据存储量分析13
2.6.3.2包含业务数据、索引、日志的存储综合分析13
2.6.4系统可维护性14
3.系统功能划分15
3.1.系统交易清单15
3.2.系统功能模块划分15
3.2.1.自动处理子系统15
3.2.2.系统维护子系统15
3.2.3.查询打印子系统15
3.2.4.日终处理15
4.系统体系结构设计16
4.1物理结构16
4.2逻辑结构17
4.3软件架构设计18
4.3.1基于交易处理模式的C/S架构18
4.3.2服务器软件架构设计18
5.关键技术实现19
5.1.客户端与子系统后台之间19
5.2.联网子系统与核心业务系统之间19
5.3.联网子系统与TIPS前置系统之间19
6.关键业务验证20
7.数据库设计21
7.1逻辑设计21
7.2物理设计21
8.接口设计22
8.1用户接口22
8.1.1.客户端程序的界面风格和样式22
8.1.2.菜单结构22
9.日志(暨可维护性)设计23
9.1日志设计原理23
9.2日志设计实现24
10.安全性与可靠性设计26
10.1安全性设计内容26
10.1.1网络安全性26
10.1.2操作系统安全性26
10.1.3数据库安全性27
10.1.4应用安全性27
10.2可靠性设计内容27
10.2.1硬件可靠性27
10.2.2软件可靠性27
10.3备份策略及灾难恢复28
10.3.1备份操作28
10.3.2备份管理29
10.3.3灾难恢复29
11.自动化工具设计31
12.软硬件选型说明32
12.1硬件设备配置方案32
12.1.1硬件设备配置原则32
12.1.2服务器配置32
12.1.3服务器配置33
12.1.4客户机配置33
12.2操作系统平台配置方案33
12.2.1服务器操作系统方案33
12.2.2客户端操作平台33
12.3软件支撑环境33
12.3.1数据库管理系统33
1.概述
1.1.目的
本文依据商业银行财税库银联网项目(以下简称联网中间业务系统)的业务需求及国库信息处理系统与商业银行的接口方案,提出了联网中间业务系统的体系结构,主要包括系统架构,系统的划分及不同系统的交互,系统的部署问题。
同时还给出了系统的安全解决方案,系统可用性、可扩展性、系统效率等问题的解决方案,系统数据存储、备份解决方案、系统网络体系结构、系统安全解决方案、与外部系统集成解决方案、系统软件与硬件解决方案、系统报表解决方案、系统部署与维护及技术支持等解决方案。
该系统体系结构是为了指导联网中间业务系统的设计、开发及测试过程,给出了在这些过程中应该遵循的标准。
1.2.背景
为实现税票信息的电子化处理。
为合理配置和节约资源,按照信息化社会的发展要求,人民银行与财政部、国家税务总局共同研究开发了全国统一的“财税库横向联网系统。
”
为满足财税库横向联网后国库内部汇集、处理、加工和利用相关信息的需要,在“财税库横向联网系统”推广的同时,国库推广使用“国库信息处理系统”
联网中间业务系统是一个以财税库银联网的业务流程和工作流程为基础的连接财税库行横向联网前置系统及商业银行核心业务系统的信息传递处理系统,用于传递、处理税款缴纳、对账、业务监管等各项业务的电子信息。
联网中间业务系统实现了商业银行与国库之间的电子信息的相互交互。
联网中间业务系统方便纳税人申报纳税。
为纳税人提供更加先进、便捷的服务,申报缴税可一次一地完成。
当签订了三方(地税、银行、纳税人)协议的纳税人在地税局申报成功后,即可直接完成税款缴纳;当纳税人去银行网点时,可以在银行网点完成申报后,当即完成税款缴纳;纳税人可以通过税务网站完成申报,通过网上银行或银行卡网站完成缴款。
系统将在商业银行各营业网点使用。
图1-1联网中间业务系统结构图。
业务范围覆盖了实时扣税,批量扣税,实时冲正,批量止付,纳税申报等业务,包括来账自动处理子系统、客户端发起业务子系统、参数及监控子系统、系统维护子系统、日初日终子系统、查询打印子系统。
图1-1联网中间业务系统结构图
1.3.读者范围
联网中间业务系统体系结构读者范围包括以下几个方面:
商业银行、人民银行金电公司,具体来说:
商业银行作为用户与业务需求的提出方,通过对联网中间业务系统的体系结构了解,知道开发部门是如何解决他们所提出的软件需求涉及的问题,知道未来该系统的运行环境等。
人民银行金电公司,作为项目的开发部门与实施部门,设计系统体系结构是为了指导组件设计与开发人员及系统测试人员的工作。
1.4.参考资料
1.《国库信息处理系统接口报文规范》
2.《国库信息处理系统与商业银行的接口技术方案》
3.《国库信息处理系统接口交易处理流程》
4.《商业银行财税库银联网项目情况介绍》
5.《软件开发中心软件项目工程文档编写规范》
6.《软件开发中心软件项目管理规范》
1.5.术语与缩写词
缩写词
注释
TIPS
国库信息处理系统
前置系统
接入TIPS的财税库行横向联网前置系统,主要作用为报文格式转换
联网中间业务系统
商业银行财税库行的联网业务处理系统,接受和处理国库信息处理系统发往商业银行的扣税请求以及商业银行自身行内系统发起联网的业务
核心业务系统
商业银行的原有的核心业务系统,总体向联网中间业务系统提供账户和清算服务
联网中间业务系统客户端
联网中间业务系统为商业银行提供的在柜台使用输入业务请求信息的客户端程序
商业银行业务系统客户端
商业银行自身已有系统的柜台程序,联网中间业务系统客户端由其调用
1.6.假定与限制
联网中间业务系统体系结构是建立在以下假定的基础上的:
硬件
内存
>=1024M
处理器
>=1.0G
硬盘
>=40G
网络适配器
10/100M自适应网卡
系统软件
SCOOpenServer
5.0.6
Windows
数据库
Informix
7.3
2.系统分析
2.1.需求概述
1.不对现有的核心业务系统进行大的改造。
2.联网中间业务系统建设成一个独立子系统,独立部署在其他服务器上。
子系统客户端程序集成在现有业务处理界面中,通过特定菜单激活联网业务子系统客户端程序。
3.具有系统参数的功能。
联网中间业务系统用经业务部门确认后的数据和参数作为基础。
系统参数主要包括工作日期、节点代码、行号、应用程序名、版本号、IP地址、贷方账号、网点支付行号等在正常业务处理前需要设定的数据。
4.具有方便的查询和打印功能,对凭证,对账单均提供查询和选择打印功能。
2.2.系统运行时序
2.3.用例清单及优先级
用例编号
用例名称
优先级
T2091QUERY
银行端申报查询
高
T9100BANKQ
银行代码
低
T9100CORRQ
更正原因代码
低
T9100NODEQ
节点代码
低
T9100RTRSQ
退库原因代码
低
T9100SBJQR
预算科目代码
低
T9100TAXQR
征收机关代码
低
T9100TREQR
国库代码
低
T9100TSBJQ
税目代码
低
T9100TTPEQ
税种代码
低
T9102QUERY
故障通知查询
低
T9103QUERY
强制退出通知查询
低
T9104QUERY
停运启用通知查询
低
T9105QUERY
查看自由格式报文
中
T9106QUERY
运行参数通知查询
中
TCHSTATQRY
状态变更通知查询
中
TLDZDY0001
对账打印
高
TLDZMXCX01
对账核对不符明细查询
高
TLDZQDCX01
对账清单查询
高
TLJSFKPZDY
电子缴税付款凭证打印
高
TLJSPZDYCL
缴税凭证打印预处理
高
TLJYZTCXCF
交易状态查询请求重发
高
TLJYZTCXCX
交易状态查询请求查询
高
TLJYZTCXLR
交易状态查询请求录入
高
TLJYZTCXXG
交易状态查询请求修改
高
TLSFXYCX00
三方协议信息查询
高
TLSFXYLR00
三方协议信息录入预处理
高
TLSFXYLR01
三方协议信息录入
高
TLSFXYSC00
三方协议信息删除
高
TLSFXYXG00
三方协议信息修改
高
TLSQBMXFCF
申报包明细重发请求重发
高
TLSQBMXFCX
申报包明细重发请求查询
高
TLSQBMXFLR
申报包明细重发请求录入
高
TLSQBMXFXG
申报包明细重发请求修改
高
TLSQYHDZCF
申请银行对账重发请求重发
高
TLSQYHDZCX
申请银行对账重发请求查询
高
TLSQYHDZLR
申请银行对账重发请求录入
高
TLSQYHDZXG
申请银行对账重发请求修改
高
TLXYYZCXCF
发起三方协议验证与撤销重发
高
TLXYYZCXJG
发起三方协议验证与撤销查询
高
TLXYYZCXLR
发起三方协议验证与撤销录入
高
TLXYYZCXLY
发起三方协议验证与撤销录入预处理
高
TLXYYZCXXG
发起三方协议验证与撤销修改
高
TLYHDSBSMC
银行端申报缴款税目查询
中
TLZYGSCX00
发起自由格式查询
中
TLZYGSLR00
发起自由格式录入
中
TQUERYTAXP
税票查询
中
TSTATQUERY
查询工作日和工作状态
中
TLRCCL0000
日初处理
中
TLRZCL0000
日终处理
中
TWCZRYDL01
网点操作员登录
中
2.4.典型处理流程
图2-1联网中间业务系统处理流程
2.5.非功能性需求
2.6.1系统性能需求
系统的性能需求主要指的是系统的响应时间。
响应时间取决于网路的性能、软件设计的质量和使用的硬件设备的性能。
在网络设备运行正常的情况下,本系统的主要要求如下:
业务处理时间一般不超过3分钟;
业务信息查询时间一般不超过10秒;
报表生成时间一般不超过30秒;
日终处理时间一般不超过10分钟。
2.6.2系统处理能力
联网中间业务系统覆盖着商业银行各支行营业网点,下表给出了各个单位的业务量情况。
表2-1各个单位业务量统计表
(自身不含全辖)
日平均业务量(笔)
日最大业务量(笔)
总行营业部
支行营业部
分理处等营业网点
根据以上业务量统计表,下表给出了处理能力计算表。
TPM-C=M*M0/T/M1
M为日交易量,包括对数据库更新、查询、增加、删除等操作。
计算TPM-C的目的是为了确定机器的处理能力,由于在每天的业务处理过程中,业务发生的频度不尽相同,一般情况下是按照8/2原则,具体来说,在20%的工作时间内业务人员要处理80%的业务。
M0为一个应用交易所对应的标准交易个数,推荐值为8-12,由于系统体系结构的不同、应用服务器的结构不同,各个厂商的推荐值也不同,如:
HP公司推荐为10。
T为交易的高峰时间,使用2/8原则,如:
每日工作时间为8小时,那么交易的高峰时间T=8*20%=1.6小时。
M1为机器预留的处理能力,这一部分的处理能力是为了分配给操作系统、中间件应用服务器及数据库服务器的。
一般来说为50%。
说明:
M0=12,按照目前厂商与TPC组织推荐的标准为8~12,取最大值为12。
T=96分钟,按照每天工作8个小时计算,同时根据2/8原则,即8*20%=1.6小时=96分钟内完成每天的工作量。
M1=50%
M0/T/M1=12/96/0.5=1/4
关于业务两M的计算,按照日最大交易量来进行计算,同时按照8/2原则,即在高峰期要处理全天80%的业务。
表2-3最大处理能力表(单位:
笔)
最大日业务量
高峰交易量
TPC-C
每分钟并发交易数
全市
3800
3800*80%=3040
3040/4=760
3800/96=39
表2-4平均处理能力表(单位:
笔)
平均日业务量
高峰交易量
TPC-C
每分钟并发交易数
全市
2000
2000*80%=1600
1600/4=400
2000/96=20
各级最大交易量来源于表2-1。
2.6.3存储要求
2.6.3.1纯业务数据存储量分析
Ø平均业务数据存储量
每条记录
平均业务量
每日存储
每月存储(22个工作日)
每年存储
全辖
2K
2000
4(M)
88(M)
1.056(G)
Ø最大业务数据存储量
每条记录
最大业务量
每日存储
每月存储(22个工作日)
每年存储
全辖
2K
3800
7.6(M)
167.2(M)
2(G)
2.6.3.2包含业务数据、索引、日志的存储综合分析
联网中间业务系统的数据库坚持定期备份,并辅以数据库日志保存1个月,足以保证业务数据的安全。
所以在计算业务数据存储要求时作如下假定:
●数据库系统日志最多保存一个月。
一笔业务数据需要的日志空间为一笔业务数据长度的2.25倍;
●索引需要的存储空间是业务数据存储空间的0.5倍。
下述两张表说明了数据存储需求:
Ø实际平均存储要求
时间
纯数据量
索引
日志
合计
全辖
一天
4(M)
2(M)
9(M)
15(M)
一个月
88(M)
44(M)
99(M)
231(M)
一年
1.056(G)
0.528(G)
0.099(G)
1.683(G)
Ø实际最大存储要求
时间
纯数据量
索引
日志
合计
一年
25.660(G)
12.830(G)
4.811(G)
43.301(G)
全辖
一天
7.6(M)
3.8(M)
17.1(M)
28.5(M)
一个月
167.2(M)
83.6(M)
376.2(M)
627(M)
一年
2(G)
1(G)
0.376(G)
3.376(G)
说明:
以上的数据量和存储的估算仅仅为系统大致的估算,实际运行过程中需要根据实际数据量的大小进行存储设备的扩容。
2.6.4系统可维护性
联网中间业务系统的设计上要考虑到将来系统易于维护。
一方面,系统运行中出现异常,一般性问题业务操作员应根据系统提示快速解决问题,特殊问题科技人员根据系统日志能快速定位并解决问题。
另一方面,联网中间业务系统程序模块化要好,代码要规范,易于进行软件维护和升级。
3.系统功能划分
3.1.系统交易清单
参见《联网中间业务系统交易设计.xls》
3.2.系统功能模块划分
3.2.1.自动处理子系统
在自动处理子系统主要处理前置系统转发的实时扣税、实时冲正、批量扣税、止付请求、自由格式、公共数据、通知类报文、对账等业务功能。
3.2.2.系统维护子系统
系统维护是对联网中间业务系统系统运行参数、数据处理、数据输出等方面的管理,为了满足上述系统运行管理的要求,系统维护应提供管辖行管理、数据操作、参数管理、账务管理等与系统运行有关的管理功能。
3.2.3.查询打印子系统
主要处理账务信息的查询打印。
3.2.4.日终处理
4.系统体系结构设计
4.1物理结构
从上述系统物理结构示意图可以看出联网中间业务系统与前置系统、核心系统之间的关系(为简化起见,图中没有画出所有的备份设备如前置机的备份机等)。
联网中间业务系统只部署在商业银行总行科技处,在营业网点设置客户端、若干操作终端(也可为PC)和打印机。
联网中间业务系统与核心业务系统通过Socket进行通讯,联网业务子系统为客户端,核心业务系统为服务端;通讯连接方式为长连接;通讯接口报文采用定长的字符串。
客户端通过发起Socket请求获取核心业务系统提供的服务;客户端可以获取核心业务系统已有的向外提供的所有服务。
4.2逻辑结构
与前置系统分机部署结构图
联网中间业务系统逻辑结构图
4.3软件架构设计
4.3.1基于交易处理模式的C/S架构
下图给出了联网中间业务系统应用架构。
联网中间业务系统采用当前业界广泛应用的“客户端-服务器”两层处理结构,客户端通过网络与后台服务器进行交互,系统的所有功能按“客户端录入并提交申请-服务器处理、存储数据并返回处理结果-客户端接收并输出处理结果”的交易处理模式实现。
4.3.2服务器软件架构设计
服务器端软件在子系统划分的基础上,采用分层实现的思想。
首先将系统划分为子系统,再将子系统划分为一系列原子操作——交易,交易之间相对独立,同时又可以合理组合从而完成一些复杂的业务逻辑。
这样做大大简化了系统横向复杂度。
同时,对于每一个交易进行分层实现。
即将交易程序分为三层以上:
1、业务逻辑层(最高层)
业务逻辑层体现交易的业务逻辑,主要包括交易数据的合法性检查,对若干业务逻辑实现步骤(实现层)的函数调用,以及形成应答报文数据返回客户端。
2、业务逻辑实现层(中间层)
业务逻辑实现层由一系列业务逻辑的具体模块组成。
这些模块主要进行数据的运算和对第三层程序的若干函数调用,来完成特定业务处理步骤所要求的功能。
3、数据库操作层(第三层)
数据库操作层主要实现对数据库的访问。
针对联网中间业务系统的特点,设计时对一些基础功能进行了抽取和封装,形成了共用模块层,对交易实现提供服务。
具体见公共函数概要设计。
5.关键技术实现
5.1.客户端与子系统后台之间
客户端由C语言开发,可以采用ABS的现有的实现方式,与后台的通讯报文格式可以采用ABS已有的格式“TAG符字符串”。
服务端用C语言实现,可以使用ABS现有的报文解析工具,无需重新开发报文解析工具;
5.2.联网子系统与核心业务系统之间
用C语言实现定长格式的报文解析
5.3.联网子系统与TIPS前置系统之间
用C语言实现TIPS前置系统格式的报文解析
6.关键业务验证
7.数据库设计
7.1逻辑设计
联网中间业务系统数据分为五大类:
报文数据、常量数据、业务系统对账数据、账务明细数据和系统功能的系统数据。
报文数据被整理为如下模式:
一个索引表对应多个业务明细表,通过键值流水号关联;
账务明细数据被整理为如下模式:
一个明细索引表对应一个实时扣税数据表和银行申报回执表以及多个批量扣税数据表,通过记录的键值关联。
业务系统对账数据设计成如下模式:
一个索引表对应明细表,通过键值关联。
具体的设计见“数据库详细设计.xls”
7.2物理设计
联网中间业务系统的数据分布在taxdbsdbspace上,使用informixonline数据库服务器,物理日志和逻辑日志分别为rootdbs和logdbs。
8.接口设计
8.1用户接口
8.1.1.客户端程序的界面风格和样式
8.1.2.菜单结构
●服务器:
服务器上主要提供启动服务器进程的操作,菜单如下:
启动交易服务
启动文件传输服务
注:
启动服务不需操作员登录
●客户端:
客户端程序集成在现有业务处理界面中,通过特定菜单激活联网业务子系统客户端程序
9.日志(暨可维护性)设计
9.1日志设计原理
1)设计目标
•让使用系统的业务员尽可能清楚在交易成功的情况下系统做了什么工作(简略),以及在交易失败的情况下出了什么错、如何改正。
•方便系统的调试和测试,便于迅速定位到出错的源代码文件及具体行号,并且能够知道关键的函数接口数据。
•方便系统的扩展
2)出错分类
•程序员编码错误,此类问题尽可能在编码及测试阶段解决。
•应用系统有关参数错误,主要表现形式为数据库操作失败,如键值重复、某字段不可空、查询单条记录却返回多条记录等。
•操作员操作错误,操作员可从返回信息得到提示,并在比较熟练的情况下能够找到解决问题的办法。
•系统错误,如没有文件读写权限、系统资源限制等。
3)返回信息的具体要求
•系统定义一套完整而唯一的返回码(主要是错误码),对应的返回信息用一个数据表DLFHXX存储。
要求错误返回码都是小于零的数字,而大于等于零的返回码代表交易成功,其中大于零的返回码代表特殊的成功返回。
•详细设计必须对每一个步骤进行简单描述,即描述该步骤的主要功能。
若执行该步骤时出错,即可返回“某某功能错误”。
•在每一层函数调用或功能步骤出现异常,都返回相应的错误代码,不得直接返回低层函数的返回码(但可以一样)。
不同交易的返回码允许重复(以便减少返回码数量)。
•除了数据库操作等系统级的出错信息(如文件读写权限,系统资源限制等),其它层次的出错信息都返回到前台。
多层次的出错信息用一个分段的长字符串存放。
如100*10,表示每一个出错信息不超过100个字符,最多10个层次的出错信息。
长度和层次数由专家根据经验确定。
•出错信息中除包括根据错误代码从数据库表中查询到的返回信息外,还应包括出错源文件名、出错行号和出错时间,后者显示在前台出错对话框右侧(隐蔽)。
•数据库操作等系统级错误信息必须翻译成用户可理解的表达方式。
•出错信息同时写到后台错误日志中。
•最底层的函数尽可能把各种能区分的错误情况区分开,并在出错的情况下把函数的接口数据写到调试日志文件中。
如数据库表操作的公用函数,以下几种特殊情况要区分出来:
插入或修改时出现唯一性字段重复,试图对不可空的字段写入空数据,修改时没有纪录被修改,删除时没有纪录被删除,查询时没有相应的纪录等等。
•底层函数应该具有扩展性。
如后期可以增加错误代码的识别,但对上层调用者应保持兼容性。
•若交易成功,则无需返回多层次的成功信息,返回信息中除提示“交易成功”外,再简要描述成功内容即可。
如“交易成功,账户校验,账号:
256000000000000”。
•若交易成
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 用户 需求 说明书