CUSTOMER INFORMATION MANAGEMENT

SYSTEM
For

MODELING AND DESIGN LAB (MBAB 707)

PROJECT REPORT

Submitted by

RATNABABU BOLIMERA REGISTER NO: 14381050

DEPARTMENT OF BANKING TECHNOLOGY

PONDICHERRY UNIVERSITY

PUDUCHERRY-605014

MARCH 2021
 DEPARTMENT OF BANKING TECHNOLOGY

SCHOOL OF MANAGEMENT PONDICHERRY

UNIVERSITY PUDUCHERRY-605014

BONAFIDE CERTIFICATE

This is to certify that the project work entitled” CUSTOMER INFORMATION

MANAGEMENT SYSTEM” is a bonafide work done by RATNABABU BOLIMERA
(REGISTER NO: 14381050) in fulfillment of the requirement, for the award of MBA-
BANKING TECHNOLOGY by Pondicherry University during the academic year 2021.

PROJECT GUIDE HEAD OF THE DEPARTMENT

Submitted for the University Examination held on ………………………..

INTERNAL EXAMINER EXTERNAL EXAMINER

 TABLE OF CONTENTS

CHAPTER NO TITLE PAGE NO

ABSTRACT i

LIST OF FIGURES ii

LIST OF ABBREVIATIONS iii

1. PROBLEM DEFINITION
1.1 EXISTING SYSTEM 1
1.2 DRAWBACKS OF EXISTING SYSTEM 1
1.3 PROPOSED SYSTEM 2
1.4 FEATURES OF PROPOSED SYSTEM 2
1.5 FEASIBILITY STUDY 2
2. SOFTWARE REQUIREMENTS SPECIFICATION
2.1 INTRODUCTION 4
2.1.1 PURPOSE 4
2.1.2 SCOPE 4
2.1.3 DEFINITIONS 4
2.1.4 OVERVIEW 5

2.2 GENERAL DESCRIPTION 5

2.2.1 PRODUCT PERSPECTIVE 5
2.2.2 PRODUCT FUNCTIONS 6
2.2.3 USER CHARACTERISTICS 6
2.2.4 GENERAL CONSTRAINTS 6
2.2.5 ASSUMPTIONS AND DEPENDENCIES 6

2.3 SPECIFIC REQUIREMENTS 6

2.3.1 FUNCTIONAL REQUIREMENTS 6
 2.3.2 EXTERNAL INTERFACES REQUIREMENTS 8
2.3.3 PERFORMANCE REQUIREMENTS 8
2.3.4 DESIGN CONSTRAINTS 9
2.3.5 ATTRIBUTES 9
2.3.6 OTHER REQUIREMENTS 10

2.4 SYSTEM DIAGRAM 11

3. OBJECT ORIENTED ANALYSIS
3.1 USE CASE DIAGRAM 12
3.2 ACTIVITY DIAGRAM 14
3.3 SEQUENCE DIAGRAM 15
4. OBJECT ORIENTED DESIGN
4.1. CLASS DIAGRAM 17
4.2 PATTERNS IDENTIFIED 19
4.3 PACKAGE DIAGRAM 20
4.4 COLLABORATION DIAGRAM 21
5. IMPLEMENTATION

5.1 COMPONENT DIAGRAM 23

5.2 DEPLOYMENT DIAGRAM 25
6. TESTING
6.1 TEST PLAN 27
6.1.1 UNIT TESTING 27
6.1.2 INTEGRATION TESTING 28

7. CONCLUSION & FUTURE ENHANCEMENT 31

 ABSTRACT

This Customer Information Management system provides an easy, convenient and

secure mechanism for the transfer of accounts or change in the addresses of the customers. This

system reduces the over delay, burden and complexity on the process. Apart from the traditional

procedures, this eliminates the paper work, physical presence of the customers. This system

provides security mechanisms such as OTP, Email Alerts and tracking system of the process.

Easy to use and operate by the account holders (Customers) as well as the staff (Bank

Employees) / administrators. By using the time stamp mechanism the system will store the

