Software engineering micro project

Project: - Bank management system

1. Process model used for the project

 Water fall model
Explanation:-
Requirements Gathering and Analysis

In this phase the requirements are gathered by the business analyst and they are
analyzed by the team. Requirements are documented during this phase and
clarifications can be sought.

The Business Analysts document the requirement based on their discussion with the
customer.

Going through the requirements and analyzing them has revealed that the project team
needs answers to the following questions which were not covered in the requirements
document –

 Will the new banking application be used in more than one country?
 Do we have to support multiple languages?
 How many users are expected to use the application? etc

System Design

The architect and senior members of the team work on the software architecture, high
level and low level design for the project.

It is decided that the banking application needs to have redundant backup and failover
capabilities such that system is accessible at all times.

The architect creates the Architecture diagrams and high level / low level design
documents.

Implementation

The development team works on coding the project.

They take the design documents / artifacts and ensure that their solution follows the
design finalized by the architect.

Since the application is a banking application and security was a high priority in the
application requirements, they implement several security checks, audit logging
features in the application.
They also perform several other activities like a senior developer reviewing the other
developers code for any issues. Some developers perform static analysis of the code.

Testing

The testing team tests the complete application and identifies any defects in the
application.

These defects are fixed by the developers and the testing team tests the fixes to ensure
that the defect is fixed.

They also perform regression testing of the application to see if any new defects were
introduced.

Testers with banking domain knowledge were also hired for the project so that they
could test the application based on the domain perspective.

Security testing teams were assigned to test the security of the banking application.

Deployment

The team builds and installs the application on the servers which were procured for
the banking application.

Some of the high level activities include installing the OS on the servers, installing
security patches, hardening the servers, installing web servers and application servers,
installing the database etc.

They also co-ordinate with network and IT administrative teams etc to finally get the
application up and running on the production servers.

Maintenance

During the maintenance phase, the team ensures that the application is running
smoothly on the servers without any downtime.

Issues that are reported after going live are fixed by the team and tested by the testing
team.
  V model

Explanation: - In the V model, the testing phase and development phase are
designed in such a way that they are planned parallel to each other.

So if we take alphabet V there is validation on one end and verification on the other
end and the joining point of the both is the coding phase.
 In this, the software testing starts at the beginner level right after writing of
requirements.

Let us have a look at what is verification and validation.

Validation:  It has static analysis or the review technique used without executing code
usage. In this stage, the whole thing is about evaluating the product development to
find out whether specified requirements of the client are met.
Verification: It involves the dynamic analysis of functional as well as non-functional
software, testing is done with the help of executing code. It evaluates the software
prepared in the developmental stage to check whether they meet the customer
expectation or not.
The testing phase of the V model may include:
1. Unit testing:

It is developed in the model designing phase, to eliminate any bug if present.

2. Integration testing:

It is performed after completion of unit testing and in this modules are integrated into
the system to be tested. This verifies the communication aspect.
3. System testing:

It looks after the functional and non-functional requirements.

4. User acceptance testing(UAT):

It is performed in the user environment that simply resembles the production unit, in
this step it is made sure that the software is ready to be used in the real world.
 Incremental process model

Explanation:-

 This model can be used when the requirements of the complete

system are clearly defined and understood.
 Major requirements must be defined; however, some details can
evolve with time.
 There is a need to get a product to the market early.
 A new technology is being used
 Resources with needed skill set are not available
 There are some high risk features and goals.
2. SRS FOR 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.1Login

3.2Validation
3.3Payment of money

3.4Transfer of money

3.5Transaction report

4. Interface Requirements

4.1 GUI

4.2 Hardware Interface

4.3 Software Interface

5. Performance Requirements

6. Constraints

7 Performance

7.1Security

7.2 Reliability
7.3 Availability

7.4 Maintainability

7.5 Reusability

8. Reference

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 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:

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:

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

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

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

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

7.5 Portability

The application should be portable on any windows based system. It should not
be machine specific.
 8 References:

