BANK CUSTOMER MANGAEMENT SYSTEM

Overview
At present most of the banking applications are yet to overcome the rapidly growing attacks
on their customer private data. Issues suck fraud operating within a conventional
environment. However current systems are still trying to cope with the existing institutional
structure, which is really meant for usual banking system only and not managing their
customer’s information more effectively. Lack of adequate security measure is making it really
challenging to successfully transform the bank customers’ management systems from where
it is now to where it should be. This challenge still lingers. The objective of this project is
devlop a bank customer management system to the best satisfaction of the customer and for
profit maximization to the Banks.

System Requirement Specifications

A Software Requirements Specification (SRS) is a document that describes the nature of a
project, software or application. In simple words, SRS document is a manual of a project
provided it is prepared before you kick-start a project/application. This document is also
known by the names SRS report, software document. A software document is primarily
prepared for a project, software or any kind of application.
There are a set of guidelines to be followed while preparing the software requirement
specification document. This includes the purpose, scope, functional and non functional
requirements, software and hardware requirements of the project. In addition to this, it also
contains the information about environmental conditions required, safety and security
requirements, software quality attributes of the project etc.

Software Requirement Specifications Document

A Software requirements specification document describes the intended purpose,

requirements and nature of a software to be developed. It also includes the yield and cost of
the software.
In this document, bank customer management project is used as an example to explain few
points.

1
System Architecture
Use Case Diagram
Use Case diagram represents the top view of the system. The use cases resides within the
system and actors act from outside the system. The use case diagram is also used to present
functionality of the system, but for proper explanation , it should read along with use cases.
The use case diagram may also be decomposed into further level of abstraction. It also shows
the relationship of use cases and actors. It also explains what happens when an actor interacts
with the system.
An actor is represented by a stick figure and a use case by an oval labelled with the name of
the use case. The relationship between an actor and a use case is shown by an arrow. For

2
small systems, one use case diagram may be sufficient to represent the whole system.
However, for a large system, we may have to draw many use case diagrams to represent
various portions of the system. The use case diagram of the

3
Activity Diagram
Activity diagram describes the flow of control in a system. It consists of activities and
links. The flow can be sequential, concurrent, or branched. Activities are nothing but
the functions of a system. Numbers of activity diagrams are prepared to capture the
entire flow in a system. Activity diagrams are used to visualize the flow of controls in
a system. This is prepared to have an idea of how the system will work when
executed.

4
Sequence Diagram
A sequence diagram is an interaction diagram. From the name, it is clear that the
diagram deals with some sequences, which are the sequence of messages flowing
from one object to another.
Interaction among the components of a system is very important from implementation
and execution perspective. Sequence diagram is used to visualize the sequence of
calls in a system to perform a specific functionality.

5
Class Diagram
Class diagrams are the most common diagrams used in UML. Class diagram consists
of classes, interfaces, associations, and collaboration. Class diagrams basically
represent the object-oriented view of a system, which is static in nature.
Active class is used in a class diagram to represent the concurrency of the system.
Class diagram represents the object orientation of a system. Hence, it is generally
used for development purpose. This is the most widely used diagram at the time of
system construction.

6
Software Specification Analysis
A system requirements analysis is a complete description of the behavior of the system to
be developed. It includes a set of use cases that describe all of the interactions that the users
will have with the system. In addition to use cases, the system requirement analysis contains
functional requirements, which define the internal workings of the system: that is, the
calculations, technical details, data manipulation and processing, and other specific
functionality that shows how the use cases are to be satisfied. It also contains nonfunctional
requirements, which impose constraints on the design or implementation (such as
performance requirements, quality standards or design constraints).
The requirement is a complete description of the behavior of the system to be developed.
These requirements include: functional and non-functional requirements.
Functional Requirements:
A functional requirement defines the internal workings of the system: that is, the calculations,
technical details, data manipulation and processing, and other specific functionality that
shows how the use cases are to be satisfied. The functionalities ofthe system or modules are
mean what the system supposes to do.

For admin Module

1. This system allows the admin to login with username and password
2. This system allows the admin to add a Bank branch details
3. This system allows the admin to accept or reject a manager/customer
4. This system allows the admin to approve or reject customer transaction request