previous details of the customers in the database. We can provide the rollback mechanism also if

the customer desired to change to his/her previous details.

i
 LIST OF FIGURES

FIGURE NO FIGURE NAME PAGE NO

2.1 System Diagram 11

3.1 System Use Case Diagram 13

3.2 Activity diagram 14

3.3 Sequence Diagram (Success) 16

3.4 Sequence Diagram (Failed) 16

4.1 Class Diagram 18

4.2 Package Class Diagram 20

4.3 Collaboration Diagram (Failed) 22

4.4 Collaboration Diagram (Success) 22

5.1 Component Diagram 24

5.2 Deployment Diagram 26

ii
 LIST OF ABBREVIATIONS

CIMS - Customer Information Management System

PHP - Hypertext Preprocessor.

XML - Extensible Markup Language

GUI - Graphical User Interface

HTML - Hyper Text Markup Language.

JS - Java Script

JQuery / AJAX Java Query / Asynchronous JavaScript and XML

iii
 CHAPTER 1

PROBLEM DEFINITION

CIMS is an acronym for “Customer Information Management system” which

provides an easy, convenient and secure mechanism for the transfer of accounts or change in
the addresses of the customers. This system reduces the over delay, burden and complexity
on the process. Apart from the traditional procedures, this eliminates the paper work, physical
presence of the customers.

1.1 EXISTING SYSTEM

The existing system is purely a manual based system which is used to update all the
information about the customers manually, so there may be a large delay in the updating of
the details of a customer whenever need. Hence it takes more time to update the details. This
might be treated as confidential information but it may not.

Customer identification means identifying the customer and verifying his/her identity
by using reliable, independent source documents, data or information. Banks have been
advised to lay down Customer Identification Procedure to be carried out at different stages
i.e. while establishing a banking relationship; carrying out a financial transaction or when the
bank has a doubt about the authenticity/veracity or the adequacy of the previously obtained
customer identification data.

1.2 DRAWBACKS OF EXISTING SYSEM

The main drawback of the existing system is not user friendly. Since the existing
system is manual based it is not secure and it might be used in a wrong manner. Mainly for
getting the service like Updating the address or Transfer of Accounts the customer has to visit
the branch directly. That will consume more time and causes inconvenience to the customers.
The main disadvantages are much delay also customer’s physical presence is needed. It will
cause inconvenience to the customers.
1.3 PROPOSED SYSTEM

Our proposed system us fully atomized system which enables the customers to place a
request for updating the addresses or transferring of accounts through online. It will reduce
the burden and provides the simple and efficient mechanism for customers with status
tracking facility. This is a speedy and efficient mechanism.

1.4 FEATURES OF PROPOSED SYSTEM

 Transfer or updating of the account at any time (24x7).

 Email alerts and OTP are provided.
 By which the system can avoid misuse of this service by the intruders and can restrict
the unauthorized access to others.
 Portable system

1.5 FEASIBILITY STUDY

The feasibility study is basically the test of the proposed system in the light of the
workability, meeting user requirements, effective use of resources and the need effectiveness.
It is most vital point for developing the new system.

The objective of feasibility is to solve the problem of time bound announcement and
reach the user quickly and efficiently. The system is to consider feasible only if the proposed
system is useful and is determined at the preliminary investigation stage.

Thus the purpose of the feasibility is to gather, analyse and document the data needed
to make an informal intelligent decision regarding system’s practicability. There are three
aspect of feasibility study of the preliminary investigation.

The feasibility study concerns with the consideration made to verify whether the
system is fit to be developed in all terms. The feasibility study is basically the test of the
proposed system in light of its workability, meeting user’s requirement, effective use of the
resources and of course the cost effectiveness. The main goal of feasibility study is the cost
and benefits are estimated with greater accuracy.

The feasibility study is an important factor in analysing the capability of the project.
The key objective is to weigh up three types of feasibility. They are:
  Operational feasibility

 Technical feasibility

 Economic feasibility

Operational feasibility:

