0% found this document useful (0 votes)
53 views

Initial Requirement Document of Bank Management System

This document provides an initial requirements document for a bank management system. It outlines key stakeholders, requirements gathering techniques, and a consolidated list of 16 initial requirements for the system. These requirements include allowing users to manage their bank accounts anytime from anywhere, generating usernames and passwords, allowing account holders to apply for loans, calculating interest, and ensuring security and privacy of users' financial information. The document also provides an overview of use cases, actors, and a basic use case diagram for the system.

Uploaded by

Aliv Ghosh
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
53 views

Initial Requirement Document of Bank Management System

This document provides an initial requirements document for a bank management system. It outlines key stakeholders, requirements gathering techniques, and a consolidated list of 16 initial requirements for the system. These requirements include allowing users to manage their bank accounts anytime from anywhere, generating usernames and passwords, allowing account holders to apply for loans, calculating interest, and ensuring security and privacy of users' financial information. The document also provides an overview of use cases, actors, and a basic use case diagram for the system.

Uploaded by

Aliv Ghosh
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 13

Bank Management System

Initial Requirement Document of Bank Management System

Title of the project Bank Management System

Stakeholders involved in capturing requirements Managers, End users, Employees,


Maintenance team, Domain Experts,
etc

Techniques used for requirement capturing Interviewing and brain storming

Name of the person along with designation ---

Date 8th November, 2019

Version 1.0

1
Consolidated list of initial requirements:

1. A system is to be implemented which can manage users’ bank account anytime


anywhere.
2. The system shall be able to generate user name and password for the users and
the employees.
3. There are four types of stakeholders: account holders, employee, manager, and
insurance.
4. The manager should be able to maintain all the details of the bank account of all
account holders.
5. The administrator should be able to monitor the transaction activity of account
holders.
6. The account holders can apply for loan to manger.
7. Employee can give loan to the borrower after the application for loan is approved
by the manager.
8. The system should calculate the total amount that has to be paid to bank as
interest and send message to the borrower.
9. The account holders must get notifications regarding any updates like changing of
any policies plan or any new scheme is going to be started.
10. There should be limitations in daily credit and debit for all account holders.
11. The system should be able to calculate the interest for each and every account
holder and update it in the account.
12. The system should notify the account holder in case of credit and debit
immediately.
13. The system should provide the medium to transfer money to other accounts along
with bills transfer like phone bill, electricity bills facilities.
14. In case of technical issues like failed transaction then it must refund the amount.
15. The security and privacy level should be as high as possible because it is concerned
with money.
16. Insurance company can attach itself with any scheme of the bank for better
priviledge to the account holders.

2
Use case approach :

Uses cases and actors are used to define the scope of the system we are planning to build.
Use case incorporate anything that is within the system, but and actors include anything that
is external to the system. We identify actors and use cases for the system under development.
To do this, a proper understanding of the system is essential. A use case is a description of a
system in terms of a sequence of actions.
Actor
An actor is a person, organization, or external system that plays a role in one or more
interactions with your system (actors are typically drawn as stick figures on UML Use Case
diagrams). We can consider following as the main actors of bank management system :

• Super Admin
• Account Holder
• Accountant
• System User
Use Case
A use case is a description of how a person who actually uses that process or system will
accomplish a goal. It's typically associated with software systems, but can be used in reference
to any process. For example, imagine you're a cook who has a goal of preparing a grilled
cheese sandwich. The use case would describe through a series of written steps how the cook
would go about preparing that sandwich. A use case helps you understand where errors could
occur in the process and design features to resolve those errors. Following are the use cases
of a bank management system.

• Manage Customer
• Manage Employee
• Manage Accounts
• Manage Fixed Deposit
• Manage Saving Account
• Manage Users
• Full Banking Management Operations
Relationship
The relationship between and among the actors and use cases of bank management system:

• Super Admin Entity: Use cases of Super Admin are Manage Customer, Manage
Employee, Manage Accounts, Manage Fixed Deposit, Manage Saving Account,
Manage Current Account, Manage Balance, Manage Users and Full Banking System
Operations

3
• System User Entity: Use cases of System User Admin are Manage Customer, Manage
Employee, Manage Accounts, Manage Fixed Deposit, Manage Saving Account,
Manage Balance
• Accountant Entity: Use cases of Accountant are Manage Customer Deposits, Manage
Debit and Credit, Manage Funds
• Account Holder Entity: Use cases of Account Holders are Deposit Payment, View
Balance, Make Transfer

