Online Bank Management System
Online Bank Management System
SYSTEM
1. Introduction
This document gives detailed functional and nonfunctional
requirements for the bank management system. This product will
support online banking transaction. The purpose of this document
is that the requirements mentioned in it should be utilized by
software developer to implement the system.
1.1 Purpose
Online banking system provides is specifically developed for
internet banking for Balance Enquiry, Funds Transfer to another
account in the same bank, Request for cheque book/change of
address/stop payment of cheques, Mini statements (Viewing
Monthly and annual statements).
The Traditional way of maintaining details of a user in a bank was
to enter the details and record them. Every time the user need to
perform some transactions he has to go to bank and perform the
necessary actions, which may not be so feasible all the time. It
may be a hard-hitting task for the users and the bankers too. The
project gives real life understanding of Internet banking and
activities performed by various roles in the supply chain. Here, we
provide an automation for banking system through Internet.
Internet banking system project captures
activities performed by different roles in real life banking which
provides enhanced techniques for maintaining the required information up-to-date, which results in efficiency. The project gives
real life understanding of Internet banking and activities
performed by various roles in the supply chain.
1.2 Scope
This Product will automate of banking transaction process.This
Project investigates the entry threshold for providing a new
transaction service channel via the real options approach,
where the entry threshold is established by using an Internet
banking system designed for the use of normal
users(individuals), Industrialists, Entrepreneurs, Educational
Institutions(Financial sections), Organizations and Academicians
under transaction rate uncertainty.
1.3 Overview
The system provides easy solution to banks.
Overview: The SRS will include two sections, namely:
Overall Description: This section will describe major components
of the system, interconnections, and external interfaces.
Specific Requirements: This section will describe the functions
of actors, their roles in the system and the constraints faced by
sys- tem.
2. General description
2.1
Product Perspective:
The client will have client interface in which he can interact with
the banking sys- tem. It is a web based interface which will be the
web page of the banking application. Starting a page is
displayed asking the type of customer he is whether ordinary
or a corporate customer. Then the page is redirected to login
page where the user can enter the login details. If the login
particulars are valid then the user is taken to a home page where
he has the entire transaction list that he can perform with the
bank. All the above activities come under the client interface.
The administrator will have an administrative in- terface
which is a GUI so that he can view the entire system. He will also
have a login page where he can enter the login particulars so
that he can perform all his actions. This administrative
interface provides different environment such that he can
maintain data- base & provide backups for the information in the
database. He can register the users by providing them with
username, password & by creating account in the database.
He can view the cheque book request & perform action to issue
the cheque books to the clients.
2.2
Software Interface:
3. Functional Specifications
This section provides the functional overview of the product. The
project will require the PHP as a front end and at the back end the
database MYSQL will be running. Various functional modules that
can be implemented by the product will be
1. Login
2. Validation
3. Get balance information
4. Withdrawal of money
5. Transfer Money
6. Customer info.
3.1 Login:
Customer logins by entering customer name & a login pin.
3.2 Validation:
When a customer enters the ATM card, its validity must be
ensured. Then customer is allowed to enter the valid PIN. The
validation can be for following conditions
Validation for lost or stolen card:
When card is already reported as lost or stolen
then the message Lost/Stolen card!!!.
Validation for cards expiry date:
If the card inserted by the customer has crossed the expiry date
then the system will prompt
Expired Card.
Validation for PIN:
After validating the card, the validity of PIN must be ensured. If
he/she fails to enter valid code for three times then the card will
not be returned to him. That means the account can be locked.
The counter for number of logins must be maintained
4. Interface Requirements
4.1 GUI
5. Performance Requirements
The system should be compatible enough to hold the general
traffic .
It should not get hang or show some other problems arising out
due to large no of concurrent users . The system should be fast
enough to meet the customer The high and low temperature
should not affect the performance of the device. An uninterrupted
transaction must be performed.
6.Constraints
* The information of all the users must be stored in a database
that is accessible by the On- line
Banking System.
* The Online Banking System is connected to the computer and is
running all 24hours a day.
* The users access the Online Banking System from any
computer that has Internet browsing capabilities and an Internet
connection.
*The users must have their correct usernames and passwords to
enter into the Online Banking System.
Design Constraints:
* Software Language Used
The languages that shall be used for coding Online Banking
System are c , c++ , java , and HTML. For working on the
coding phase of the Online job portal System Web Sphere
7. Performance
7.1 Security
The banking system must be fully accessible to only authentic
user.
It should require pin for entry to a new environment.
7.2 Reliability
The application should be highly reliable and it should generate
all the updated information in correct order.
7.3 Availability
7.4 Maintainability
The application should be maintainable in such a manner that if
any new requirement occurs then it should be easily incorporated
in an individual module.
7.5 Portability
The application should be portable on any windows based system.
It should not be machine specific.