Operational feasibility ensures that the project developed is successfully implemented

in the distributed environment. The Operational feasibility is very high as it is user-friendly,
easy to use and found to be beneficial environment.

Technical feasibility:

This system involves the general user-friendly windows environment, so our system
works with Cross platform. This project is technically easier even though a new user can
easily work with this project with little instruction.

Economic feasibility:

This system is feasible in economic aspects; this system requires very easy technique
and minimal software. So it does not need much cost and software. So, it can be used in any
environment.
 CHAPTER 2

SOFTWARE REQUIREMENTS SPECIFICATION

2.1 INTRODUCTION

2.1.1 Purpose

This SRS document stands as an agreement between the customer and the
designer/developer concerning the functional and non-functional requirements that the
proposed CIMS system should exhibit.

2.1.2 Scope

This document will be referred throughout the project life cycle right from the design
phase to the implementation phase. This document defines the final state of system's
requirements, both functional and non-functional, agreed upon by the customers and
developers. This document may be referred in case of any confusion or conflict that may
occur to either the customers or the developers. Finally at the end of the project execution, all
the functionalities of the product must be traceable right from the SRS to the implementation
stage.
In terms of usability, the scope of this document extends to customer and
designer/developer. The document should be made available for reference on demand.

2.1.3 Definitions

 CIMS - CIMS is the Customer Information Management System is which is used to

maintain the Customer Information and enable the customer to make updates by
authorization in two level security mechanisms.
 PHP – PHP is a server-side scripting language designed for web development but
also used as a general-purpose programming language. As of January 2013, PHP was
installed on more than 240 million websites (39% of those sampled) and 2.1 million
web servers. Originally created by Rasmus Lerdorf in 1994, the reference
implementation of PHP (powered by the Zend Engine) is now produced by The PHP
Group. While PHP originally stood for Personal Home Page, it now stands for PHP:
 Hypertext Preprocessor, which is a recursive backronym. Server-side scripting