www.w3schools.com

www.roseindia.net

www.dbforums.com

www.ibm.com

http://tomcat.apache.org/

3. System architecture and details

This section will produce a comprehensive comparison between the earlier
selected SOA and OO architectural styles. Several software quality factors
which are critical to this project will be used to assess both architectural
styles in order to select an appropriate one. The most suitable style will be
adopted throughout the development lifecycle to deliver a solution to the
client.

Software Quality Factors Analysis Software quality assesses the quality of

the design of the system as well as the quality of conformance to that
design. An architectural design has a direct impact on the Quality of Service
(QoS), for example; coupling affects maintainability and reusability. This
suggests that a correctly selected architecture can have a positive impact
on QoS during the early stages of the development lifecycle. Zhu (2005,
p.33)statesthat errors made during the design of the architecture can be
costly and maybe impossible to rectify at a later stage. There are countless
software quality factors available presently. These factors are reflect
ed in the ISO (International Organisation for Standardisation) and IEEE
(Institute of Electrical Engineers) standards which group and prioritise them
in terms of their effectivenesstowards QoS. Schulmeyer (2007, pp.67‐ 68)
hints that ISO/IEC 9126 series is best applicable in measuring software
quality due to resting on three components; internal quality, external
quality and quality in use. This is achieved by relying on six quality factors,
namely: functionality, reliability, usability, efficiency, maintainability and
portability which are further divided into twenty‐seven sub‐attributes
allowing to accurately measure the quality (Siu et al., 2011, p.116). These
taxonomic models are great for defining quality but are lacking in
measuring and predicting it. Furthermore, they are standardized for all
projects with emphasis on specific requirements, however, in order to
develop a quality software, it is necessary to assess the problem and define
software quality factors specific to the project (Zhu, 2005, pp.39‐43).
Having familiarized with the software quality factors offered by the above
standards and fully understood the client requirements, numerous quality
factors have been devised for this project. These factors will be used to
assess the two selected architectural styles and ultimately select the best
one for this project. The chosen software quality factors along with the
reasoning are outlined below

Correctness – The group will be mainly dealing with customers; therefore, it

is vital to implement user requirements correctly. Otherwise the system
will not be used.

Maintainability – The system is likely to be maintained by the ABC Banking

Group, suggesting that the system must accommodate future changes by
other developers/programmers.

Efficiency – The organization’s key business activity is transaction

management which suggests that the system throughput must be high and
use as little resources as possible.
Scalability – ABC Banking Group wishes to expand in the future, implying
that the system must be easily scalable to add new features without having
to change the entire architecture.
 Reliability – Since it is a banking system, each request must result in a
correct output from the system. Additionally, the system must
automatically withstand and recover from failures, informing the banking
group of the occurred faults.   
Reusability – The banking group wishes to remain competitive in the
market. By reusing existing components, new services will be developed
quicker, rivalling the competitors. 17  Portability – By expanding the
baking group’sservicesin the future, the current system should easily adapt
to new technologies and conform to the latest standards. This will also
ensure that the current system is easily accessible from a range of devices,
as the client requested. The software quality factors have been chosen and
fully justified. It is now vital to elaborate and state what each factor means
in order to remove ambiguity and correctly compare the two styles.

4.UMl diagrams
1. Use case diagram
2. Activity diagram
3. Sequence diagram
5. Code
//***************************************************************
// HEADER FILE USED IN PROJECT
//****************************************************************

#include<iostream>
#include<fstream>
#include<cctype>
#include<iomanip>
using namespace std;

//***************************************************************
// CLASS USED IN PROJECT
//****************************************************************

class account
{
int acno;
char name[50];
int deposit;
char type;
public:
void create_account(); //function to get data from user
void show_account() const; //function to show data on screen
void modify(); //function to add new data
void dep(int); //function to accept amount and add to
balance amount
 void draw(int); //function to accept amount and subtract
from balance amount
void report() const; //function to show data in tabular
format
int retacno() const; //function to return account number
int retdeposit() const; //function to return balance amount
char rettype() const; //function to return type of account
}; //class ends here