Use case Diagram


A use case diagram is a dynamic or behavior diagram in UML. Use case diagrams model the
functionality of a system using actors and use cases. Use cases are a set of actions, services,
and functions that the system needs to perform. In this context, a "system" is something being
developed or operated, such as a web site. The "actors" are people or entities operating under
defined roles within the system.

4
Manage Users and Full Application

Super
Admin
Manage Customer & Employee

Super
Admin
Manage Debit & Credit

Manage Funds

Log In and Out

Update

Account
System Manage Account Holder
User

Manage Fixed Deposit

Deposit Payment

Make Transfer and View

5
System Requirement Specifications (SRS) Document of Bank Management System

Table of Contents
1. Introduction
1.1 Purpose
1.2 Scope
1.3 Overview
1.4 Additional Information
2. General Description
3. Functional specifications
3.1 Login
3.2 Validation
3.3 Payment of money
3.4 Transfer of money
3.5 Transaction report
4. Interface Requirements
4.1 GUI
4.2 Hardware Interface
4.3 Software Interface
5. Performance Requirements
6. Constraints
7. Performance
7.1 Security
7.2 Reliability
7.3 Availability
7.4 Maintainability
7.5 Reusability
8. References

6
1. Introduction
This document gives detailed functional and non-functional 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 needs 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 in- formation 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:

7
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 system.

2. General description

2.1 Product Perspective:


The client will have client interface in which he can interact with the banking system. 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:


Front End Client:
The system is a web based application clients are requiring using modern web browser such
as Mozilla Firefox 1.5, PHP.
Web Server:
The web application will be hosted on one of the apache server.
Back End:
We use backend as MY SQL.

3. Functional Specifications

8
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 card’s 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

9
Get balance information:
This system must be networked to the bank’s computer. The updated
database of every customer is maintained with bank. Hence the balance information of every
account is available in the database and can be displayed to the customer.

3.3 Payment of Money:


A customer is allowed to enter the amount which he/she wishes to withdraw. If the entered
amount is less than the available balance and if after withdraw if the minimum required
balance is maintained then allow the transaction.

3.4 Transfer of Money:


The customer can deposit or transfer the desired amount of money.

3.5 Transaction Report:


The bank statement showing credit and debit information of corresponding account must be
printed by the machine.

3.6 Technical Issues


This product will work on client-server architecture. It will require an internet server and
which will be able to run PHP applications. The product should support some commonly used
browsers such as Internet Explorer, Mozilla Firefox.

4. Interface Requirements

4.1 GUI
This is interface must be highly intuitive or interactive because there will not be an assistance
for the user who is operating the System. At most of the places help desk should be provided
for users convenience. The screens appearing should be designed in such a manner that it can
draw User attraction towards the new plans for the customers.
Also the pin and password confidentiality should be maintained. This can be done by using
asterisks at the password panel. Proper security messages should be displayed at most of the
places.

10
4.2 Hardware Interface
Various interfaces for the product could be
1. Touch screen/Monitor
2. Keypad
3. Continuous battery backup
4. Printer which can produce the hard copy.
5. Interface that connects the device to bank’s computer.
6. An interface that can count currency notes.

4.3 Software Interface


1. Any windows operating system.
2. The PHP must be installed. For the database handling MYSQL must be installed. These
products are open source products.
3. The final application must be packaged in a set up program, so that the products can be
easily installed on machines. This application must be networked to corresponding banks.

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.

11
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
Application Server/WebSphere Application Server CE Server needs to be installed.

Database design
In our database design, we give names to data flows, processes and data stores. Although the
names are descriptive of data, they do not give details .So following DFD, our interest is to
build some details of the contents of data flows, processes and data store. A data dictionary
is a structured repository of data about data .It is a set of rigorous definitions of all DFD data
elements and data structures .

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
Any information about the account should be quickly available from any computer to the
authorized user. The previously visited customer’s data must not be cleared.

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.

12
7.5 Portability
The application should be portable on any windows based system. It should not be machine
specific.

8. References:
1. www.w3schools.com
2. www.roseindia.net
3. www.dbforums.com
4. Software Engineering by K.K. Aggarwal & Engineering by K.K. Aggarwal &Yogesh
Singh, New Age Publishing Home, 3rd Edition2008
5. IEE Standard for Software Test Documentation- IEEE Std. 829-1998

13

You might also like