language is similar to JavaScript in many ways, as they both allow you to embed little
programs (scripts) into the HTML of a Web page. In executing, such scripts allow you
to control what will actually appear in the browser window in some way more flexible
that what is possible using straight HTML. PHP lets us insert instructions into our
web pages that our Web server software (be it Apache, Personal Web Server, or
whatever) will execute before sending those pages to a browser that requests them.
 SQL-Structured Query Language or SQL (pronounced either "sequel" or "ess-cue-
ell"--take your pick). Commands in SQL are also called queries. SQL is the standard
language for interacting with most databases, so even if we move from MySQL to a
database like Microsoft SQL Server in the future, we'll find that most of the
commands are identical. It's important that we understand the distinction between
SQL and MySQL. MySQL is the database server software that we're using. SQL is
the language that we're using to interact with the database.
 MySQL- A database server (in our case, MySQL) is a program that can store large
amounts of information in an organized format that is easily accessible from scripting
languages like PHP.

2.1.4 Overview

The SRS document for the CIMS system covers the following
 General Description: This section describes the general functionality of the CIMS
system, as desired by the customer in common terms.
 Specific Requirements: This section describes about both the functional and non-
functional requirements of the system. The Functional Requirement section defines
the requirement specifications from functionality viewpoint while the Non-
Functional Requirements - external interface, performance, etc. are dealt in detail in
corresponding sub-sections.

2.2 GENERAL DESCRIPTION

2.2.1 Product Perspective

 User's Perspective: The system provides a friendly working environment where end
users, moderators and also the administrator can work without having any querying or
 database knowledge through its attractive interface.
 Developer's Perspective: The system provides easy developments since the
technologies we are using are open source and platform independent. Also it reduces
the time of developing due to its re-usability, availability and flexibility.

2.2.2 Product Functions

 To provide a user-friendly GUI environment to work in

 To provide an Input Output Control System
 To provide a File, Directory and Storage manager
 The system should break the barrier of Platform and it must be Portable across various
Platforms

2.2.3 User Characteristics

 The CIMS users need not to be familiar with the query language.

2.2.4 General Constraints

 Hardware constraints
The system should run only on machines with Pentium 486 (or above) processors and
32MB (or more) RAM.
 Software Constraints
In the front-end we are using HTML, JS, PHP, AJAX/JQuery and MySQL as back-
end.
2.2.5 Assumptions and Dependencies

 The system will work on any devices which allow networking with browsing facility.
 We can run the same application in a system simultaneously.
 Like any other system, tampering the system files may render the system useless

2.3 SPECIFIC REQUIREMENTS

2.3.1 Functional Requirements

2.3.1.1 Interface Manager

The Interface Manager or the IM will be the foundation of the GUI of the system. The
desktop, as it will be called, will provide shortcuts and menus for all the applications
supported by the CIMS system. It will also provide a mechanism through which the user will
be able to select the options for the working environment to work.

2.3.1.2 AJAX

Asynchronous JavaScript + XML in short Ajax is a group of interrelated Web

development techniques used on the client-side to create asynchronous Web applications.
With Ajax, Web applications can send data to and retrieve from a server asynchronously (in
the background) without interfering with the display and behavior of the existing page. Data
can be retrieved using the XML Http Request object. Despite the name, the use of XML is
not required; JSON is often used instead, and the requests do not need to be asynchronous.

Ajax is not a single technology, but a group of technologies. HTML and CSS can be
used in combination to mark up and style information. The DOM is accessed with JavaScript
to dynamically display – and allow the user to interact with – the information presented.
JavaScript and the XML Http Request object provide a method for exchanging data
asynchronously between browser and server to avoid full page reloads.

2.3.1.3 JQuery

JQuery is a cross-platform JavaScript library designed to simplify the client-side

scripting of HTML. Used by over 60% of the 10,000 most visited websites, j Query is the
most popular JavaScript library in use today. J Query is free, open source software, licensed
under the MIT License.

JQuery's syntax is designed to make it easier to navigate a document, select DOM

elements, create animations, handle events, and develop Ajax applications. JQuery also
provides capabilities for developers to create plug-ins on top of the JavaScript library. This
enables developers to create abstractions for low-level interaction and animation, advanced
effects and high-level, theme-able widgets. The modular approach to the jQuery library
allows the creation of powerful dynamic web pages and web applications.
2.3.1.4 Storage Manager

The system will provide a facility to store/retrieve the customer information on/from
the secondary storage.

2.3.2 External Interfaces Requirements

2.3.2.1 System Interfaces

The proposed CIMS system in PHP will interact with PHP Command Line Interface.
As the name implies, this is a way of using PHP in the system command line. Or by other
words it is a way of running PHP Scripts that aren't on a web server (such as Apache web
server or Microsoft IIS).

2.3.2.2 User Interfaces

The CIMS system will provide an interactive GUI interface with multilingual
features. It will function similar to the popular Windows Operating System, having a desktop
from which various applications may be launched.

2.3.3 Performance Requirements

Performance of the CIMS system depends on the following factors

 Storage: MySQL or any other SQL server as MSSQL or Oracle, stored procedures
increase dramatically the speed of the queries involved because this are already
compiled. Stored procedures are more secure than direct queries and as object in the
database they can be administered by the owner, giving the right access to each user.

 Using stored procedures you can also hide the logic of the queries and procedures and
give to the development team and other programmers a "black box" in which they
insert data and receive results.

SPECS
Generator
Bra ille I/P

Bra ille I/P

2.3.4 Design Constraints

2.3.4.1 Hardware Constraints

The system will run on machines with 32MB RAM (or above), running 32-bit
Operating System (or above).

2.3.4.2 Memory Constraints

 The system will be loaded over the underlying operating system, which may limit the
memory available to the CIMS system.
 The system will also require considerable amounts of memory to load various map
files at run time for attaining multilingual characteristics.
2.3.5 Attributes

The various attributes of the system are as follows.

 Efficiency: The amount of computing code and resources required by a program to

perform its functions.
 Maintainability: The minimum effort required for locating and fixing an error in a