void account::create_account()
{
cout<<"\nEnter The account No. :";
cin>>acno;
cout<<"\n\nEnter The Name of The account Holder : ";
cin.ignore();
cin.getline(name,50);
cout<<"\nEnter Type of The account (C/S) : ";
cin>>type;
type=toupper(type);
cout<<"\nEnter The Initial amount(>=500 for Saving and
>=1000 for current ) : ";
cin>>deposit;
cout<<"\n\n\nAccount Created..";
}

void account::show_account() const

{
cout<<"\nAccount No. : "<<acno;
cout<<"\nAccount Holder Name : ";
cout<<name;
 cout<<"\nType of Account : "<<type;
cout<<"\nBalance amount : "<<deposit;
}

void account::modify()
{
cout<<"\nAccount No. : "<<acno;
cout<<"\nModify Account Holder Name : ";
cin.ignore();
cin.getline(name,50);
cout<<"\nModify Type of Account : ";
cin>>type;
type=toupper(type);
cout<<"\nModify Balance amount : ";
cin>>deposit;
}

void account::dep(int x)
{
deposit+=x;
}

void account::draw(int x)
{
deposit-=x;
}

void account::report() const

{
cout<<acno<<setw(10)<<" "<<name<<setw(10)<<"
"<<type<<setw(6)<<deposit<<endl;
}

int account::retacno() const

{
return acno;
}

int account::retdeposit() const

{
return deposit;
}

char account::rettype() const

{
return type;
}

//***************************************************************
// function declaration
//****************************************************************
void write_account(); //function to write record in binary file
void display_sp(int); //function to display account details given by
user
void modify_account(int); //function to modify record of file
void delete_account(int); //function to delete record of file
void display_all(); //function to display all account details
void deposit_withdraw(int, int); // function to desposit/withdraw
amount for given account
void intro(); //introductory screen function

//***************************************************************
// THE MAIN FUNCTION OF PROGRAM
//****************************************************************

int main()
{
char ch;
int num;
intro();
do
{
system("cls");
cout<<"\n\n\n\tMAIN MENU";
cout<<"\n\n\t01. NEW ACCOUNT";
cout<<"\n\n\t02. DEPOSIT AMOUNT";
cout<<"\n\n\t03. WITHDRAW AMOUNT";
cout<<"\n\n\t04. BALANCE ENQUIRY";
cout<<"\n\n\t05. ALL ACCOUNT HOLDER LIST";
cout<<"\n\n\t06. CLOSE AN ACCOUNT";
cout<<"\n\n\t07. MODIFY AN ACCOUNT";
cout<<"\n\n\t08. EXIT";
cout<<"\n\n\tSelect Your Option (1-8) ";
cin>>ch;
system("cls");
switch(ch)
{
case '1':
write_account();
break;
case '2':
cout<<"\n\n\tEnter The account No. : "; cin>>num;
deposit_withdraw(num, 1);
break;
case '3':
cout<<"\n\n\tEnter The account No. : "; cin>>num;
deposit_withdraw(num, 2);
break;
case '4':
cout<<"\n\n\tEnter The account No. : "; cin>>num;
display_sp(num);
break;
case '5':
display_all();
break;
case '6':
cout<<"\n\n\tEnter The account No. : "; cin>>num;
delete_account(num);
break;
case '7':
cout<<"\n\n\tEnter The account No. : "; cin>>num;
modify_account(num);
break;
case '8':
 cout<<"\n\n\tThanks for using bank managemnt
system";
break;
default :cout<<"\a";
}
cin.ignore();
cin.get();
}while(ch!='8');
return 0;
}

//***************************************************************
// function to write in file
//****************************************************************

void write_account()
{
account ac;
ofstream outFile;
outFile.open("account.dat",ios::binary|ios::app);
ac.create_account();
outFile.write(reinterpret_cast<char *> (&ac), sizeof(account));
outFile.close();
}

