You are on page 1of 24

Banking System

_____________________________________________
Prepared By: Isra’a

University

Prepared For: Dr. Aysh Al- Huroob
Funded By: Isra’a University
_____________________________________________

Written By:

______________________________________________
Abdulrahman Muataz

Laith Obeidat &
01/24/2015

_____________________________________________

Table of Content
- Abstract
………………………………………………………………………………
…………. 3
- Introduction
………………………………………………………………………………
…… 3
- Feasibility Report
…………………………………………………………………………….4
- Stakeholders of Banking System
…………………………………………………….. 5
- Functional Requirements
………………………………………………………………. 7
- Non-Functional Requirements
……………………………………………………….. 8
- Use Case Diagram
………………………………………………………………………….. 9
- Use Case Specifications
………………………………………………………………… 10
- Class Diagram
………………………………………………………………………………..
16
- Sequence Diagram
………………………………………………………………………… 17
- Activity Diagram
…………………………………………………………………………….
20
- Risk Analysis and Classification
……………………………………………………… 21
- Risk Decomposition Fault-tree technique
……………………………………… 23

2

Banking System

Abstract
The scope of this project is limited to the activities of an
operations unit of the banking system which includes opening of
account, deposit of funds, funds transfer, check balance, monthly
statement and different payment methods.

Introduction
One of the most important processes needed by client is the
banking operations, because it regulates most of his financial
activities to achieve particular objectives. In this system we are
provides the main process that including in banking system to
achieve the best solution to enhance operations in banking
system that meet customer needs.
3

Technologies
 Hardware Requirements
- PC with 2GB hard disk.
- 256 MB RAM.
 Software Requirements
- Windows 7 with MS-OFFICE
- Database – MY-SQL / MS-ACCESS.
- Programming Language – VB.NET.
- IDE-Visual Studio 2008.

Feasibility Report
Three main advantages aspects of the banking system:

ECONOMICAL FEASIBILITY
The proposed system “Banking System” we use the S/W to
development the proposed banking system we will use easily S/W
available with low cost and the database is freely available hence
to minimum cost implementation.
TECHNICAL FEASIBILITY
In this part we concern with using computer through convert from
manual solution to automated solution to obtain needs for a
technical feasibility study, also we focus on the platform used
database management. In the proposed system doesn’t need to
expert knowledge about the system development because the
S/W (VB.NET) used makes the system user friendly through (GUI),
and the performance will be true in best time.
4

BEHAVIOURAL FEASIBILITY
The proposed system must be better than the existing system in
the specification (behavioral) study. The S/W should care in end
user when the system is structured, while implementation should
be care with user’s knowledge inputs, outputs etc. within a
minimum bugs (operations illogical), and avoid any non-working
components.

CURRENT SYSTEM
The proposed system is a creative in the sector of banking
because in the existing system we need to more human resource
to get the job done but in the proposed system requires lesser
staffs. The data entry and saved processes we need too many of
paper also during work within existing system higher possibility of
errors, time, and more usage of resources like papers etc.
PROPOSED SYSTEM
Why an Automated Banking System?






Most of information related with work based on paper.
Reduce the time searching of documents.
Compatible with changing system requirements.
Quick, easy to use and enterprise wide access to information.
Enhance data security through authentication access.
Reduce storage space.
Facilitate widely used in withdrawal process, deposition
process and faster balance enquiry.

5

STAKEHOLDERS OF BANKING SYSTEM
 Customer
 Internal Customer

-

View accounts.
Check balance.
Transaction history.
Transfer funds.
Pay bills.
Check services.
Deposit funds.
Withdraw cash.
Check or update personal information.

 External Customer

- Don’t have any accounts. But can open an account and
deposit funds.

 Employees
 Administrator
- Controlling of all processes in the system to sustainability
of the company (approved process, granting authority).
 Customer Services (Teller)
- Open an account for the customer, provides information
and dealing with deposit and withdraw processes,
moreover dealing smart cards, systems of loans available
and customers' transactions in a bank.
 Reception
- Provide possible assistance to the customer and any help
they need.
 IT Employee
- Provides a help disk, manages network, and manage
Database that related with the system.

6

 Security Employee
- Keep the public safety security for the completion of the
banking process successfully without any risk.

 Shareholders
- Share price growth, dividends, also to ensuring a solid and
sustainable investment return through providing an
accessible information involves processes and procedures
to ensure fully meet investors expectations
 Government
- Ensure legal working, payment of taxes.
Functional Requirements
 Open an account: both external and internal customers can
open a new account.
 The customer can do login to the system through the website
and he can access account by user name and password after
verified with database.
 Customer can make a funds transfer to another account in the
same bank or another bank.
 Customer can request details of number of transactions he
has performed on any account.
 Customer can request for cheque book.
 Show Account statement (Transactions History):Customer can