program.
 Portability: The ease with which the program can be transferred from one platform to
another.
 Reliability: The extent to which a program can be expected to perform its intended
function with required precision.
 Security: The availability of mechanisms to control or protect the consistent state of
the Customer Information.
 Usability: The minimum effort required for learning, operating, preparing input and
interpreting output of a program.
Attribute High Medium Low

Efficiency X
Maintainability X
Portability X
Reliability X
Security X
Usability X
2.3.6 Other Requirements

2.3.6.1 User Documentation

A complete documentation of the system will be provided. Ease of understanding the

documentation will be a very important consideration in its preparation. The documentation
will contain
 Step by step procedure.
 How to handle OTP.
 Working guidelines.

2.3.6.2 Training

Users familiar with the Windows Operating System will find it very easy to work with
the CIMS system due to the similarity in its look and feel with the Windows Operating
System.

2.3.6.3 Object Reuse

The system will be designed using the object-oriented paradigm. Hence reusability is
inherent and future modifications and enhancements can be easily incorporated using class
and object reuse.
2.4 System Diagram

Fig. No. 2.1 System Diagram

 CHAPTER 3

OBJECT ORIENTED ANALYSIS

3.1 USE CASE DIAGRAM

Use case diagrams provide a way of describing the external view of the system and its
interactions with the outside world. In this way it resembles the context diagram of traditional
approaches. In this representation the outside world is represented as actors. And also in
addition to the links among actors and use cases, there are two other types of links called
include and extends, they represent include and extends relationships among use cases.

In this Use Case Diagram Customer is a Primary actor who can login into the system,
check account details and send request for updating of address and bank details then staff
receives the request verify and forward that request to administrator. Admin verifies and
update it in Customer database.

Insurance person can check the liabilities of Customer from customer data base for
offering loans.
Fig. No. 3.1 System Use Case Diagram
3.2 ACTIVITY DIAGRAM

Activity diagrams are one of several ways you can model the dynamics of a system.
The activity diagram focuses on activities, chunks of process that may or may not correspond
to methods or member functions, and the sequencing of these activities. In this sense it is like
a flow chart. It differs, however, from a flow chart in that it explicitly supports parallel
activities and their synchronization. You can show sequential and/or concurrent steps of a
process, model business workflows, model the flow control of an operation, or the flow of an
object as it passes though different states at different points in a process.

Fig. No. 3.2 Activity Diagram

3.3 SEQUENCE DIAGRAM
Sequence diagrams show a detailed flow for a specific use case or even just part of a
specific use case. They are almost self-explanatory; they show the calls between the different
objects in their sequence and can show, at a detailed level, different calls to different objects.

A sequence diagram has two dimensions: The vertical dimension shows the sequence of
messages/calls in the time order that they occur; the horizontal dimension shows the object
instances to which the messages are sent.

Focus of Control:
Focus of Control (FOC) is an advanced notational technique that enhances sequence
diagrams. It shows the period of time during which an object is performing an action, either
directly or through an underlying procedure.

Link:
Objects interact through their links to other objects. A link is an instance of an
association, analogous to an object being an instance of a class. one object may send
messages to another.

Message/Event:
A message is the communication carried between two objects that triggers an event. A
message carries information from the source focus of control to the destination focus of
control.
 Fig. No. 3.3 Sequence Diagram for Verification (Success)

The above diagram shows the flow of system in which submitted documents by
customer are valid and then the details are updated.

Fig. No. 3.4 Sequence Diagram for Verification (Failed)

The above diagram shows the flow of system in which submitted documents by
customer are invalid and then the Request is rejected.
 CHAPTER 4
OBJECT ORIENTED DESIGN

4.1. CLASS DIAGRAM

The system static structure can be documented by class diagram. All system life time
can be shown on a links (associations) between classes with their operations, attributes, and
names. Class diagram define as a rectangular boxes .This boxes initially contain sections.
First section gives for class name (or object name), second one contains the class attributes,
and the bottom section for methods (operations) associated with the class as shown below.

