银行储蓄业务系统需求分析说明书Word文档格式.docx
- 文档编号:21667217
- 上传时间:2023-01-31
- 格式:DOCX
- 页数:9
- 大小:74.51KB
银行储蓄业务系统需求分析说明书Word文档格式.docx
《银行储蓄业务系统需求分析说明书Word文档格式.docx》由会员分享,可在线阅读,更多相关《银行储蓄业务系统需求分析说明书Word文档格式.docx(9页珍藏版)》请在冰豆网上搜索。
进入系统后可添加或删除管理员,并设定银行的定期、活期利率。
“储户管理”包括添加储户(开户)、删除储户(销户)、活期(存款、取款、查询)、定期(存款、取款、查询)
“数据维护”即数据安全,可对数据进行备份与还原。
根据可行性研究的结果和客户的要求,分析现有情况及问题,绘制银行储蓄业务系统数据库E-R图:
性别
业务员号
姓名
E-R图中的实体与属性
银行储蓄业务系统的实体联系图
全局的E-R图
数据库需求分析
存款流程图
取款流程图
银行储蓄业务系统实体分析:
这里的银行储蓄业务系统是一个简化的系统,它只包含客户的存款取款业务,不涉及企业的大宗贷款业务,资金管理,内部管理等方面。
(1)储蓄业务系统管理的实体及属性说明
实体一:
业务员。
属性1-1:
业务员号,字符串,固定长度8.
属性1-2:
姓名,字符串,固定长度16.
属性1-3:
性别,字符串,固定长度2.
关于业务员信息的说明:
业务员号是唯一的,不得取空值,在表中作为主码。
姓名不得为空,但允许姓名相同。
实体二:
客户登记。
属性2-1:
姓名,字符串,中英文。
属性2-2:
属性2-3:
身份证号,字符串,固定长度18.
属性2-4:
住址,字符串,最大长度50.
属性2-5:
电话号码,字符串,最大长度20.
关于客户信息的说明:
客户姓名可以相同,但是身份证号是不可能相同的。
因此,在表中,身份证号作主码,是唯一识别客户的数据。
实体三:
客户账号。
属性3-1:
身份证号,字符串,固定长度18.取自“客户登记”中的“身份证号”。
属性3-2:
账号,字符串,固定长度16.
属性3-3,开户日期。
属性3-4:
账户余额,数字。
关于客户信息的说明:
客户账号中的身份证号必须来自客户登记表,不得取空值。
一个客户在银行可能有多个账号,但一个账号只能对应唯一的客户。
在表中,账号作主码,身份证号作外码。
(2)储蓄业务系统管理的实体之间联系的说明。
实体一盒实体二都是独立的信息。
一个来自于银行内部的业务员的信息,一个是外部的客户信息。
实体二通过实体一办理储蓄业务。
客户办理储蓄业务,可以是任何业务员。
业务员可以为任何客户办理储蓄业务。
每进行一笔储蓄业务,在账户流水中记录账号,存款金额(或取款金额),发生日期,业务类型,业务员号。
每进行一笔储蓄业务,在客户转账中记录转出账号,转入账号,转账金额,转账日期,业务员号。
(3)由E-R模型转换得到的账户流水关系模式。
4.1业务员(业务员号,姓名)。
4.2客户(姓名,身份证号,住址,电话号码)。
4.3客户账号(身份证号,账号,开户日期)。
4.4账户流水(账号,发生额,发生日期,业务员号)。
4.5业务类型
业务员,客户,客户账号三个关系模式,可以由三个实体对应产生。
新产生的关系模式“账户流水”是客户进行储蓄业务时产生的。
。
因此关系账户流水中有5个属性:
属性4-1:
账号,字符串,固定长度16.取自“客户账号”中的“账号”。
属性4-2:
发生金额,数值类型。
存款为正数,取款为负数。
每次取款不得超过5000。
属性4-3:
发生日期,日期时间类型。
属性4-4:
业务员号,字符串。
取自“业务员”中的“业务员号”。
属性4-5:
业务类型。
账户流水只记录各账户的存取款发生额,存款金额与取款金额是互斥的。
账号应该是“客户账号”表中实际存在的账号。
业务员号必须是银行业务员信息由登记的业务员号。
取款额设上限5000.
(4)由E-R模型转换得到的账户流水关系模式。
5.1业务员(业务员号,姓名)。
5.2客户(姓名,身份证号,住址,电话号码)。
5.3转出账号(身份证号,账号,开户日期)。
5.4转入账号(身份证号,账号,开户日期)。
5.5转账日期,日期时间类型。
属性5-1:
转出账号,字符串,固定长度16.取自“客户账号”中的“账号”。
属性5-2:
转入账号,字符串,固定长度16.取自“客户账号”中的“账号”。
属性5-3:
转账金额,数值类型。
转入为正数,转出为负数。
每次转出不得超过5000。
属性5-4:
属性5-5:
银行储蓄业务系统的性能需求
为了保证系统能够长期、安全、稳定、可靠、高效的运行,银行储蓄业务系统应该满足以下的性能需求:
1.系统处理的准确性和及时性
系统处理的准确性和及时性是系统的必要性能。
在系统设计和开发过程中,要充分考虑系统当前和将来可能承受的工作量,使系统的处理能力和响应时间能够满足企业对信息处理的需求。
由于银行储蓄业务系统的查询功能对于整个系统的功能和性能完成举足轻重。
作为系统的很多数据来源,而交易金额数量和交易时间又影响个人和银行的决策活动,其准确性很大程度上决定了银行储蓄业务系统的成败。
在系统开发过程中,必须采用一定的方法保证系统的准确性。
2.系统的开放性和系统的可扩充性
银行储蓄业务系统在开发过程中,应该充分考虑以后的可扩充性。
例如交易系统方式的改变(网上购物),用户查询的需求也会不断的更新和完善。
所有这些,都要求系统提供足够的手段进行功能的调整和扩充。
而要实现这一点,应通过系统的开放性来完成,既系统应是一个开放系统,只要符合一定的规范,可以简单的加入和减少系统的模块,配置系统的硬件。
通过软件的修补、替换完成系统的升级和更新换代。
3.系统的易用性和易维护性
银行储蓄业务系统是直接面对使用人员的,而使用人员往往对计算机并不是非常熟悉。
这就要求系统能够提供良好的用户接口,易用的人机交互界面。
要实现这一点,就要求系统应该尽量使用用户熟悉的术语和中文信息的界面;
针对用户可能出现的使用问题,要提供足够的在线帮助,缩短用户对系统熟悉的过程。
银行储蓄业务系统中涉及到的数据是银行相当重要的信息,系统要提供方便的手段供系统维护人员进行数据的备份,日常的安全管理,系统意外崩溃时数据的恢复等工作。
4.系统的标准性
系统在设计开发使用过程中都要涉及到很多计算机硬件、软件。
所有这些都要符合主流国际、国家和行业标准。
例如在开发中使用的操作系统、网络系统、开发工具都必须符合通用标准。
如规范的数据库操纵界面、作为业界标准的TCP/IP网络协议及ISO9002标准所要求的质量规范等;
同时,在自主开发本系统时,要进行良好的设计工作,制订行之有效的软件工程规范,保证代码的易读性、可操作性和可移植性。
5.系统的先进性
目前计算系统的技术发展相当快,做为银行储蓄业务系统工程,应该保证系统在下个世纪仍旧是先进的,在系统的生命周期尽量做到系统的先进,充分完成企业信息处理的要求而不至于落后。
这一方面通过系统的开放性和可扩充性,不断改善系统的功能完成。
另一方面,在系统设计和开发的过程中,应在考虑成本的基础上尽量采用当前主流并先进且有良好发展前途的产品。
6.系统的响应速度
银行储蓄业务系统系统在日常处理中的响应速度为秒级,达到实时要求,及时反馈信息。
在进行统计分析时,根据所需数据量的不同而从秒级到分钟级,
原则是保证操作人员不会因为速度问题而影响工作效率。
银行储蓄业务系统的数据需求
银行储蓄业务系统的数据需求包括如下几点:
1.数据录入和处理的准确性和实时性
数据的输入是否准确是数据处理的前提,错误的输入会导致系统输出的不正确和不可用,从而使系统的工作失去意义。
数据的输入来源是手工输入。
手工输入要通过系统界面上的安排系统具有容错性,并且对操作人员要进行系统的培训。
在系统中,数据的输入往往是大量的,因此系统要有一定的处理能力,以保证迅速的处理数据。
2.数据的一致性与完整性
由于系统的数据是共享的,在不同的银行,金额数是共享数据,所以如何保证这些数据的一致性,是系统必须解决的问题。
要解决这一问题,要有一定的人员维护数据的一致性,在数据录入处控制数据的去向,并且要求对数据库的数据完整性进行严格的约束。
对于输入的数据,要为其定义完整性规则,如果不能符合完整性约束,系统应该拒绝该数据。
3.数据的共享与独立性
整个银行储蓄业务系统的数据是共享的。
然而,从系统开发的角度上看,共享会给设计和调试带来困难。
因此,应该提供灵活的配置,使各个银行分系统能够独立运行,而通过人工干预的手段进行系统数据的交换。
这样,也能提供系统的强壮性。
建立银行储蓄业务系统的约束
计算机技术和产品的发展日新月异,将会给信息处理带来更多的手段,同时也会带来更加丰富的信息表达形式。
例如图象和语音技术的进步,多媒体技术的发展,这些都要求系统在设计时考虑技术变化的可能性,为可能的变化预留一定的系统处理能力。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 银行 储蓄 业务 系统 需求 分析 说明书