7
5. This system allows the admin to View Managers & Customers details
For Manager Module
1. This system allows the manager to register
2. This system allows the manager to login with email and password
3. This system allows the manager to accept/reject branch customers
4. This system allows the manager to view customer transactions
5. This system allows the manager to update personal information
6. This system allows the manager to reset password if password is forgotten
For Customer Module
1. This system allows the customer to login with email and password
2. This system allows the customer to update personal details
3 This system allows the customer to reset password if password is forgotten
4. This system allows the customer to view his/her account balance
5. This system allows the customer to transfer money from his account to another account
6. This system allows the customer to recover password
7. This system allows the customer to change password
8. This system allows the customer to delete profile
9. This system allows the customer to choose image point.
Non-functional requirement is a requirement that specifies criteria that can be used to judge
the operation of a system, rather than specific behaviors. It is about how the system supposes
to be and specify the quality of the system, is mostly related to the satisfaction of the user,
example minimum acceptable page load time.
Some of these non-functional requirements are:
1. Integrity
2. Usability
3. Maintainability
Integrity: Integrity testing is basically a type of software testing that is done to check whether
the application or the product is secured or not. It checks to see if this application is vulnerable
to attacks, if anyone hack the system or login to the application without any authorization. It
is a process to determine that an information system protects data and maintains
functionality as intended. The security testing is performed to check whether there is any
information leakage in the sense by encrypting the application or using wide range of

8
software’s and hardware’s and firewall etc. For example this online bank application can allow
the users to login and carry out transaction but not to edit their account balance. As only
when a transaction occurs their account balance should be automatically update.
Usability: This has to do with black box testing, but relating it to white box testing, usability
testing is a very wide area of testing and it needs fairly high level of understanding of this field
along with creative mind. People involved in the usability testing are required to possess skills
like patience, ability to listen to the suggestions, openness to welcome any idea, and the most
important of them all is that they should have good observation skills to spot and fix the issues
or problems. As soon as the user problems are identified, if such problem arises from the
internal mechanism of the product then white box testing strategy can help to identify and
fix those problems.
Maintainability: It basically defines that how easy it is to maintain the system. This means
that how easy it is to analyses, change and test the application or product. Maintainability
testing shall use a model of the maintainability requirements of the software product. The
maintainability testing shall be specified in terms of the effort required to effect a change
under each of the following four categories:
1. Corrective maintenance: Deals with correcting problems. The maintainability of a system
can be measured in terms of the time taken to diagnose and fix problems identified within
that system.
2. Perfective maintenance: This deals with system enhancements. The maintainability of a
system can also be measured in terms of the effort taken to make required enhancements to
that system. This can be tested by recording the time taken to achieve a new piece of
identifiable functionality such as a change to the database, etc. A number of similar tests
should be run and an average time calculated. The outcome will be that it is possible to give
an average effort required to implement specified functionality. This can be compared against
a target effort and an assessment made as to whether requirements are met.
3. Adaptive maintenance: Adapting to changes in environment. The maintainability of a
system can also be measured in terms on the effort required to make required adaptations
to that system. This can be measured in the way described above for perfective
maintainability testing.
4. Preventive maintenance: Actions to reduce future maintenance costs. This refers to
actions to reduce future maintenance costs and to maximize profit while reducing cost. It also
important to note that maintainability deals with; modular structure of software, internal
program documentation, Programmers manual typical requirements, Code to company
standards and guidelines

9
Unit Testing
A unit involves the smallest testable part of software. It usually has one or a few inputs and
usually a single output .
White box testing strategy:
This is a testing strategy where developers takes into account the internal mechanism of a
system, application or component to check if the source code is working as expected or not.
The white box testing strategy incorporate coverage of the code written, branches, paths,
statements and internal logic of the code, etc. However, in order to implement white box
testing strategy, the tester has to deal with the code, and hence is required to possess
knowledge of coding and logic i.e., internal working of the code. It also called structural
testing, glass box testing or clear box testing. For example; when a developer develops an
application (like this Bank customer management system), the developer first of all tests all
the components by examining each line of code and also integrates all the components
together and test them to check if the system has any error, during the implementation stage
if there is any error the developer must start all over again by checking and tracing the cause
of the error.
Black box testing strategy:
It is a testing strategy in which the functionality of the software is tested without any
reference to the internal design, code, or algorithm used in the program. Black box testing
strategy ignores the internal mechanism of a system or component and focuses solely on the
outputs generated in response to selected inputs and execution conditions. A testing strategy
without having any knowledge of the internal workings of the application is Black Box testing
strategy. The tester is oblivious to the system architecture and does not have access to the
source code. Typically, when performing a black box test, a tester will interact with the
system's user interface by providing inputs and examining outputs without knowing how and
where the inputs are worked upon. It is also called functional testing.

10