//***************************************************************
// function to read specific record from file
//****************************************************************
void display_sp(int n)
{
account ac;
bool flag=false;
ifstream inFile;
inFile.open("account.dat",ios::binary);
if(!inFile)
{
cout<<"File could not be open !! Press any Key...";
return;
}
cout<<"\nBALANCE DETAILS\n";

while(inFile.read(reinterpret_cast<char *> (&ac),

sizeof(account)))
{
if(ac.retacno()==n)
{
ac.show_account();
flag=true;
}
}
inFile.close();
if(flag==false)
cout<<"\n\nAccount number does not exist";
}

//***************************************************************
// function to modify record of file
//****************************************************************

void modify_account(int n)
{
bool found=false;
account ac;
fstream File;
File.open("account.dat",ios::binary|ios::in|ios::out);
if(!File)
{
cout<<"File could not be open !! Press any Key...";
return;
}
while(!File.eof() && found==false)
{
File.read(reinterpret_cast<char *> (&ac),
sizeof(account));
if(ac.retacno()==n)
{
ac.show_account();
cout<<"\n\nEnter The New Details of
account"<<endl;
ac.modify();
int pos=(-1)*static_cast<int>(sizeof(account));
File.seekp(pos,ios::cur);
File.write(reinterpret_cast<char *> (&ac),
sizeof(account));
cout<<"\n\n\t Record Updated";
found=true;
}
 }
File.close();
if(found==false)
cout<<"\n\n Record Not Found ";
}

//***************************************************************
// function to delete record of file
//****************************************************************

void delete_account(int n)
{
account ac;
ifstream inFile;
ofstream outFile;
inFile.open("account.dat",ios::binary);
if(!inFile)
{
cout<<"File could not be open !! Press any Key...";
return;
}
outFile.open("Temp.dat",ios::binary);
inFile.seekg(0,ios::beg);
while(inFile.read(reinterpret_cast<char *> (&ac),
sizeof(account)))
{
if(ac.retacno()!=n)
{
 outFile.write(reinterpret_cast<char *> (&ac),
sizeof(account));
}
}
inFile.close();
outFile.close();
remove("account.dat");
rename("Temp.dat","account.dat");
cout<<"\n\n\tRecord Deleted ..";
}

//***************************************************************
// function to display all accounts deposit list
//****************************************************************

void display_all()
{
account ac;
ifstream inFile;
inFile.open("account.dat",ios::binary);
if(!inFile)
{
cout<<"File could not be open !! Press any Key...";
return;
}
cout<<"\n\n\t\tACCOUNT HOLDER LIST\n\n";

cout<<"===============================================
=====\n";
cout<<"A/c no. NAME Type Balance\n";
cout<<"===============================================
=====\n";
while(inFile.read(reinterpret_cast<char *> (&ac),
sizeof(account)))
{
ac.report();
}
inFile.close();
}

//***************************************************************
// function to deposit and withdraw amounts
//****************************************************************

void deposit_withdraw(int n, int option)

{
int amt;
bool found=false;
account ac;
fstream File;
File.open("account.dat", ios::binary|ios::in|ios::out);
if(!File)
{
cout<<"File could not be open !! Press any Key...";
return;
}
while(!File.eof() && found==false)
{
 File.read(reinterpret_cast<char *> (&ac),
sizeof(account));
if(ac.retacno()==n)
{
ac.show_account();
if(option==1)
{
cout<<"\n\n\tTO DEPOSITE AMOUNT ";
cout<<"\n\nEnter The amount to be
deposited";
cin>>amt;
ac.dep(amt);
}
if(option==2)
{
cout<<"\n\n\tTO WITHDRAW AMOUNT ";
cout<<"\n\nEnter The amount to be
withdraw";
cin>>amt;
int bal=ac.retdeposit()-amt;
if((bal<500 && ac.rettype()=='S') || (bal<1000
&& ac.rettype()=='C'))
cout<<"Insufficience balance";
else
ac.draw(amt);
}
int pos=(-1)*static_cast<int>(sizeof(ac));
File.seekp(pos,ios::cur);
File.write(reinterpret_cast<char *> (&ac),
sizeof(account));
 cout<<"\n\n\t Record Updated";
found=true;
}
}
File.close();
if(found==false)
cout<<"\n\n Record Not Found ";
}