You will usually create several Class diagrams for a single system. Some will display
a subset of the classes and their relationships. Others might display a subset of classes,
including their attributes and operations. Still others may display only the packages of classes
and the relationships between the packages. You can create as many Class diagrams as you
need to get a full picture of your system.

By default, there is one Class diagram, called Main, directly under the Logical View
entry. This Class diagram displays the packages of classes in your model. Inside each
package is another diagram called Main, which includes all of the classes inside that package.
In Rose, double-clicking a package in a Class diagram will automatically open its Main Class
diagram. If a Main Class diagram does not exist, double-clicking the package will create it.
Fig. No. 4.1 Class Diagram
4.2 PATTERNS IDENTIFIED

Patterns used in our system are

 Singleton Pattern
 Abstract Factory

Singleton Pattern

The singleton pattern is one of the simplest design patterns: it involves only one class
which is responsible to instantiate itself, to make sure it creates not more than one instance; in
the same time it provides a global point of access to that instance. In this case the same
instance can be used from everywhere, being impossible to invoke directly the constructor
each time.

In our system administrator class follows singleton pattern because this class has
only one instance and provide a global point of access to the object.

Abstract Factory Pattern

The Abstract Factory class is the one that determines the actual type of the concrete object
and creates it, but it returns an abstract pointer to the concrete object just created. This determines the
behaviour of the client that asks the factory to create an object of a certain abstract type and to return
the abstract pointer to it, keeping the client from knowing anything about the actual creation of the
object

In our system public class follows Abstract Factory pattern because it provides interface for
creating a family of related objects, without explicitly specifying their classes.
4.3 PACKAGE DIAGRAM

A package diagram in the Unified Modeling Language depicts the dependencies

between the packages that make up a model.

Fig. No. 4.2 Package Class Diagram

4.4 COLLABORATION DIAGRAM

A Collaboration Diagram shows an interaction between objects and the context of the
context of the interaction in terms of the links between the objects.

Collaboration Diagram

Focus of Control:
Focus of Control (FOC) is an advanced notational technique that enhances sequence
diagrams. It shows the period of time during which an object is performing an action, either
directly or through an underlying procedure.

Link:
Objects interact through their links to other objects. A link is an instance of an association,
analogous to an object being an instance of a class. one object may send messages to another.

Message/Event:
A message is the communication carried between two objects that triggers an event. A
message carries information from the source focus of control to the destination focus of
control.
Fig. No. 4.3 Collaboration Diagram for Verification (Failed)

Fig. No. 4.4 Collaboration Diagram for Verification (Success)

 CHAPTER 5

IMPLEMENTATION

5.1 COMPONENT DIAGRAM

A component diagram provides a physical view of the system. Its purpose is to show
the dependencies that the software has on the other software components (e.g., software
libraries) in the system. The diagram can be shown at a very high level, with just the large-
grain components, or it can be shown at the component package level.

A component represents a software module (source code, binary code, executable,

DLL, etc.) with a well-defined interface. The interface of a component is represented by one
or several interface elements that the component provides. Components are used to show
compiler and run-time dependencies, as well as interface and calling dependencies among
software modules. They also show which components implement a specific class.

A Component diagram depicts how components are wired together to form large
components and or software systems. They are used to illustrate the structure of arbitrarily
complex system.

We have the following components involved in the CIMS:

 Registration form
 Login form
 Update Request form
Fig. No. 5.1 Component Diagram
5.2 DEPLOYMENT DIAGRAM

The deployment diagram shows how a system will be physically deployed in the
hardware environment. Its purpose is to show where the different components of the system
will physically run and how they will communicate with each other. Since the diagram
models the physical runtime, a system's production staff will make considerable use of this
diagram.

client web database

browser