view his account statement within a specified period. He can
also take print out of the same.
 Balance enquiry: The system is providing balance enquiry
facility.
7

 Pay bill: Customers can select one of their accounts they want
to use for bill payment.
 Account Summary: A customer can get an account summary
for all accounts, including account number, account type and
balance.
 Service for changing information: Customers can modify some
information, such as address, phone number and password.
 Once the customer finishes the task the update information
gets stored into the database.
 The customer can sign out from his account.
Non-Functional Requirements
 Secure access of confidential data. SSL can be used (critical).
 Availability: The system must be available at any time for the
user (critical).
 Efficiency: the average response time of the system should be
less than thirty seconds (critical).
 Usability: The interfaces of the system should be designed to
be clear, simple and easy to use and understand. To increase
the user friendly.
 Robustness: In any Risks such as loss of electricity, the
system should not loss any information or data the system
should maintain the integrity of the database all the time.

8

 Reliability: The system should be reliable to the users and its
failure rate should be less than 0.05% (critical).
 Privacy: The private information of each individual stored in
the system should be secured. Only the owner of data is
allowed to access the information. User ID and password can
be achieved this goal.
 Flexibility: the system architecture will be fits with future
extensions.

Use Case Diagram
Use case diagram is a diagram that shows a set of use cases
and actors and their relationships.

9

10

Use Case Specification
Name: Login
Actors: User, Bank Staff
Description: The Login begins when user is entering user name
and password in to the system, to display his profile and the
recent transactions and choose available services. The
customer can change the account login password, but not the
user id, every transaction login is added to the bank database.
Basic Flow:
1- User enters username and password.
2- Bank Database validates the user.
3- After success user can transfer money, change his
password and view his Account.
Alternative Flow: If in the basic flow, the details specified by
user are invalid then he is informed that this login is failed
.Then the user may quit the system or create a new account.
Precondition: The user should have a valid account in the
bank.
Post condition: The account database is updated after
transaction.

11

Name: cancel account
Actors: User, Bank Staff
Description: after enables the user login to his account in
system, the user can request to cancel the account
Basic Flow:
1. The user selects the Delete option.
2. The system will then ask the user to verify/confirm the
canceling of the account.
Alternative Flow: if in the basic flow, the user cannot cancel
account of database records because the balance account is
not zero.
Precondition: User login to the system and request cancel
account.
Post condition: The system cannot cancel.

12

Name: request service
Actors: User, Bank Staff
Description: after enables the user login to his account in
system, the user can complement all dealings.
Basic Flow:
The user selects the open account, view account, deposit,
fund transfer, payment, check balance or withdraw.
Alternative Flow: The user cannot perform any of the services
unless they have a bank account.
Precondition: User has an account in the bank and login to the
system.
Post condition:

13

Name: open account
Actors: User, Bank Staff
Description: after enables the user login to system, the user
can request to open account.
Basic Flow:
1. User is open new account.
2. If the user has an account (current) can open another
account(saving).
Alternative Flow: The user will not be able to complete the
process of opening an account unless meets the requirements
set.
Precondition: User login to the system and request open new
account.
Post condition: after open account successfully, enjoy all the
services offered by the Bank.

14

Class Diagram for banking system

0..*

1

1

1
1
1

1
1

1

1

1

1
1

0..*

0..*
1

Sequence Diagrams

Sequence Login Diagram

15

0..*

Deposit Sequence Diagram

16

Withdraw Sequence Diagram

17

Activity Diagram

18

Login Activity Diagram

Deposit Activity Diagram

19

Withdraw Activity Diagram

20

Risk analysis and classification
Identified hazard

Hazard
probabili
21

Hazar
d

Estima
te Risk

Acceptabili
ty

ty
Power Failure

Low

Severi
ty
Low

Damage data

Low

High

Service Error

Low

High

Unauthorized Attack
Increased visibility of publicly
accessible networks (e.g. the
Internet)
Less face-to-face interaction with
financial institution customers
Speed of technological change

High
High

Low

Acceptable
ALARP

High
High

Mediu
m
Mediu
m
High
High

Intolerable
Intolerable

Low

Low

Low

Acceptable

Medium

Mediu
m
High

Mediu
m
High

ALARP
Intolerable

High

Mediu
m

High

Intolerable

Mediu
m
Mediu
m
Mediu
m
Mediu
m

ALARP

Need to integrate e-banking with the
institution's legacy computer systems
Dependence on others for necessary
technical expertise against of threats
and vulnerabilities in publicly
accessible networks
arise fire in the banking system

High

Low

High

Storage space is insufficient

Medium

Physical security of all e-banking
computer equipment
Up-to-date equipment inventories,
network maps and backup data

Low

Mediu
m
High

Medium

22

Mediu
m

ALARP

ALARP
ALARP
ALARP

Risk Decomposition fault-tree technique

23

24