//***************************************************************
// INTRODUCTION FUNCTION
//****************************************************************

void intro()
{
cout<<"\n\n\n\t BANK";
cout<<"\n\n\tMANAGEMENT";
cout<<"\n\n\t SYSTEM";
cout<<"\n\n\n\nMADE BY : your name";
cout<<"\n\nSCHOOL : your school name";
cin.get();
}

//***************************************************************
// END OF PROJECT
//***************************************************************
Test plan
For testing banking applications, different stages of testing
include

 Requirement Analysis: It is done by business analyst;

requirements for a particular banking application are
gathered and documented
 Requirement Review: Quality analysts, business analysts,
and development leads are involved in this task. The
requirement gathering document is reviewed at this stage,
and cross-checked to ensure that it does not affect the
workflow
 Business Requirements Documentation: Business
requirements documents are prepared by quality analysts
in which all reviewed business requirements are covered
 Database Testing: It is the most important part of bank
application testing. This testing is done to ensure data
integrity, data loading, data migration, stored procedures,
and functions validation, rules testing, etc.
 Integration Testing: Under Integration Testing all
components that are developed are integrated and
validated
  Functional Testing: The usual software testing activities
like Test Case preparation, test case review and test case
execution is done during this phase
 Security Testing: It ensures that the software does not
have any security flaws. During test preparation, QA team
needs to include both negative as well as positive test
scenarios so as to break into the system and report it
before any unauthorized individual access it. While to
prevent from hacking, the bank should also implement a
multi-layer of access validation like a one-time password.
For Security Testing, automation tools like IBM AppScan
and HPWebInspect are used while for Manual
Testing tools like Proxy Sniffer, Paros proxy, HTTP watch,
etc. are used
 Usability Testing: It ensures that differently able people
should be able to use the system as normal user. For
example, ATM with hearing and Braille facility for disabled
 User Acceptance Testing: It is the final stage of testing
done by the end users to ensure the compliance of the
application with the real world scenario.

Test cases for banking

Security is prime for any banking application. Therefore, during test preparation, QA team
should include both negative and positive test scenarios in order to sneak into the system and
report for any vulnerabilities before any unauthorized individual get access to it. It not only
involves writing negative test cases but may also include destructive testing.

Following are generic test cases to check any banking application

Test cases
For Admin  Verify Admin login with valid and Invalid data
 Verify admin login without data
 Verify all admin home links
 Verify admin change password with valid and invalid data
 Verify admin change password without data
 Verify admin change password with existing data
 Verify admin logout

For new Branch  Create a new branch with valid and invalid data
 Create a new branch without data
 Create a new branch with existing branch data
 Verify reset and cancel option
 Update branch with valid and invalid data
 Update branch without data
 Update branch with existing branch data
 Verify cancel option
 Verify branch deletion with and without dependencies
 Verify branch search option

For New Role  Create a new role with valid and invalid data
 Create a new role without data
 Verify new role with existing data
 verify role description and role types
 Verify cancel and reset option
 Verify role deletion with and without dependency
 verify links in role details page

For customer & Visitors  Verify all visitor or customer links

 Verify customers login with valid and invalid data
 Verify customers login without data
 Verify banker's login without data
 Verify banker's login with valid or invalid data

For New users  Create a new user with valid and invalid data
 Create a new user without data
  Create a new user with existing branch data
 Verify cancel and reset option
 Update user with valid and invalid data
 Update user with existing data
 Verify cancel option
 Verify deletion of the user

Challenges in testing Banking domain & their

Mitigation
Challenges tester might face during testing banking domain are