The nodes appear as boxes, and the artifacts allocated to each node appear as
rectangles within the boxes. Nodes may have sub nodes, which appear as nested boxes. A
single node in a deployment diagram may conceptually represent multiple physical nodes,
such as a cluster of database servers.
There are two types of Nodes:
o Device Node
o Execution Environment Node
Device nodes are physical computing resources with processing memory and services
to execute software, such as typical computers or mobile phones.
An execution environment node (EEN) is a software computing resource that runs
within an outer node and which itself provides a service to host and execute other executable
software elements
Fig. No. 5.2 Deployment Diagram
 CHAPTER 6
TESTING

Testing is a set of activities that can be planned in advance and conducted

systematically testing requires that the developer discard preconceived notations of the
correctness of the software just developed and overcome a conflict of interest that occurs
when errors are encountered. Testing is a process of technical investigation, performed on
behalf of stakeholder that is intended to reveal quantity related information about the product
with respect to the context in which it is intended to operate.

6.1 TEST PLAN

Before applying methods to design effective test case, a software engineer must
understand the basic principle that guides software testing. Test plan will describe about the
scope and activities of our modules in the project. We must plan the test plans in the starting
of our project. It will provide a unique identifier for our document.

6.1.1 Unit testing

Unit testing is a method by which individual units of source code are tested to
determine if they are fit for use. A unit is the smallest testable part of an application. In
procedural programming a unit could be an entire module but is more commonly an
individual function or procedure. In object-oriented programming a unit is often an entire
interface, such as a class, but could be an individual method. Unit tests are created by
programmers or occasionally by white box testers during the development process.

6.1.1.1 Test cases

Test case for login page

In login module, there is a rule is some field are mandatory, so it can’t be

empty. Any alert message should be pop-up to intimate the fields are empty.

 Test case: user name, password and conform password should not empty.
Error message: please enter user name, password and confirm password
  Test case: password and confirm password should be same.
Error : if both password and confirm password is not same.

Error message: please check that confirm password does not match.

Test case for customer registration

 Test case: user name, password and conform password should not empty.
Error message: please enter user name, password and confirm password

 Test case: password and confirm password should be same.

Error : if both password and confirm password is not same.

Error message: please check that confirm password does not match.

 Test case: user name should be empty

Error message: please enter a user name

6.1.2 Integration testing

The purpose of integration testing is to verify functional, performance, and reliability

requirements placed on major design items. These "design items", i.e. assemblages (or groups
of units), are exercised through their interfaces using Black box testing, success and error
cases being simulated via appropriate parameter and data inputs. Simulated usage of shared
data areas and inter-process communication is tested and individual subsystems are exercised
through their input interface.

Test cases are constructed to test that all components within assemblages interact
correctly, for example across procedure calls or process activations, and this is done after
testing individual modules, i.e. unit testing. The overall idea is a "building block" approach,
in which verified assemblages are added to a verified base which is then used to support the
integration testing of further assemblages.

6.1.2.1 Test cases

In this project, integration is done right from page to contact us page. After integrating
all modules it should uncover all errors and procedure a proper result. The registered admin
and member can only access the feature of the site.
Test case for end user:

If the user is just visiting our website then he /she can access only the home page.

Test case for login:

If the user has registered into our website they will be provided with an user id

And using that they can access their account.

6.1.3 Validation testing

Software validation testing is essentially a task carried out by a software tester.

The aim is to check, if the software has been made in lines with the requirements of the
client. In this article, we will talk about software validation testing in detail

6.1.3.1 Test case for end user:

If the user is just visiting our website then he /she can access only the home page.

Test case for login:

If the user has registered into our website they will be provided with a user id

And using that they can access their account.

 CHAPTER 7
CONCLUSION & FUTURE ENHANCEMENT

Our proposed system is a fully automated system aimed for time and cost saving also
the convenience of the customer. It provides the accuracy of the information to the maximum
extent as it involves no clerical entry of the data. i.e clerical mistakes will avoided. It enables
the customers and bank clerks to work in a friendly interactive user interface. Thus the
project has been partially fulfilled with maximum requirements of the user.

It can be further implemented with many other features which provide the
convenience to the customers as well as the bank employees. IVRS and SMS based
transferring can also possible to implement with certain Hardware and software changes.