Challenge Mitigation

 Getting access to production data and  Ensure that test data meets regulatory
replicating it as test data, for testing is compliances requirements and guidelines
challenging  Maintain the data confidentiality by
following techniques like data masking,
synthetic test data, testing system
integration, etc.

 The biggest challenge in testing banking  Ensure Data Migration Testing is

system is during the migration of the complete
system from the old system to the new  Ensure Regression Test cases are
system like testing of all the routines, executed on old and new systems, and
procedures and plans. Also how the data the results match.
will be fetched, uploaded and transferred
to the new system after migration

 There may be the cases where  The test should participate in the project
requirements are not documented well right from Requirement Analysis phases
and may lead to functional gaps in test and should actively review the Business
plan Requirements
 Many non-functional requirements are
not fully documented, and testers do not
know whether to test it or not
  The most important point is to check  Compliance or Regulatory Policies testing
whether the said system follows the must be done
desired policies and procedures

 The scope and the timelines increases as  Ensure Time budget for Integration
banking application are integrated with Testing is accounted if your banking
other application like internet application has many external interfaces
or Mobile banking

Banking domain is the most vulnerable area for cyber-theft, and safeguarding
the software requires precise testing. This tutorial gives a clear idea of what it
takes for banking domain testing and how important it is. One must
understand that -

 Majority of banking software are developed on Mainframe and Unix

 Testing helps to lessen possible glitches encounter during software
development
 Proper testing and compliance to industry standards, save companies
from penalties
 Good practices help develop good results, reputation and more
business for companies
 Both manual and automated testing have respective merits and usability
8. Defect life cycle
10. Scope of the project
Banking system is a way to maintain few records
which bank holds in order to keep a track of
everything in the bank so a software application is
required in order to make the work easier, for
example- maintenance of international value of
INR and other currency are also a part of the job
of banking system. The bank management is also
required to act as the currency distributor and to
serve the work for the nation’s well-being. This
application is built to make it easier for the
customers to track every transaction that is being
made. Banking system assignment help is provided
by MakeMyAssignments.com.
The main aim of an application is to somewhere
automate records on the system. It gives all sorts
of functions which are required by the bank in
order to run a stable system. In addition to that it
also helps to manually check the records of the
pre-existing system like transactions that are
made in the past. The application also changes or
manipulates the new data that is being added and
is then re-recorded. One can also check their
present transactions that are in process and keep
a check on their accounts via this application. It’s
not only useful for the customers but also for the
admin.

SCOPE:
 Creating New Accounts- The application can
be used to create two different types of
accounts by the customers, which are Savings
Account and Current Account. It helps save the
hustle for the customer to visit the bank
physically and create/use these accounts.
 Depositing Money- As the world is moving
towards the limited use of paper currency,
depositing or transferring money from one
bank to the other will become as easy as
clicking a few buttons using this application.
 Withdrawing Money- Requests can be sent
through the application to ask for money
transfer as well.
 Account Holder List- This is a feature for the
admin. The admin can view the list of all the
account holders.
 Balance Enquiry- The customer can check
their balance via this application.
 Changing Passwords/PIN- The customer can
easily change the passwords and pin numbers
using the application.
 Closing- The customer can close their
accounts too using this application.

11. COCOMO model

12. Final cost of the project and future
work
The popularity of mobile banking has surpassed that of online
banking, and the overall number of online customers has slowed
worldwide. According to Insider Intelligence, mobile banking is
growing at five times the rate of online banking, and half of all online
customers are also mobile banking users. 

Despite this growing popularity, some banks still fall short on the
demand for mobile tasks, like bill pay and reward redemption, causing
them to push users to online banking. However, even this push won't
be enough to popularize online banking as millenials and Gen Zers
continue gravitating toward the mobile market.

Digital-only banks, also known as neobanks, are redefining the future

of banking around the world. Though off to a slow start in the US due
to high regulatory barriers, recent developments and the loosening of
regulations suggest that US neobanks are set to take off.