INDUSTRIAL TRAINING REPORT

On “BANK MANAGEMENT SYSTEM”

Submitted in partial fulfilment of the award of the degree of
Bachelor of technology (B. tech) in
Computer Science and Engineering

Submitted by:
Aayushi
2023078002
CSE (2023-202)

Submitted To:
Ms. Divya
Department of Computer Science and Engineering,
State Institute of Engineering and Technology, Nilokheri (Karnal)
(Affiliated to Kurukshetra University, Kurukshetra)

1
 DECLARATION BY THE CANDIDATE

I hereby declare that the project report entitled " Bank Management system " submitted by me
to State Institute of Engineering & Technology, Nilokheri (Karnal) in partial fulfilment of the
requirement for the award of the degree of B. TECH in COMPUTER SCIENCE &
ENGINEERING is a record of bonafide project work carried out by me. I further declare that
the work reported in this project has not been submitted and will not be submitted, either in
part or in full, for the award of any other degree or diploma in this institute or any other institute
or university.

Signature of the Candidate

Date: Name: Aayushi
Place: Class: CSE 3rd Semester
Roll no.: 2023078002

2
CERTIFICATE

3
 ACKNOWLEDGEMENT

The success and outcome of this project required a lot of guidance and assistance from many
people, and I am extremely privileged to have got this all along the completion of my project.
All that I have done is only due to such supervision and assistance and I would not forget to
thank them.
I would like to place on record my deep sense of gratitude to Hartron Team who taught me the
usage of the various tools and techniques widely used in the field of user experience design.
Thank you Hartron for giving such a wonderful opportunity to study under their online training
program.
I am thankful to and fortunate enough to get constant encouragement, support and guidance
from all Teaching staffs of Department of Computer Science and Engineering who helped me
in successfully completing our project work.

Aayushi
CSE 3rd Semester
Roll no.-2023078002

4
 ABSTRACT

The bank management system project is a program that keeps track of a client’s bank account.
This project demonstrates the operation of a banking account system and covers the essential
functions of bank management software. It develops a project for resolving a customer’s
financial applications in a banking environment to meet the needs of an end banking user by
providing multiple ways to complete banking chores. Additionally, this project is to provide
additional features to the user’s workspace that are not available in a traditional banking project.
The project’s bank management system is built on cutting-edge technologies. This project’s main
goal is to create software for a bank account management system. This project was designed to
make it simple and quick to complete previously impossible processes with manual systems
which are now possible with this software.

5
 COMPANY PROFILE
Company Overview
• Company Name: HARTRON (Haryana State Electronics Development Corporation
Limited)
• Founded: 1982
• Headquarters: Chandigarh, India
• Website: www.hartron.org.in
HARTRON is a state government-owned electronics development corporation based in
Haryana, India. It was established with the primary objective of promoting the electronics and
IT industry in Haryana. Over the years, HARTRON has become a key player in the state's
technology development, particularly in the fields of electronics, computer education, software
development, and IT-enabled services.

Vision
To become a leading organization in the field of electronics and IT development, empowering
the people and businesses of Haryana through innovative technology solutions, educational
services, and efficient governance.

Mission
• To foster the growth of the electronics industry in the state.
• To promote computer education and software development.
• To enhance the use of information technology for the development of the state.
• To provide IT infrastructure and services for government and public sector
organizations.

Core Services and Offerings

1. Software Development:
o Development of customized software solutions for various government
departments and industries.
o Expertise in enterprise resource planning (ERP), e-governance solutions, and
web-based applications.
2. IT Education and Training:
o Offering computer education and training programs for individuals and
organizations.
o Training centres across the state for various computer courses, skill
development, and certification programs.
3. Electronics Manufacturing:
o Manufacturing and development of electronic products such as
microprocessors, PCBs (Printed Circuit Boards), and other electronic
components.
o Involvement in the design and assembly of consumer electronics.
4. Consulting and Support Services:
o Providing IT consulting, support, and solutions for both public and private
organizations.
o Support for IT infrastructure development and implementation of IT solutions
in governmental projects.
5. E-Governance Initiatives:
o Automation of government services using information technology.

6
 o Digitalization of government processes to improve transparency, accountability,
and efficiency.
6. Project Management:
o Managing large-scale technology projects for the government and other clients.
o Expertise in the execution of IT infrastructure projects.

Key Achievements
• Implementation of E-Governance Solutions: HARTRON has successfully delivered
several e-governance initiatives to streamline government operations and improve
service delivery to citizens.
• Training Success: Thousands of individuals have been trained in various computer and
IT courses, significantly contributing to skill development in the state.
• Industry Partnerships: Collaborations with various global and national organizations to
bring innovative technology solutions to Haryana.
• Pioneering IT Solutions for Government: HARTRON has played a key role in the
automation of state government processes, increasing efficiency and transparency in
governance.

Key Clients and Collaborations

• Government of Haryana: As a state-run corporation, HARTRON works closely with
various state government departments, delivering IT and e-governance solutions.
• Public Sector Enterprises (PSEs): HARTRON provides IT solutions, consulting, and
training services to numerous public sector organizations.
• Private Sector Companies: HARTRON collaborates with private-sector entities in
electronics manufacturing, software development, and IT support services.

Infrastructure and Technology

• HARTRON has a robust infrastructure with modern data centres, training centres, and
electronic manufacturing units spread across the state.
• The company uses state-of-the-art technology in its development and implementation
processes, ensuring high-quality solutions.

Awards and Recognition

• HARTRON has received recognition for its significant contributions to the
development of IT infrastructure and e-governance in Haryana.
• The company has been awarded various national and state-level awards for excellence
in IT innovation and technology development.

Outlook
HARTRON aims to:
• Expand its IT services to more regions and industries.
• Focus on Smart Cities and Digital India initiatives through collaboration with state and
central government projects.
• Develop and implement more e-governance solutions to enhance public service
delivery.
• Continue its efforts in skill development and training to meet the growing demands of
the IT industry.

7
 LIST OF FIGURES

Sr. No. Fig. No. Caption Page No.

1 Fig.3.1 Activities during software project planning 29

2 Fig.3.2 Requirement analysis Steps 37

3 Fig.5.1 Main Menu 53
4 Fig.5.2 Customer Menu 53
5 Fig.5.3 Account Management Menu 54
6 Fig.5.4 Creating New Account 54

8
 TABLE OF CONTENTS

Sr. No. Title Page

No.
1 Declaration 2
2 Certificate 3
3 Acknowledgement 4
4 Abstract 5
5 Company profile 6
6 List of figures 8
7 Chapter 1: Introduction 10
1.1 Significance of Bank Account 10
1.2 History of Bank Account 11
1.3 Objective of Banking System 11
1.4 Types of Banking System 13
8 Chapter 2: Tools & Technologies learned 14
2.1 Acceptance and text generation 14
2.2 Text data used 15
2.3 Implementation 18
9 Chapter 3: Project Brief 20
3.1 Profile of Problem 20
3.2 Software development life cycle 21
3.3 Problem Analysis 23
3.4 Feasibility Analysis 26
3.5 Project plan 28
3.6 Planning the development process 29
3.7 Size estimation 30
3.8 cost estimation 30
3.9 Hardware and software required 32
3.10 Frontend details 35
3.11 Backend details 37
10 Chapter 4: Functional requirements 41
4.1 Nonfunctional requirements 41
4.2 System designed 44
4.3 Design notations 47
4.4 User characteristics 48
4.5 Entity relationship diagrams 52
11 Chapter 5: Final Design Screens 53
12 Chapter 6: Conclusion 55
13 References 58

9
 CHAPTER 1

INTRODUCTION

1.1 Significance of Bank Account

A bank account is a financial account maintained by a banking institution that allows

customers to deposit money, withdraw funds, and conduct various financial transactions. It is
a secure and regulated way for individuals and businesses to manage their finances.
Key Features of a Bank Account:
1. Account Holder: The person or entity that owns the account.
2. Account Number: A unique identifier used to access the account and conduct
transactions.
3. Banking Institution: The financial institution (bank or credit union) where the
account is held.
4. Balance: The amount of money available in the account at any given time.
5. Transactions: Actions like deposits, withdrawals, payments, and transfers that take
place within the account.
How a Bank Account Works:
• Deposits: Money is placed into the account either through cash deposits, checks, or
electronic transfers (e.g., wire transfers, direct deposits).
• Withdrawals: Money can be taken out via ATM withdrawals, writing checks, using a
debit card, or transferring funds to another account.
• Interest: Some bank accounts, especially savings and fixed deposit accounts, may earn
interest based on the balance in the account.
• Fees: Some accounts charge fees for services such as monthly maintenance, ATM use,
or insufficient funds.
Importance of a Bank Account:
1. Security: Keeps money safe from theft or loss compared to storing cash at home.
2. Record-Keeping: Provides a paper trail of deposits and withdrawals, helping with
financial tracking and budgeting.
3. Access to Financial Services: Enables access to other banking products like loans,
mortgages, and credit cards.
4. Convenience: Allows easy access to funds, bill payments, and online purchases.

10
1.2 History of Bank Account
The history of bank accounts stretches back thousands of years, evolving from primitive
systems for storing wealth to the advanced digital tools we use today.
In ancient civilizations, such as Mesopotamia around 3000 BCE, the first forms of banking
were created by temples that served as places to store valuables and grain, facilitating trade
and lending. Similarly, in ancient Egypt, temples acted as depositories, providing safe storage
for wealth and enabling early forms of credit. In ancient Greece and Rome, banking practices
evolved further, with Roman argentarii offering services like moneylending and currency
exchange, which laid the groundwork for more structured financial systems.
During the Middle Ages, the rise of trade in Europe led to the emergence of merchant banks
in cities like Venice and Florence. Wealthy families, such as the Medici, established banking
institutions that offered services such as deposit taking and lending. This period also saw the
introduction of banknotes in the 14th century, essentially paper money issued by banks as
receipts for deposited assets, which marked the beginnings of modern currency systems.
The development of modern banking began in the 17th century with the founding of the Bank
of England in 1694, which set the model for central banking and currency regulation. This era
also saw the emergence of more formalized bank accounts, including checking and savings
accounts, which allowed individuals to store money securely and conduct financial
transactions more efficiently.
In the 19th century, the Industrial Revolution spurred the need for more accessible banking
services. Personal banking accounts became available to ordinary citizens, and the use of
checks as a method of transferring money grew, providing a more secure and convenient way
to handle finances. As banking evolved, it became more integrated into daily life, especially
with the advent of automated teller machines (ATMs) in the 1960s, which allowed customers
24/7 access to their accounts.
The late 20th century brought further innovations in banking with the rise of credit and debit
cards, and by the 1990s, the internet transformed banking with the introduction of online
banking. This allowed customers to check balances, transfer money, and pay bills without
leaving their homes, bringing unprecedented convenience.
In the 21st century, mobile banking became mainstream, as smartphones enabled users to
manage their bank accounts and conduct financial transactions via apps. Additionally, the rise
of cryptocurrencies like Bitcoin and the underlying blockchain technology have introduced
decentralized forms of banking, presenting new challenges and opportunities for the financial
sector.
From ancient deposit systems to the digital banking landscape of today, the history of bank
accounts reflects the ongoing evolution of how people manage money and interact with
financial institutions. Each step forward has made banking more accessible, secure, and
efficient, and the trend toward digitalization suggests an even more streamlined future.

1.3 Objective of Banking System

The objective of a banking system is to facilitate the efficient functioning of an economy by
managing money, credit, and financial transactions. The banking system plays a crucial role in
the overall economic development by ensuring liquidity, fostering savings and investment, and
supporting the flow of funds between borrowers and lenders. Here are the key objectives of a
banking system:
11
1. Facilitate Economic Growth and Development
Banks provide the infrastructure needed to channel funds from savers to borrowers. By lending
money to individuals, businesses, and governments, they promote investment and economic
activity, which helps in the growth and development of the economy.
2. Promote Savings and Investments
A banking system encourages individuals and businesses to save money by offering savings
accounts and fixed deposits. These savings can then be used for investments, both personal
and in the form of loans to businesses, contributing to economic productivity and innovation.
3. Provide a Payment System
Banks provide a safe, efficient, and reliable means of transferring money and making payments.
They enable electronic payments, fund transfers, check processing, and online banking
services, all of which are essential for the smooth operation of the economy.
4. Ensure Liquidity and Stability
A key objective of the banking system is to ensure liquidity (the availability of money) in the
economy. This means ensuring that individuals and businesses can easily access cash when
needed. It also involves the stability of the financial system by managing risks and avoiding
systemic crises.
5. Manage Credit and Monetary Policy
Banks play a critical role in the credit creation process by lending money to borrowers. They
also work in conjunction with central banks to manage monetary policy, control inflation, and
regulate the supply of money in the economy, thereby helping maintain price stability.
6. Foster Trust and Security
The banking system ensures the safety of deposits by offering insurance (such as Deposit
Insurance in some countries), protecting customers’ money. This fosters trust in the financial
system and promotes savings and investment.
7. Support International Trade
Banks provide services like foreign exchange, letters of credit, and trade financing, which
help businesses engage in international trade. This is vital for fostering global economic
integration and facilitating the exchange of goods and services across borders.
8. Provide Financial Services
Banks offer a wide range of financial products and services, such as loans, mortgages, credit
cards, insurance, and investment products. These services help individuals and businesses
meet their financial needs and goals.
9. Facilitate Financial Inclusion
One of the modern goals of banking systems is to ensure that everyone, including underserved
and low-income populations, has access to basic financial services. This includes bank
accounts, microfinance, and digital banking solutions to help people manage their money and
improve their economic well-being.

12
1.4 Types of Banks
1. Checking Account:
• Designed for everyday use.
• Allows deposits, withdrawals, writing checks, and making payments.
• Typically has low or no interest but offers high liquidity (easy access to funds).
• Features may include a debit card, ATM access, and online banking.
2. Savings Account:
• Used for saving money over a longer period.
• Typically earns interest on the balance.
• Withdrawals may be more limited compared to checking accounts.
• Ideal for accumulating funds for future needs or emergencies.
3. Fixed Deposit Account (Time Deposit):
• A type of savings account where funds are deposited for a fixed period (e.g., 1 year,
5 years).
• Offers a higher interest rate than regular savings accounts.
• Funds are usually locked until the maturity date.
4. Current Account:
• Primarily used by businesses for frequent transactions.
• Often comes with overdraft facilities and allows for larger transactions.
• May not earn interest and could have higher fees and charges compared to savings
accounts.
5. Joint Account:
• An account shared by two or more individuals.
• Can be used for shared financial goals or family management.
• All account holders can deposit, withdraw, or manage funds.
6. Online or Mobile Bank Account:
• Accounts that are primarily managed through online banking apps or websites.
• Offers convenience and may have lower fees due to reduced physical
infrastructure.

13
 CHAPTER 2

TOOLS AND TECHNOLOGIES LEARNED

2.1 Acceptance and test generation

The objective of this step is to produce a set of test data that may be used to test the system.
Whenever a new system is developed it need to be tested to confirm its validity and to
determine whether it meets the user requirements. The system was also tested with some
sample records. The records were entered into the system and various reports were generated
to check the system.
System testing is a critical phase of implementation. Testing of the system involves hardware
devices and debugging of computer programs and testing information processing procedures.
Testing can be done with test data, which attempt to simulate all possible condition that may
rise during processing. The testing methods adopted during the testing of system are unit
testing and integration testing.

2.1.1 TESTING

Testing is the process of executing a program with the intent of finding errors. Although
software testing is itself an expensive activity, yet launching of software without may lead to
cost potentially much higher than that of testing, especially in systems where human safety is
involved. Effective software testing will contribute to the delivery of higher quality software
products, more satisfied users, and lower maintenance costs, more accurate and reliable
results.
Software testing is necessary and important activity of software development process.

2.1.2 STRUCTURAL TESTING

Structural Testing considers the internal mechanism of a system or component. Fatigue Testing
is carried out with the objective of determining the relationship between the stress range and
the number of times it can be applied before causing failure. So, when your product’s structural
durability needs to be predicted, verified and validated, turn to DTB's Structural Testing and
Fatigue Testing experts. We provide you with the necessary structural testing and fatigue
testing equipment and personnel to test the design and manufacturing integrity of your product.
Call upon our vast experience in commercial and military applications.

Software structure testing is a 2-day course designed to provide an excellent knowledge base
and practical skills for anyone interested in improving Software Structural Testing techniques
and practices in their organization. This course starts with an overview of software testing
basics, including discussions of the importance of software testing, the different levels of
testing and basic testing principles. Basic testing terminology is defined. Techniques for
ensure test coverage of requirements, different types of testing documentation and various test
activities are discussed.
2.1.3 FUNCTIONAL TESTING
It is very useful and convenient in support of functional testing. Although JMeter is known
more as a performance testing tool, functional testing elements can be integrated within the
Test Plan, which was originally designed to support load testing. Many other load-testing tools
provide little or none of this feature, restricting themselves to performance-testing purposes.
14
Besides integrating functional-testing elements along with load-testing elements in the Test
Plan, you can also create a Test Plan that runs these exclusively. In other words, aside from
creating a Load Test Plan, it also allows you to create a Functional Test Plan. This flexibility
is certainly resource-efficient for the testing project.
This will give a walkthrough on how to create a Test Plan as we incorporate and/or configure
its elements to support functional testing. This created a Test Plan for a specific target web
server. We will begin the chapter with a quick overview to prepare you with a few expectations;
we will create a new Test Plan, only smaller. The Test Plan we will create and run at the end
of this chapter will incorporate elements that support functional testing, exclusively.
2.1.4 UNIT TESTING

Unit testing focuses on the modules independently locate the errors. This enables the tester to
detect errors in coding. It is the process of taking a module and running it in isolation from
rest of the software product by using prepared test cases and comparing the actual result with
the result redirected with the specifications and design of the module. One purpose of testing
is to find and remove as many errors in the software as practical. There are number of reasons
in support of unit testing-:
• The size of module single module is small that we can locate an error fairly easily.
• The module is small enough that we can attempt to test it in some demonstrably
exhaustive fashion.
• Confusing interactions of multiple errors in widely different parts of software are
eliminated.
There are problems associated with testing a module in isolation. How do we run a module
without anything to call it, to be called by it, possibly to output intermediate values obtained
during execution? One approach is to construct an appropriate driver routine to call it, and
simply stubs to be called by it, and to insert output statements in it. Stubs serve to replace
modules that are subordinate to the module to be tested. A stub or dummy subprogram uses
the subordinate module’s interface, may do minimal data manipulation, prints verification of
entry and returns.
2.1.5 INTEGRATION TESTING

This is a systematic technique for constructing the program structure while at the same time
to uncover the errors associated with the interface. The objective is to take unit tested module
and build a program structure that has been detected by designing. The main purpose of
integration testing is to determine that the interfaces between modules are correct or not. One
specific target of integration testing is the interface: whether parameter matches on both sides
as to type, permissible ranges, meaning & utilization. There are 3 types of integration testing-
• Top-Down Approach: Top-Down integration proceeds down the invocation hierarchy,
adding one module at a time until an entire tree level is generated.
• Bottom-Up Approach: The Bottom-up strategy works similarly from the bottom to up.
• Sandwich Strategy: A sandwich strategy runs from top and bottom simultaneously.

2.2 Test data used

test data should be tailored to meet the specific requirements and practices commonly followed
in India’s banking industry. Below is a refined version of test data that is relevant to the Indian
15
banking system, considering various aspects such as account types, transactions, loans, and
bill payments that reflect common practices in India.
1. Customer Account Data (Indian Context)
Test data for customer accounts ensures the system can handle account creation, retrieval, and
modification. For India, account types could include savings accounts, current accounts, and
fixed deposits.
• Account Number: 123456789012, 987654321098, 112233445566
• Account Holder Name: Ramesh Kumar, Priya Sharma, Deepak Yadav
• Account Type:
o Savings Account (SB)
o Current Account (CA)
o Fixed Deposit (FD)
• Balance: ₹5000.00, ₹20000.00, ₹0.00
• Account Status: Active, Inactive, Blocked
• IFSC Code: SBIN0001234, HDFC0002345, ICIC0004567
• Branch Name: State Bank of India, HDFC Bank, ICICI Bank
• Customer Address: "1st Floor, MG Road, Bengaluru", "B-10, Sector 12, Noida"
• Phone Number: +91-9876543210, +91-9112233445
• Email Address: [email protected], [email protected]
2. Transaction Data
Test data for transactions ensures the system can handle deposit, withdrawal, and transfer
scenarios accurately in the Indian banking system, including transaction charges that are
commonly applied in India. The proper selection of the data is very important. If the test data
is not appropriate or representative of the data to be provided by the user, the reliability of the
output is susceptible.
• Transaction ID: TXN10001, TXN10002, TXN10003
• Transaction Date: "2024-10-15", "2024-10-16", "2024-10-17"
• Transaction Type: Deposit, Withdrawal, Transfer, IMPS, NEFT
• Amount: ₹500.00, ₹2000.00, ₹10000.00, ₹50.00
• Source Account: 123456789012, 987654321098
• Destination Account: 112233445566, 987654321098
• Transaction Status: Success, Failed, Pending
• Transaction Mode: IMPS, NEFT, RTGS, UPI, Cash Withdrawal
• Balance After Transaction: ₹5500.00, ₹19000.00, ₹5000.00
• Transaction Fee: ₹5 (for UPI Transfer), ₹10 (for NEFT), ₹20 (for cash withdrawal)
Example Transactions:
1. Deposit:
o Transaction ID: TXN10001
o Account: 123456789012 (Ramesh Kumar)
o Amount: ₹1000.00
o Balance Before: ₹5000.00
o Balance After: ₹6000.00
o Transaction Type: Deposit (Cash)
2. Withdrawal:
o Transaction ID: TXN10002
o Account: 987654321098 (Priya Sharma)
o Amount: ₹500.00
o Balance Before: ₹20000.00
o Balance After: ₹19500.00

16
 o Transaction Type: Withdrawal (ATM)
3. Transfer (IMPS):
o Transaction ID: TXN10003
o Amount: ₹2000.00
o Source Account: 123456789012 (Ramesh Kumar)
o Destination Account: 112233445566 (Deepak Yadav)
o Balance Before (Source): ₹6000.00
o Balance After (Source): ₹4000.00
o Balance After (Destination): ₹2000.00
3. Loan Data
Test data for loan management ensures the system can handle loan applications, approvals,
and repayments. In India, common types of loans include personal loans, home loans, and car
loans.
• Loan ID: LN1001, LN1002, LN1003
• Loan Amount: ₹100000.00, ₹500000.00, ₹2000000.00
• Interest Rate: 7%, 9%, 10.5%
• Loan Term: 12 months, 24 months, 36 months
• Instalment Amount: ₹10000.00, ₹25000.00, ₹40000.00
• Start Date: "2024-01-01", "2024-05-01", "2024-08-01"
• Due Date: "2025-01-01", "2026-05-01", "2027-08-01"
• Loan Status: Approved, Pending, Rejected
• Repayment Status: Paid, Overdue, Partial
Example Loan Data:
1. Home Loan:
o Loan ID: LN1001
o Amount: ₹500000.00
o Interest Rate: 8%
o Term: 24 months
o Instalment: ₹25000.00/month
o Status: Approved
2. Personal Loan:
o Loan ID: LN1002
o Amount: ₹100000.00
o Interest Rate: 10.5%
o Term: 12 months
o Instalment: ₹10000.00/month
o Status: Pending
4. Bill Payment Data (Indian Context)
Test data for bill payments ensures that the system can handle utility bill payments, mobile
recharges, and credit card payments common in India. Payment systems like UPI, IMPS, and
NEFT are widely used.
• Bill Payment ID: BP1001, BP1002, BP1003
• Bill Type: Electricity Bill, Credit Card, Mobile Recharge, Water Bill
• Amount: ₹500.00, ₹1500.00, ₹3000.00
• Payment Method: UPI, NEFT, Credit Card, Debit Card
• Bill Due Date: "2024-10-01", "2024-11-01", "2024-12-01"
• Payment Status: Success, Failed, Pending
Example Bill Payments:
1. Electricity Bill:
o Bill ID: BP1001
17
 o Amount: ₹500.00
o Bill Type: Electricity
o Payment Method: UPI
o Due Date: "2024-10-01"
o Payment Status: Success
2. Mobile Recharge:
o Bill ID: BP1002
o Amount: ₹200.00
o Bill Type: Mobile Recharge (Airtel)
o Payment Method: UPI
o Due Date: "2024-10-10"
o Payment Status: Success
3. Credit Card Payment:
o Bill ID: BP1003
o Amount: ₹2000.00
o Bill Type: Credit Card (HDFC)
o Payment Method: NEFT
o Due Date: "2024-11-01"
o Payment Status: Failed
5. Security Data (for Authentication)
Test data for security ensures the system handles login attempts, password changes, and user
authentication in line with common security practices in Indian banks.
• User ID: user001, user002, user003
• Password: "password123", "Secure@2024", "Pass@456"
• Login Attempt: Success, Failure
• Failed Login Attempts: 1, 3, 5 (for account lockout scenarios)
6. User Interface (UI) Data
Test data for the UI ensures that inputs like customer details, transaction amounts, and other
data are correctly handled.
• Customer Name: "Ramesh Kumar", "Priya Sharma"
• Account Type: "Savings Account", "Current Account", "Fixed Deposit"
• Transaction Amount: ₹1000.00, ₹2000.00, ₹500.00
• Loan Type: "Personal Loan", "Home Loan"
• Bill Type: "Electricity", "Credit Card", "Water"
• Payment Mode: "UPI", "NEFT", "Debit Card"

2.3 Implementation
Implementation is the stage in the project where the theoretical design is turned into the
working system and is giving confidence to the new system for the users i.e. will work
efficiently and effectively. It involves careful planning, investigation of the current system and
its constraints on implementation, design of method to achieve the changeover, an evaluation,
of change over methods. Apart from planning major task of preparing the implementation is
education of users. The more complex system is implemented, the more involved will be the
system analysis and design effort required just for implementation. An implementation
coordinating committee based on policies of individual organization has been appointed. The
implementation process begins with preparing a plan for the implementation for the system.
According to this plan, the activities are to be carried out; discussions may regarding the
equipment have to be acquired to implement the new system.
18
Implementation is the final and important phase. The most critical stage is in achieving a
successful new system and in giving the users confidence that the new system will work and
be effective. The system can be implemented only after thorough testing is done and if it found
to working according to the specification. This method also offers the greatest security since
the old system can take over if the errors are found or inability to handle certain types of
transaction while using the new system.
At the beginning of the development phase a preliminary implementation plan is created to
schedule and manage the many different activities that must be integrated into plan. The
implementation plan is updated throughout the Development phase, culminating in a
changeover plan for the operation phase. The major elements of implementation plan are test
plan, training plan, equipment installation plan, and a conversion plan.
There are three types of implementations:

• Implementation of a computer system to replace a manual system.

• Implementation of a new computer system to replace an existing system.
• Implementation of a modified application to replace an existing one, using the same
computer.
Successful implementation may not guarantee improvement in the organization using the new
system, but improper installation will prevent it. It has been observed that even the best system
cannot show good result if the analysts managing the implementation do not attend to every
important detail. This is an area where the systems analysts need to work with utmost care.
2.3.1 Conversion Methods:

A conversion is the process of changing from the old system to the new one. It must be properly
planned and executed. Four methods are common in use. They are Parallel Systems, Direct
Conversion, Pilot System and Phase In method.
2.3.2 Parallel system:
The most secure method of converting from an old to new system is to run both systems in
parallel. This method is safest one because it ensures that in case of any problem in using new
system, the organization can still fall back to the old system without the loss of time and
money.
The disadvantages of parallel systems approach are: •
It doubles operating costs.
• The new system may not get fair trial.

2.3.3 Post Implementation Review

After the system is implemented and conversion is complete, a review should be conducted to
determine whether the system is meeting expectations and where improvements are needed.
A post implementation review measures the systems performance against predefined
requirement. It determines how well the system continues to meet the performance
specifications.

19
 CHAPTER 3

PROJECT BRIEF
3.1 Profile of the Problem
The Bank Management System was created in response to several challenges faced by
traditional banking operations and to address the increasing complexity of financial transactions
in modern economies. Here are the key problems that led to the development of automated
banking management systems:

1. Manual Process Inefficiencies

Before the digital revolution, many banking processes were carried out manually,
including account opening, transaction processing, record-keeping, and generating
reports. This led to inefficiencies, errors, and delays in processing customer requests,
which was time-consuming for both bank employees and customers.

2. Increased Risk of Errors and Fraud

Human errors, such as incorrect data entry, manual calculation mistakes, or
mismanagement of physical records, were common in traditional banking systems.
Additionally, the lack of robust internal controls and auditing led to fraud,
embezzlement, and mismanagement of funds.

3. Difficulty in Managing Large Volumes of Transactions

As banking systems grew, especially with the advent of ATMs, internet banking, and
mobile banking, the volume of transactions increased exponentially. Traditional
systems struggled to manage the increasing load, causing delays, backlogs, and
customer dissatisfaction.

4. Lack of Centralized Data Access

Before automation, bank branches often operated as independent entities with separate
records and databases. This lack of centralized access to information made it difficult to
track customer accounts, balance inquiries, and generate reports across different
branches. It also led to discrepancies in account balances and customer details between
branches.

5. Slow and Inefficient Customer Service

In a manual banking environment, customers often faced long queues, slow processing
times, and delays in service, especially during peak hours or when accessing specialized
services like loan applications, account balance updates, and transaction processing.

6. Inability to Offer New Financial Products and Services

Traditional banking systems, which were typically designed for basic operations like
deposits and withdrawals, struggled to manage new and more complex financial
products like loans, investment accounts, mutual funds, and insurance.

7. Lack of Transparency and Accountability

Manual banking systems made it difficult to track and report on financial transactions,
which led to a lack of transparency and accountability in the banking process.

20
 Customers and auditors often faced challenges in ensuring that their transactions and
balances were accurate.

8. Limited Access to Banking Services

In traditional banking systems, banking services were confined to bank branches.
Customers had to visit branches during business hours to access their accounts or
perform financial transactions. This was especially problematic in rural areas where
access to banking services was limited.

9. Regulatory and Compliance Challenges

Banks must comply with various regulatory standards and legal requirements such
as Know Your Customer (KYC), Anti-Money Laundering (AML) rules, and other
government regulations. Manual systems struggled to ensure proper compliance,
resulting in risks of non-compliance penalties or reputation damage.

10. Growing Customer Expectations

As technology evolved, customers began to expect instantaneous services, 24/7
access, and personalized banking experiences. Traditional banking systems could not
meet these expectations effectively, leading to customer dissatisfaction and
competitive disadvantages.

3.2 Software development life cycle

The Software Development Life Cycle (SDLC) is a structured approach used in the
development of software, including banking systems like a Bank Management System. The
SDLC ensures that software development is efficient, reliable, and meets customer
requirements. Below is an overview of the SDLC phases for developing a Bank Management
System:
1. Planning and Requirement Gathering
Objective: The goal of this phase is to clearly understand the problem the banking system
will solve, and to identify functional and non-functional requirements of the system.
• Activities:
o Meet with stakeholders (bank employees, customers, and technical teams) to
understand the requirements.
o Identify core features such as account creation, transactions (deposit,
withdrawal), loan management, and bill payments.
o Define non-functional requirements like system performance, security,
scalability, and compliance with banking regulations.
o Develop a feasibility study to determine if the project is achievable in terms
of technology, resources, and budget.
• Output:
o Project plan
o Requirements specification document (Functional and non-functional
requirements)

2. System Design
Objective: The purpose of this phase is to define the overall system architecture and design
the database, user interface (UI), and software components.
• Activities:
o High-level system architecture design: Decide whether the system will be a
web-based or desktop-based application.
21
 o Database design: Create ER diagrams (Entity-Relationship diagrams) to model
the database. Define tables for customer details, transaction records, loan
accounts, etc.
o UI/UX design: Design wireframes for the user interface that allows easy access
to features like balance inquiry, loan applications, bill payments, and
transaction history.
o Security design: Plan for secure login systems (e.g., multi-factor
authentication), encryption of sensitive data, and compliance with regulations
such as KYC (Know Your Customer) and AML (Anti-Money Laundering).
• Output:
o System architecture document
o UI/UX wireframes
o Database schema
o Security protocols

3. Implementation (Coding/Development)
Objective: In this phase, actual coding takes place based on the designs created in the previous
step. Development teams write the code, implement the logic, and integrate various system
components.
• Activities:
o Set up the development environment, including tools, frameworks, and
programming languages (e.g., Python, Java, C++, etc.).
o Develop modules for core banking functionalities:
▪ Account management (create, update, delete, view)
▪ Transaction handling (deposits, withdrawals, transfers)
▪ Loan processing and payment
▪ Bill payments and service request management
o Implement the database and connect it to the application.
o Write unit tests for individual components to ensure correct functionality.
• Output:
o Source code
o Unit test results
o Database and application integration

4. Testing
Objective: The goal of the testing phase is to identify and fix bugs, verify system functionality,
and ensure that the Bank Management System meets the specified requirements.
• Activities:
o Unit Testing: Test individual components (functions or modules) to ensure they
work as expected.
o Integration Testing: Ensure that different system modules, like the account
module and transaction module, work seamlessly together.
o System Testing: Test the entire system for functionality, performance, security,
and stability.
o Acceptance Testing: Conduct User Acceptance Testing (UAT) with real users
(e.g., bank employees) to ensure the system meets business needs.
o Security Testing: Conduct vulnerability scans, penetration testing, and data
encryption validation.
• Output:
o Test reports
o Bug and issue reports
22
 o Finalized system ready for deployment

5. Deployment
Objective: This phase involves deploying the completed Bank Management System into the
live environment where it will be used by the bank staff and customers.
• Activities:
o Set up the live environment, ensuring that hardware, network, and software
resources are ready for deployment.
o Deploy the application on a production server or cloud infrastructure.
o Migrate data from legacy systems (if any) to the new banking system.
o Configure security measures and backup procedures.
o Provide training for bank staff on how to use the system.
• Output:
o Live system
o Deployment documentation
o User training materials

6. Maintenance and Support

Objective: After the system is live, it will need ongoing maintenance to fix issues, update
software, and add new features based on user feedback.
• Activities:
o Bug fixes: Address any issues or bugs identified by users or through automated
error tracking.
o Updates and enhancements: Roll out regular updates to improve functionality,
security, or performance.
o User support: Provide support for bank employees and customers, addressing
problems with account access, transactions, or other features.
o Monitoring: Continuously monitor system performance, track transactions, and
ensure uptime.
• Output:
o Maintenance logs
o Patches and updates
o User support documentation

SDLC Phases Summary

1. Planning and Requirement Gathering: Understand the business needs and define
system requirements.
2. System Design: Create the architecture, database design, and security protocols.
3. Implementation: Write the code and integrate various modules.
4. Testing: Verify that the system meets the requirements and functions properly.
5. Deployment: Deploy the system to production, making it available to users.
6. Maintenance and Support: Provide ongoing updates, bug fixes, and support.

3.3 Problem analysis

The Bank Management System (BMS) is designed to address several critical challenges in
the banking sector. Before building such a system, it is essential to analyse the problems faced
by banks and their customers in traditional banking systems, which motivates the need for
automation and more efficient solutions. The following are the key problems that led to the
creation of the Bank Management System:

23
1. Manual Processing and Human Errors
Problem: In traditional banking systems, many tasks such as account management, transaction
processing, and record-keeping were performed manually. This resulted in human errors, such
as incorrect entries, miscalculations, and delayed transactions. These errors caused
discrepancies in financial records, leading to financial mismanagement and customer
dissatisfaction.
• Impact: Increased chances of errors in financial transactions, account balance
discrepancies, delayed updates, and poor customer experience.
Solution: An automated Bank Management System reduces human intervention and ensures
accuracy in processing transactions, managing accounts, and generating reports, thereby
reducing errors and increasing efficiency.

2. Slow Transaction Processing

Problem: In a manual system, transactions like deposits, withdrawals, fund transfers, and loan
approvals took significant time due to manual verification and entry into ledgers. This created
bottlenecks, especially during peak hours or month-end closings, leading to long queues and
delays.
• Impact: Slow service delivery, especially during peak times, leading to customer
frustration and poor customer satisfaction.
Solution: A Bank Management System allows for real-time transaction processing, enabling
fast, efficient transactions that customers can perform instantly, either in-person or through
online banking services.

3. Lack of Centralized Data Management

Problem: In traditional systems, different branches of the bank maintained separate records,
making it difficult to obtain a unified view of customer data. For instance, customers could not
access their account information at other branches, and there was no centralized database for
real-time updates across the entire bank network.
• Impact: Discrepancies in account balances, data retrieval delays, difficulty in reporting,
and limited access to services across branches.
Solution: A centralized Bank Management System connects all branches and departments in
real-time, ensuring that customers can access their account information across branches, and
that all data is synchronized, improving accessibility and reducing errors.

4. Security and Fraud Risks

Problem: Manual record-keeping and a lack of automated security measures left banking
systems vulnerable to fraud, unauthorized access, and identity theft. Security risks like data
breaches, financial fraud, and inadequate transaction authentication were prevalent.
• Impact: Financial losses, regulatory penalties, and damage to the bank's reputation.
Solution: A modern Bank Management System integrates robust security protocols such as
multi-factor authentication, data encryption, and audit trails to track transactions, ensuring safe
and secure banking operations. Additionally, real-time monitoring for suspicious activities can
help prevent fraud.

5. Complexity in Managing Loans and Accounts

Problem: Manual management of loans, interest calculations, and account balances often led
to inaccuracies, errors, or delays in updating loan repayments, outstanding balances, and interest
calculations. Furthermore, manual processes lacked integration with other banking modules,
leading to disconnected operations.

24
 • Impact: Difficulty in managing loan applications, loan repayment schedules, and
interest calculations, leading to customer dissatisfaction, errors in loan accounting, and
delays in approvals.
Solution: The Bank Management System automates loan management, ensuring that loan
applications are processed quickly, repayment schedules are followed accurately, and interest
is calculated correctly. Automated integration across modules improves coordination between
accounts, loans, and transactions.

6. Regulatory Compliance Issues

Problem: Banks are subject to strict regulatory frameworks, including KYC (Know Your
Customer), AML (Anti-Money Laundering), and other financial regulations. Traditional
systems struggled to manage and document compliance, increasing the risk of non-compliance
penalties.
• Impact: Failure to comply with regulatory requirements could lead to legal issues, fines,
and damage to the bank's reputation.
Solution: A Bank Management System integrates automated compliance checks, helping banks
maintain up-to-date customer records, track suspicious activities, and automatically generate
reports for regulatory bodies, thus ensuring compliance and reducing the risk of legal issues.

7. Limited Customer Access and Services

Problem: In traditional banking systems, services were limited to bank branches, and customers
had to visit in person to access their accounts, make deposits, withdrawals, or request loans.
This limited the bank’s accessibility, particularly for customers in rural areas.
• Impact: Customers faced inconvenience and accessibility issues, especially those in
remote areas, leading to frustration and low customer retention.
Solution: A Bank Management System integrates online banking, mobile banking, and ATM
networks, allowing customers to access their accounts, perform transactions, and even request
loans from the comfort of their homes or offices. This increases accessibility and enhances
customer experience.

8. Difficulty in Reporting and Data Analysis

Problem: In manual systems, generating financial reports, tracking transaction histories, and
performing data analysis were time-consuming tasks. Manual reports were often delayed,
incomplete, and prone to errors.
• Impact: Inability to make real-time decisions, poor management oversight, and delays
in financial reporting for both internal and external stakeholders.
Solution: A Bank Management System provides automated reporting features that generate
real-time, accurate reports on transactions, account balances, and loan statuses. Data analysis
tools allow for better decision-making and financial forecasting.

9. High Operational Costs

Problem: The cost of manual labour, paperwork, data storage, and physical infrastructure was
high in traditional banking systems. Moreover, managing large volumes of transactions without
automation added significant overhead.
• Impact: Increased operational costs, reduced profitability, and inefficiencies in resource
allocation.
Solution: By automating processes such as account management, transactions, loan processing,
and compliance reporting, a Bank Management System reduces manual labor and lowers
operational costs. It also allows for the optimization of resources and improves profitability.

25
10. Customer Experience and Satisfaction
Problem: Long queues, slow transaction processing, limited access to services, and poor
communication between the bank and its customers resulted in a poor customer experience.
• Impact: Loss of customers, reduced customer loyalty, and negative impact on the bank’s
reputation.
Solution: A Bank Management System enhances customer experience by offering fast, efficient
services, 24/7 access to accounts through mobile apps, automated notifications for transactions
and loan updates, and self-service options such as ATMs and online banking platforms.

3.4 Feasibility analysis

Feasibility analysis is a critical step in the Bank Management System (BMS) development
process. It helps determine whether the project is achievable, both in terms of resources and
technology, and whether it will meet the business needs of the bank. Feasibility analysis
typically considers four major aspects: technical feasibility, operational feasibility, economic
feasibility, and legal feasibility. Below is a detailed breakdown of each aspect for the
development of a Bank Management System.

1. Technical Feasibility
Objective: To assess whether the required technology and resources are available to
successfully implement the Bank Management System.
• Technology Requirements:
o Programming Languages: The system can be developed using programming
languages like Python, Java, or C++ for backend development, and HTML, CSS,
JavaScript, or frameworks like React.js or Angular for the frontend (if web-
based).
o Database: MySQL, PostgreSQL, or Oracle can be used for managing customer
data, transactions, and account information.
o Platform: The system can be web-based, desktop-based, or mobile-based
(iOS/Android) depending on the bank's needs.
o Security Tools: Implementation of secure protocols like SSL/TLS for data
encryption, OAuth for authentication, and AES for securing sensitive customer
data.
o Integration with Existing Infrastructure: The system should integrate with
existing systems such as ATMs, payment gateways, and legacy software for
smooth transition and operation.
• Evaluation:
o The current technological infrastructure (servers, database management
systems) is capable of handling the required resources and expected user load.
o Development tools and technologies are readily available, and developers have
the required skillset.
o The system is scalable and capable of handling increasing amounts of data and
users over time.
• Conclusion:
o Technically feasible: The required technologies, infrastructure, and tools are
available, and development teams have the necessary skills to execute the
project.

26
2. Operational Feasibility
Objective: To evaluate whether the Bank Management System will work effectively within the
current operational structure of the bank and meet user needs.
• Stakeholder Requirements:
o The system must cater to the needs of bank employees, customers, and system
administrators.
o It must allow for easy access to accounts, transaction history, and loan
information for employees and customers.
o The system should support real-time transactions and provide easy-to-navigate
interfaces for self-service banking.

• Operational Challenges:
o User Adoption: The system must be user-friendly and intuitive for both tech-
savvy and non-technical users (bank staff, customers).
o Training Requirements: Bank staff must be trained to use the new system, which
could take time and resources.
o Data Migration: Migrating data from older systems to the new system without
causing disruptions to existing services.
• Evaluation:
o The new system aligns with the bank's operational workflows and integrates
with existing processes (such as account opening, loan approval, and payment
processing).
o The system is easy to use, and staff training requirements are manageable.
o There is a clear plan for data migration, and any operational disruptions are
minimized.
• Conclusion:
o Operationally feasible: The system can be implemented effectively in the bank’s
current operations, with appropriate training and minimal disruption.

3. Economic Feasibility
Objective: To assess whether the development and implementation of the Bank Management
System will be financially viable for the bank.
• Cost Estimates:
o Development Costs: Includes costs for software development (coding, testing,
debugging), project management, and initial setup costs.
o Hardware Costs: Includes any upgrades needed for servers, storage, or network
infrastructure.
o Operational Costs: Recurring expenses such as system maintenance, support
staff, software updates, and cloud hosting costs.
o Training Costs: Costs for training employees and customers on the new system.
• Benefits:
o Efficiency Gains: Reduced time spent on manual tasks like data entry and
transaction processing, leading to higher productivity.
o Cost Savings: Reduced operational costs due to automation, especially in areas
like account management, loan processing, and transaction handling.
o Improved Customer Satisfaction: Faster service, reduced errors, and better
access to banking services lead to increased customer loyalty and new
customers.

27
 • Return on Investment (ROI):
o The initial investment in the system can be offset by long-term benefits,
including reduced labour costs, higher customer retention, and the ability to
scale services more efficiently.
• Evaluation:
o Initial costs for development and implementation may be high, but the long-term
savings and revenue benefits from improved operational efficiency and
customer satisfaction justify the investment.
o The bank can expect a positive ROI in a few years due to efficiency
improvements and enhanced service offerings.
• Conclusion:
o Economically feasible: The project is financially viable, with high long-term
benefits that outweigh the initial costs.

4. Legal Feasibility
Objective: To ensure that the Bank Management System complies with all applicable laws,
regulations, and standards in the banking industry.
• Regulatory Compliance:
o The system must adhere to KYC (Know Your Customer) regulations for
customer verification, which require secure data management practices.
o The system must comply with AML (Anti-Money Laundering) requirements,
ensuring that it can flag suspicious transactions and keep detailed logs for
auditing purposes.
o The system must ensure data protection in accordance with GDPR (General Data
Protection Regulation) or Indian IT Act to ensure the security and privacy of
customer data.
• Data Security Laws:
o The Bank Management System should be compliant with data encryption
standards, such as AES (Advanced Encryption Standard), and provide secure
communication channels for online transactions.
o There should be audit trails to ensure traceability of every action performed in
the system, ensuring accountability and transparency.
• Evaluation:
o All necessary security measures, including data encryption, audit logs, and
secure communication, will be implemented.
o Compliance with regulations like KYC, AML, and data privacy laws will be
ensured through the inclusion of automated compliance features.
• Conclusion:
o Legally feasible: The system will comply with all relevant laws and regulations,
ensuring it can be implemented without legal complications.

3.5 Project plan

1. Defining a problem:
• Define a problem.
• Justify the needs for a computerized solution.
• Identify the functions to be provided by the systems along with the constraints.
• Determine goal and requirements of the system.

28
 • Establish the high-level acceptance criteria.

2. Developing a solution strategy:

• Outline several solution strategies. Do not consider constraints for the time being.
• Conduct a feasibility strategy, including why the other strategies are rejected.
• Develop a list of priorities for the product characteristics.

3.6 Planning the development process:

• Define a life cycle model and an organizational structure for the project.
• Plan the configuration management, quality assurance and validation activities.
• Establish the preliminary cost estimates, the schedule and the staffing estimates for
System development.
• Develop preliminary estimates for the computing resources required to operate and
maintain the system.

SIZE

COST DEVELOPMENT
ESTIMATION TIME

RESOURCES
REQUIREMENT

PROJECT
SCHEDULING

Figure: 3.1 Activities during software project planning

29
3.7 Size estimation:
Size estimation is the process of determining the size of the software based on its functionality,
complexity, and required resources. For a Bank Management System, the goal is to estimate
how large the system is in terms of its components and the effort needed to develop it.
There are various methods to estimate the size of a software project. Below is a basic overview
of the most common methods for size estimation:

1. Function Point Analysis (FPA)

Function Points (FP) measure the functionality provided by the system based on the user’s
perspective. The size of the system is estimated by identifying the key functions (e.g.,
customer account management, transaction processing, loan management, etc.) and assigning
each function a score based on its complexity (simple, average, or complex). The sum of these
scores gives the total function points, which helps estimate the system's size.
• Example: If the Bank Management System has 5 main functions (like account
management, transaction processing, loan management), each with varying
complexities (simple, average, complex), you assign a value to each and calculate the
total FP.

2. Lines of Code (LOC)

The Lines of Code (LOC) estimation method involves predicting the number of lines of code
required to implement the system. This is based on the system's complexity and the
programming language used. The system's size is estimated by multiplying the number of
function points by a factor (typically 50–100 lines of code per function point).
• Example: If the system has 45 function points, and each point represents an average
of 75 lines of code, the total LOC would be estimated as 26 FP × 50 LOC = 1,300
lines of code.

3. Use Case Points (UCP)

Use Case Points estimate the system size based on use cases, which are the various tasks or
interactions that users will perform with the system (e.g., account creation, money transfer).
Each use case is evaluated for its complexity (simple, average, complex), and the total points
help estimate the system size.

4. COCOMO Model
COCOMO (Constructive Cost Model) uses the number of lines of code (LOC) to estimate
the effort (in person-months) required to develop the system. It’s a mathematical model that
factors in the type of project (simple, medium, complex) and the team's productivity.
• Example: If you have 1,300 lines of code (LOC), the COCOMO model can be used
to calculate the estimated effort (in terms of person-months).

3.8 Cost estimation:

For any software project, it is necessary to know how much it will cost to develop and how
much development time it will take. These estimates are needed before development is
initiated. In many cases estimates are made using experience as the only guide.

1. Requirements Analysis and Design

• Time and Effort: Gathering user requirements, designing system architecture, and
planning.
• Estimated Cost:
30
 o ₹166,000–₹415,000

2. Development
• Coding in C++: The actual development of the system's core features, including
customer account management, transaction processing, security, etc.
• Time: 3–6 months of full-time development.
• Estimated Cost:
o ₹1,245,000–₹7,968,000

3. Database Design and Integration

• Time: Designing and setting up the database (e.g., MySQL, PostgreSQL) for customer
data, transactions, etc.
• Estimated Cost:
o ₹199,200–₹1,328,000

4. Testing
• Types of Testing: Unit testing, integration testing, system testing, and user acceptance
testing.
• Time: 1–2 months.
• Estimated Cost:
o ₹415,000–₹1,660,000

5. Deployment and Maintenance

• Deployment: Setting up the system in a production environment, which may involve
server setup and configuration.
• Ongoing Maintenance: After deployment, ongoing support for bug fixes, performance
optimization, and updates.
• Estimated Cost:
o Deployment: ₹166,000–₹415,000
o Ongoing Maintenance: ₹166,000–₹415,000/month

6. Additional Costs
• Software Licensing: If third-party libraries or commercial tools (e.g., for encryption,
security) are required.
o Estimated Cost: ₹41,500–₹415,000
• Hardware: If you need special infrastructure (e.g., servers for deployment).
o Estimated Cost: ₹83,000–₹830,000
• Security and Compliance: Adherence to regulatory standards such as PCI-DSS, GDPR,
or others.
o Estimated Cost: ₹415,000–₹1,660,000

Total Estimated Cost (INR)

• Basic / Small-Scale System: ₹2,000,000 – ₹5,000,000 (₹20 Lakhs to ₹50 Lakhs)
• Medium-Scale / Advanced System: ₹5,000,000 – ₹12,000,000 (₹50 Lakhs to ₹1.2
Crore)
• Large-Scale / Highly Complex System: ₹12,000,000 – ₹20,000,000+ (₹1.2 Crore to ₹2
Crore)

31
Key Factors Affecting the Cost:
• Project Scope: More features (e.g., online banking, mobile integration, complex loan
systems) will drive costs up.
• Development Team: The hourly rate of developers in India varies based on experience
and location. Freelancers may charge less, while developers in top cities (Bengaluru,
Mumbai, Delhi) or with specialized skills (security, advanced C++) may charge more.
• Security & Compliance: Financial systems need high-level security and adherence to
legal standards, which can add to the cost.
These estimates are indicative and will vary depending on the specific requirements, region,
and complexity of the project. To get a more accurate estimate, it's essential to define the
scope and specific features of the bank management system clearly before initiating
development.

3.9 Hardware & software requirements:

1. Hardware Requirements
The hardware requirements for a BMS can vary based on the size and complexity of the system.
Here’s a breakdown for small to medium-scale systems, along with scalability considerations
for larger systems:

A. Server Requirements
• Processor (CPU):
o For small-scale systems: Intel i5 or equivalent (4 cores, 2.5 GHz+)
o For medium-scale systems: Intel Xeon or AMD Ryzen (6–8 cores, 3.0 GHz+)
o For large-scale systems: High-end Xeon or AMD EPYC (12–16 cores, 3.0
GHz+)
• RAM:
o Small-scale: 8 GB RAM
o Medium-scale: 16 GB to 32 GB RAM
o Large-scale: 64 GB+ RAM
• Storage (Hard Disk):
o Small-scale: 500 GB SSD or 1 TB HDD (for testing and low traffic)
o Medium-scale: 2 TB SSD / RAID Array for redundancy and faster I/O
o Large-scale: 5 TB+ SSD or Enterprise-class RAID for high availability and data
protection
• Network:
o Gigabit Ethernet (1 Gbps) for regular traffic
o 10 Gbps network cards and switches for larger systems or systems with heavy
transaction loads.
• Backup:
o Backup storage (e.g., external HDD or Cloud backup services) for data
protection and disaster recovery.

B. Workstations/Client Devices
• For Development & Testing:
o Processor: Intel i5 / i7 or equivalent
o RAM: 8 GB to 16 GB
o Storage: 250 GB SSD (minimum)
o Display: Full HD (1920x1080) or better
o OS: Windows 10/11 or Linux (Ubuntu, CentOS, etc.)
32
 • For Client Access (End users, bank staff, admins):
o Devices with standard internet connectivity, such as desktops, laptops, or
terminals.
o OS: Windows, macOS, or Linux (depending on organizational standards).

C. Security Hardware (Optional)

• Firewalls & Intrusion Detection Systems (IDS/IPS) to protect sensitive data.
• Hardware Security Modules (HSMs) or TPMs for encryption key management
(especially for financial transactions).
• Backup Power (UPS) to ensure uninterrupted operation in case of power failure.

2. Software Requirements
A Bank Management System developed in C++ typically uses various software tools, libraries,
and frameworks to ensure smooth functioning, security, and scalability. Here's a breakdown of
the core software requirements:

A. Development Environment
• Programming Language: C++ (with libraries like STL, Boost, OpenSSL for security,
etc.)
• Integrated Development Environment (IDE):
o Visual Studio (for Windows-based systems)
o CLion, Eclipse CDT, or Code::Blocks (cross-platform options)
o GCC (GNU Compiler Collection) for Linux development.
• Version Control:
o Git (for source code management)
o GitHub / GitLab / Bitbucket (for repository hosting and collaboration)
• Build Tools:
o CMake (build automation tool)
o Make or Ninja (for compiling and managing builds)

B. Database Management System (DBMS)

The database is a critical component for storing and managing user and transaction data.
• Relational Database:
o MySQL (open source, widely used)
o PostgreSQL (open-source, robust, and scalable)
o Oracle Database (enterprise-grade, but can be costly)
• NoSQL Database (for scalable data storage or for non-relational data):
o MongoDB
o Cassandra
• Database Management Tools:
o phpMyAdmin / pgAdmin for managing databases via GUI (optional)
o Navicat or DBeaver for database design and management.

C. Web Server / Application Server

• For Web-based Access (if implementing a web-based admin panel or user interface):
o Apache HTTP Server or Nginx (for web serving)
o Tomcat or Node.js (for backend application management if using web
frameworks like Node.js for APIs)

D. Frameworks and Libraries

• C++ Libraries:
33
 o Boost (general-purpose, cross-platform C++ libraries)
o OpenSSL (for implementing SSL/TLS encryption in the application)
o Qt (if the system has a GUI for administrators or users)
o SQLite (if using a lightweight database for smaller, embedded systems)
• Multithreading/Concurrency Libraries:
o Boost Asio or std::thread (to handle concurrent user requests and transactions
efficiently)
• Security Libraries:
o OpenSSL or Crypto++ for encryption of sensitive data like passwords,
transaction details, etc.
o JWT (JSON Web Tokens) for implementing secure user authentication and
session management.

E. Operating System
• For Development:
o Windows 10/11 (for C++ development in Visual Studio)
o Linux (for server-side deployment and development using GCC)
o macOS (for macOS-specific applications or cross-platform development)
• For Server-side Deployment:
o Linux (Ubuntu, CentOS, RedHat) – most used for server deployment due to its
stability, security, and cost-effectiveness.
o Windows Server (for enterprise environments that prefer Microsoft-based
solutions)

F. Security Software
• Antivirus / Anti-malware Software: Essential for protecting the development and
production environments.
• Firewall: Ensuring secure access to databases and applications.
• SSL Certificates: For encrypting sensitive data during transmission (e.g., HTTPS).
• Encryption Software: Tools for securing sensitive information, especially for financial
transactions.

G. Testing and Debugging Tools

• Unit Testing Frameworks:
o Google Test (for unit testing C++ code)
o Catch2 (for writing unit tests in C++)
• Debugging Tools:
o GDB (GNU Debugger) for debugging C++ code
o Valgrind (for memory leak detection and performance profiling)
o Static Analysis Tools: Clang Static Analyzer, CppCheck (for code quality and
bug detection)

H. Backup and Recovery Software

• Database Backups:
o mysqldump for MySQL backups
o pg_dump for PostgreSQL backups
• System Backup:
o rsync or Duplicity for full system or incremental backups.

I. Cloud Services (Optional for Large-scale Systems)

• Cloud Storage:
34
 o AWS S3, Azure Blob Storage, or Google Cloud Storage for storing backups,
logs, or large datasets.
• Cloud Hosting / Virtualization:
o AWS EC2, Google Cloud Compute Engine, or Microsoft Azure Virtual
Machines for deploying the system at scale.
• Containerization:
o Docker and Kubernetes for scalable, containerized application deployment.

3.10 Front End Details:

The header files listed for the Bank Management System (BMS) suggest that the application
is likely to be console-based and designed for a simple, text-driven user interface (UI). This
type of application is suitable for environments where a graphical interface is not necessary,
such as for terminal-based applications or for environments where minimal resources are
available.
Here is a breakdown of how each of these header files might be used in the front-end of the
system and their associated functionality:

1. Overview of Header Files

a. #include <fstream>
• Usage: This header is used for file handling (reading from and writing to files).
• Front-End Use:
o Used to store and retrieve account data (such as account details, transactions)
from a text file or binary file (e.g., .txt or .dat files).
o It allows users' data to be persisted across sessions, so account information is
saved even when the application is closed.
b. #include <cstring> and #include <string.h>
• Usage: These headers provide functions for handling C-style strings and operations
like comparing, copying, concatenating strings, etc.
• Front-End Use:
o Used for manipulating input data such as usernames, account numbers, and
passwords.
o Functions like strcmp, strcpy, strlen, and strcat may be used for string
operations on user input and validation.
c. #include <iomanip>
• Usage: This header is used for input/output formatting, such as setting the width,
precision, and alignment of output data.
• Front-End Use:
o Helps format monetary values, such as account balances, deposits, withdrawals,
and transaction history.
o Used to ensure consistent output formatting (e.g., displaying balances to two
decimal places).
d. #include <cstdio>
• Usage: This header provides functions for C-style I/O operations such as printf, scanf,
fopen, etc.
• Front-End Use:
o Commonly used for formatted output (like printf) and for interacting with files
(e.g., opening a file to save user data or logs).
o It can be used to display messages to the user and capture user input.

35
e. #include <conio.h>
• Usage: This header is specific to DOS/Windows-based environments and provides
functions like getch(), clrscr(), gotoxy(), etc.
• Front-End Use:
o getch() is often used for capturing a single character input, useful for password
entry where characters are not displayed on the screen.
o clrscr() can be used to clear the screen, which is useful for refreshing the
console UI after each operation.
o gotoxy() can be used for cursor positioning, allowing better control over where
text appears in the terminal.
f. #include <ctime>
• Usage: Provides functions for date and time handling.
• Front-End Use:
o Useful for recording timestamps for transactions (e.g., when a deposit or
withdrawal occurs).
o Displaying current date/time on the user interface (e.g., showing the last login
time, or time of transaction).
g. #include <stdlib.h>
• Usage: Provides functions for memory allocation, random number generation, process
control, and conversions.
• Front-End Use:
o Functions like system("cls") (to clear the screen) and exit() (to terminate the
program) can be used.
o Random number generation (rand()) can be used for generating random account
numbers or PINs.
h. #include <bits/stdc++.h>
• Usage: This is a common catch-all header that includes most of the C++ Standard
Library headers. It's often used in competitive programming or projects where multiple
libraries are required.
• Front-End Use:
o It can be useful if your system needs various C++ Standard Library functions,
such as data structures (e.g., vectors, maps), input/output functions, etc.
o May also include functionalities for advanced string manipulations, file
handling, and more.

2. Designing the Front-End in C++

Given that this system is likely console-based, the front-end design will primarily rely on
text-based interactions, formatted outputs, and simple menu navigation.

3. Explanation of the Code

• Main Menu (displayMenu): This function displays a simple text menu and waits for
the user to input their choice. The menu includes options to create a new account, view
account details, deposit funds, and withdraw funds.
• Account Creation (createAccount): When the user selects the "Create New Account"
option, the system prompts the user to enter the account holder's name and initial
deposit. A random account number is generated, and the account details are saved to a
file (accounts.txt).
• View Account (viewAccount): The user can input their account number to retrieve
their details. The system reads from the file (accounts.txt) and displays the account
information if the account number is found.

36
 • File Handling: The account information is saved in a file (accounts.txt), making it
persistent across application rest

3.11 Back-end details:

Back-end part of a system is more important because it controls all the internal process
of a system. I have chosen XAMPP local database as back end. Because it is word’s Most
Capable relational database and provide more security than others.
Why MySQL?
MySQL is the world's most popular open-source database software, with over 100 million
copies of its software downloaded or distributed throughout its history. With its superior speed,
reliability, and ease of use, MySQL has become the preferred choice for Web, Web 2.0, SaaS,
ISV, Telecom companies and forward-thinking corporate IT Managers because it eliminates the
major problems associated with downtime, maintenance and administration for modern, online
applications.
Many of the world's largest and fastest-growing organizations use MySQL to save time and
money powering their high-volume Web sites, critical business systems, and packaged software
including industry leaders such as Yahoo!, Alcatel-Lucent, Google, Nokia, YouTube,
Wikipedia, and Booking.com.
The flagship MySQL offering is MySQL Enterprise, a comprehensive set of production-tested
software, proactive monitoring tools, and premium support services available in an affordable
annual subscription.
MySQL is a key part of WAMP (Window, Apache, MySQL, PHP), the fast-growing open source
enterprise software stack. More and more companies are using WAMP as an alternative to
expensive proprietary software stacks because of its lower cost and freedom from platform
lock-in.

Draw context
Diagram

Draw
Prototypes

Model the
Requirement

Finalize the
Requirement

Figure 3.2: Requirement analysis steps

37
1. Draw Context Diagrams

The context diagram is a simple model that defines the boundaries and interfaces of the
proposed system with the external world. It identifies the entities outside the proposed system
that interact with the system
2. Development of Prototype
One effective way to find out what the customer really wants is to construct a prototype,
something that looks and preferably acts like a part of the system they want.

3. Model the Requirement

This process really consists of various graphical representations of functions, data entities,
external entities and the relationship between them. The graphical view may help to find
incorrect, inconsistent, missing and superfluous requirement.

4. Finalize the Requirements

After modelling the requirements, we will have better understanding of the system behaviour.
The inconsistencies and ambiguities have been identified and corrected.

38
 CHAPTER 4
FUNCTIONAL REQUIREMENTS
A Bank Management System (BMS) is designed to handle essential banking operations such
as account creation, deposits, withdrawals, transaction history, and other banking
functionalities. These operations ensure that both customers and bank staff can perform
necessary tasks in a secure, efficient, and user-friendly manner.
Below are the functional requirements for a Bank Management System developed in C++.

1. User Authentication and Authorization

• Login System:
o The system should allow users (bank customers and staff) to log in using a valid
username and password.
o Customers should have access to personal accounts, while staff should have
access to account management and other administrative functions.
o Secure password management (password hashing) should be implemented.
• Logout:
o Users should be able to log out securely from the system.

2. Customer Account Management

• Create New Account:
o Bank staff should be able to create new customer accounts by providing
customer details like name, address, initial deposit, and account type (e.g.,
savings, current).
o The system should generate a unique account number for each customer.
o The account details should be stored in a file or database for persistence.
• View Account Details:
o Customers should be able to view their account details such as name, account
number, balance, and account type.
o The system should retrieve account details from the stored data (e.g., text file or
database).
• Edit Account Details:
o Bank staff should have the ability to update account details, such as changing
customer information, updating the account type, or modifying other personal
details.
• Delete Account:
o Bank staff should be able to delete customer accounts after proper validation and
ensuring there are no pending transactions or balances.

3. Transaction Management
• Deposit Funds:
o Customers should be able to deposit money into their accounts.
o The system should update the account balance accordingly and provide a
receipt of the deposit.
o The transaction should be logged with the date and time of the deposit.
• Withdraw Funds:
o Customers should be able to withdraw money from their accounts.
o The system should check if the balance is sufficient for the requested
withdrawal and prevent overdrafts.
39
 o The transaction should be logged, and a receipt should be provided.
• Transfer Funds:
o Customers should be able to transfer funds between their own accounts or to
other customers' accounts within the same bank.
o The system should verify the account numbers and balance before processing
the transfer.
o A transaction receipt should be generated.

4. Transaction History
• View Transaction History:
o Customers should be able to view their transaction history, including deposits,
withdrawals, and transfers.
o The history should show details such as transaction ID, date, amount, and
balance after transaction.
o Bank staff should also be able to view transaction histories for individual
customers as part of account management.

5. Balance Inquiry and Account Status

• Check Account Balance:
o Customers should be able to check their current account balance anytime,
including after deposits, withdrawals, or transfers.
• Account Status:
o Customers should be able to check the status of their account, such as whether
it is active or closed. The system should provide the status of the account based
on the available data.

6. Reporting and Auditing (Admin Functionality)

• Generate Reports:
o Bank staff should be able to generate reports for different activities, such as daily
deposits, withdrawals, transfers, and account balances.
o Reports should be available as printable or viewable data (in text or CSV
format).
• Audit Trail:
o The system should maintain an audit trail of actions performed (such as account
creation, balance updates, transfers, etc.) for security and compliance purposes.
o This log should be accessible by bank staff but protected from tampering.

7. Security and Data Protection

• Password Encryption:
o User passwords should be encrypted using a hashing algorithm (e.g., SHA256
or bcrypt) to enhance security.
o Ensure that passwords are not stored in plain text.
• Access Control:
o Customers should only have access to their own accounts and transaction
histories.
o Bank staff should have higher privileges to manage and edit customer accounts,
but access control should be enforced.
• Session Management:
o After a certain period of inactivity, the system should log out the user
automatically to protect sensitive information.

40
 • Secure File Handling:
o When using files to store account and transaction data, ensure that files are
protected from unauthorized access. Sensitive data should be securely stored and
properly validated before use.

8. User Interface (Console-based)

• Menu System:
o The system should display a clear, easy-to-navigate menu where users can select
options like Create Account, Deposit Funds, Withdraw Funds, Check
Balance, etc.
o Use clear prompts to guide users through each step (e.g., "Enter your account
number," "Enter deposit amount," etc.).
• Error Handling and Validation:
o Input data should be validated to prevent invalid data entry, such as non-
numeric characters for account numbers or deposit/withdrawal amounts.
o If an invalid input is detected, the system should show an error message and
prompt the user to try again.
o The system should prevent invalid transactions, such as attempting to withdraw
more money than is available in the account.

9. Data Storage and File Management

• Data Persistence:
o Customer account information, transactions, and other data should be stored in
files (e.g., .txt, .dat, or a basic database) to ensure data is retained between
application sessions.
o Files should be used for storing data such as account numbers, balances,
transaction histories, and user login information.
• Backup and Recovery:
o The system should periodically back up critical data, and restore functionality
should be available in case of data corruption or system failure.

10. Additional Functionalities (Optional)

• Interest Calculation:
o If implementing a savings account, the system should periodically calculate and
apply interest on the balance based on a fixed rate.
• Loan Management:
o Implement basic loan management features, where customers can apply for
loans, view loan balances, and make loan payments.

4.1 Non-functional requirement

Non-functional requirements define how the system should behave and address aspects such
as performance, usability, security, scalability, and reliability. While functional requirements
specify what the system should do, non-functional requirements outline the quality attributes
that the system should have to ensure it performs optimally under various conditions.
Here are the key non-functional requirements for a Bank Management System (BMS)
developed in C++:

41
1. Performance Requirements
• Response Time:
o The system should respond to user input within 2-3 seconds for typical
operations such as login, account balance inquiry, and transaction processing.
o For complex tasks like generating transaction history reports, the system should
respond within 5-10 seconds depending on the volume of data.
• Throughput:
o The system should be capable of handling multiple transactions simultaneously,
with the ability to handle at least 50 transactions per second for moderate-scale
usage.
• Transaction Processing Time:
o For deposit, withdrawal, or fund transfer operations, the system should process
the transaction and update the database (or files) within 1 second.

2. Reliability Requirements
• System Availability:
o The system should be available and operational at least 99.9% of the time, with
minimal downtime for maintenance.
o The system should allow for scheduled backups to ensure data safety without
significant disruption to normal operations.
• Error Handling and Fault Tolerance:
o The system should gracefully handle input errors (e.g., invalid account number,
insufficient balance) and show clear, understandable error messages to the user.
o The system should not crash or cause data corruption in case of errors, such as
invalid input or transaction failures.
• Backup and Recovery:
o The system should have the capability to perform regular backups of account
data, and it should ensure that the data can be recovered in case of a system
failure (e.g., from backups or logs).

3. Security Requirements
• Data Encryption:
o All sensitive data, such as account details, passwords, and transaction history,
should be encrypted when stored or transmitted to protect against unauthorized
access.
o Passwords should be hashed and salted before storing them in files or databases
to prevent exposure of user credentials.
• Authentication and Authorization:
o Only authorized users (bank customers and staff) should be allowed to access
specific features based on their role. Customers should only access their own
account details, while bank staff should have broader access for account
management.
o The system should implement multi-level authentication for staff access, such
as login credentials combined with security codes for admin roles.
• Session Management:
o Sessions should automatically expire after a period of inactivity (e.g., 15
minutes), requiring the user to log in again to prevent unauthorized access.
o Users should be logged out securely when they choose to exit the system.

42
 • Audit Trails and Logging:
o The system should maintain an audit trail for all user actions, including login
attempts, transactions, account modifications, etc. This log helps track and
review actions for security and compliance purposes.

4. Usability Requirements
• User Interface (UI) Design:
o The user interface (console-based in this case) should be simple, intuitive, and
easy to navigate.
o Clear prompts should be provided for each user action (e.g., "Enter your account
number", "Deposit amount").
o Error messages should be concise and provide suggestions for correction (e.g.,
"Invalid account number. Please try again.").
• Documentation:
o Comprehensive user documentation should be provided to help users understand
how to interact with the system, including how to create an account, deposit
funds, check balances, and manage transactions.
o Admin users should have separate documentation for managing system
operations, reports, and account issues.
• User Training:
o The system should include help screens or guides for new users (bank staff and
customers) to assist in their initial interactions with the system.

5. Scalability Requirements
• Data Storage Scalability:
o The system should be designed in a way that it can handle a growing number of
customers and accounts. As the number of users increases, the system should be
able to handle larger data files or move to a more scalable database solution if
needed.
• Performance under Load:
o As the user base grows, the system should be able to handle increased
transaction volume without significant degradation in response time.
o The system should be able to scale to hundreds or thousands of accounts and
handle increased transaction frequencies.

6. Maintainability and Support Requirements

• Code Maintainability:
o The code should be modular and well-commented to ensure easy maintenance
and updates in the future.
o Proper naming conventions, consistent indentation, and clear function
definitions should be used to make the codebase easy to understand and
maintain.
• Error Logging and Debugging:
o The system should include error logging features to help track and diagnose
issues. The logs should be structured for easy analysis (e.g., showing timestamp,
error type, user actions, etc.).
o A debugging mode should be available to allow developers to trace issues during
development or testing phases.
• System Updates and Patch Management:
o The system should support the ability to apply patches or updates (e.g., to fix
bugs or improve features) without major downtime.
43
7. Compatibility Requirements
• Platform Compatibility:
o The Bank Management System should run on common operating systems, such
as Windows, Linux, or macOS, given that it is a console-based application.
o The system should be able to function properly in a terminal or console window,
with no dependency on external GUI libraries (unless a GUI is planned for future
versions).
• Data Format Compatibility:
o The system should support common file formats for storing and exchanging
data, such as text files (.txt), comma-separated values (CSV), or basic database
formats.

8. Compliance Requirements
• Regulatory Compliance:
o The system must comply with local financial regulations, such as maintaining
user privacy, storing personal data securely, and ensuring that all banking
transactions are properly recorded and auditable.
o If applicable, the system should comply with data protection laws (e.g., GDPR
for EU-based systems, CCPA for California-based systems) for storing personal
information and user data.
• Transaction Logging:
o The system should keep detailed logs of all transactions, including the time of
occurrence, user ID, amount, and account involved. These logs may be used for
auditing and dispute resolution.

9. Availability and Reliability Requirements

• High Availability:
o The system should ensure minimal downtime, especially during peak periods
(e.g., end of the month or during business hours).
o If the system is running on a server, there should be redundant systems or
failover mechanisms to maintain high availability in case of a failure.
• Backup and Restore:
o Regular data backups should be performed to prevent data loss.
o The system should have disaster recovery capabilities, including the ability to
restore the data and application state to a previous point in time in case of failure.

10. Localization and Internationalization Requirements (Optional)

• Multiple Languages:
o The system should support multiple languages (if needed), allowing users to
interact with the system in their preferred language. This is particularly
important for systems deployed in regions with diverse linguistic needs.
• Currency Support:
o The system should handle multiple currencies (if applicable), allowing users to
view balances and perform transactions in their local currency.

4.2 System design

The system design for a Bank Management System (BMS) defines the overall structure of the
system, specifying the components, interactions, and technologies that come together to achieve

44
the desired functionality. In this case, since we are discussing a console-based C++
application, the system design focuses on the structure of the application, how components
interact with each other, and how data is stored and managed.

1. High-Level Architecture
The Bank Management System is designed using a modular architecture. Each module
focuses on a specific functionality, and modules communicate with each other as needed.
Key Components of the System:
• User Interface (UI): Handles user input and displays results.
• Account Management: Handles operations like creating accounts, viewing account
details, and updating account information.
• Transaction Management: Manages deposits, withdrawals, transfers, and transaction
history.
• Data Storage: Stores account and transaction data persistently, usually in text files or
binary files.
• Security: Ensures authentication, authorization, and secure handling of data (passwords,
transaction details).
• Logging and Audit: Logs user actions and maintains an audit trail for security and
troubleshooting.
The architecture is client-server-like, where users (clients) interact with the system through the
UI, and the system (server) processes the data and communicates with the storage layer.

2. Functional Components
The system can be broken down into the following functional components:

A. User Interface (UI)

• Description: Handles interaction with the user in the form of text-based menus,
prompts, and results.
• Responsibilities:
o Display menus to users (e.g., main menu, account management options).
o Capture user inputs (e.g., deposit amount, account number).
o Display results or error messages.
o Provide a simple, clear, and efficient navigation system.
• Tools Used:
o Console-based interaction using standard C++ libraries (e.g., iostream,
conio.h for getch() to capture input).
o Functions like clrscr() (clear screen), gotoxy() (move cursor) to create a
more dynamic interface.

B. Account Management Module

• Description: Manages customer accounts, including creating, editing, viewing, and
deleting accounts.
• Responsibilities:
o Create new accounts (generate unique account numbers, store details).
o View account details (balance, account type).
o Update account information.
o Delete accounts.
o Ensure proper data validation (e.g., unique account number, valid input).
• Tools Used:
o File Handling: Uses fstream or ofstream/ifstream to read and write account
data to text files (e.g., accounts.txt).
45
 o String Manipulation: cstring or string.h for handling account holder names,
passwords, etc.

C. Transaction Management Module

• Description: Manages deposits, withdrawals, transfers, and transaction history.
• Responsibilities:
o Handle deposits and withdrawals (validate account balance, update
balance).
o Support fund transfers between accounts (validate account numbers, ensure
sufficient funds).
o Track and store transaction history.
o Generate receipts for transactions.
• Tools Used:
o File I/O: Transaction logs are stored in files (e.g., transactions.txt).
o Mathematical Operations: Ensure proper calculations for balance updates
(e.g., deposits, withdrawals).
o Date and Time: Use ctime to capture transaction timestamps.

D. Security Module
• Description: Ensures the security of user data and access control.
• Responsibilities:
o Handle user login with username/password (authentication).
o Encrypt sensitive data such as passwords.
o Ensure users only have access to their own accounts.
o Log out users after a timeout or manual logout.
• Tools Used:
o Password Handling: Use basic string manipulation and encryption
techniques (e.g., hashing passwords using std::hash).
o Access Control: Define roles (customer, bank staff) and restrict access to
certain features based on roles.
o File I/O: For storing user credentials (securely, using hashing or simple
encryption).

E. Data Storage Layer

• Description: Stores account information, transaction history, and other relevant data
persistently.
• Responsibilities:
o Store account details (names, account numbers, balances).
o Store transaction history.
o Ensure data is persistent even when the program is closed or restarted.
• Tools Used:
o Text Files/Binary Files: Using fstream for reading/writing to text files like
accounts.txt and transactions.txt to store data.
o File Organization: The system uses simple file-based storage with structured
data (CSV or delimited format).

F. Logging and Audit Module

• Description: Logs system activities and tracks user actions for audit purposes.
• Responsibilities:
o Record each transaction (deposit, withdrawal, transfer).
o Log user login/logout events.
46
 o Maintain a history of all interactions for compliance and troubleshooting.
• Tools Used:
o File I/O: Log entries are saved to a separate file (e.g., audit_log.txt).
o Text Formatting: Use iomanip for formatting logs.

3. Data Flow and Interaction

Process Flow
1. User Login:
o The user inputs their login credentials (username/password).
o The system validates the credentials by reading the stored user data (e.g., from
users.txt).
o On successful login, the user is presented with the main menu based on their role
(customer or staff).
2. Main Menu:
o The user selects an option (e.g., Create Account, Deposit, Withdraw, View
Account).
o The system retrieves and processes the corresponding data (e.g., account
balances, transactions).
3. Account Management:
o For operations like creating or viewing accounts, the system reads or writes to
the account file (accounts.txt).
o The system uses user input to perform operations (e.g., deposit amount) and
updates the balance accordingly.
4. Transaction Processing:
o When the user initiates a transaction (e.g., deposit, withdrawal, or transfer), the
system checks for sufficient funds and performs the transaction.
o Transaction details (such as date, amount, and transaction type) are logged into
transaction history files (transactions.txt).
5. Logging and Audit:
o Every user action (including login, account modification, and transactions) is
recorded in the audit log (audit_log.txt).
o These logs provide a trail of user actions for compliance and security purposes.

4. Data Models
A. Account Data Model
Each account will have the following attributes:
• Accounts are stored in a text file or binary file, with each account's data on a
new line.
B. Transaction Data Model
Each transaction will be recorded with:
• Transactions are stored in a separate file (transactions.txt).

5. Data Storage (File Organization)

• accounts.txt (Stores account details)
• transactions.txt (Stores transaction history)
• audit_log.txt (Logs all user activities)
4.3 Design notations
The DFD also known as the Bubble Chart is a simple graphical formalism that can be used to
represent a system in terms of the input data to the system. Various processing carried out on

47
these data, and the output data generated by the system. The main reason why the DFD
technique is so popular is probably because DFD is a very simple formalism-it is simple to
understand and use. A DFD uses a very limited number of primitive symbols to represent the
functions performed by a system and the data flow among these functions. Starting with a set
of high-level functions that a system performs, a DFD model hierarchically represents various
sub functions

4.4 User characteristics

User characteristics describe the types of users who will interact with the Bank Management
System, their specific roles, and the attributes and behaviour that define how they use the
system. Understanding user characteristics helps in designing the user interface, system
functionality, and access control.
1. Customer (End User)
Description:
• The customer is a person who uses the Bank Management System to manage their own
accounts, check balances, and perform transactions like deposits, withdrawals, and
transfers.
Key Characteristics:
• Role: Regular customer of the bank.
• Access Rights:
o View: Can view their own account details (balance, account type, transaction
history).
o Perform Transactions: Can perform deposits, withdrawals, and fund transfers
(within the limits of their account balance).
o Account Management: Can request account modifications (e.g., change of
password, view statements).
o Security: Must authenticate using a username and password to access their
account. The password should be encrypted for security.
Expected Behaviour:
• Customers will typically:
o Log in to view their account details or perform transactions.
o Deposit money into their account or withdraw funds as needed.
o Transfer money between their own accounts or to others.
o Request a transaction history or balance statement.
o Log out once finished to ensure their account is secure.
System Interaction:
• User Interface:
o Interacts with the system through menus that allow for easy navigation between
features such as deposit, withdrawal, account details, etc.
o The customer will use input fields to perform transactions (e.g., enter withdrawal
amount).
• Authentication:
o The customer will need to authenticate with a username and password. The
system should validate credentials before allowing access.
• Error Handling:
o The system should provide clear, user-friendly error messages, such as
"Insufficient funds" when the customer tries to withdraw more than their
balance, or "Invalid account number" if they enter an incorrect account.

48
2. Bank Staff / Administrator
Description:
• A bank staff member (or administrator) manages customer accounts, performs
administrative tasks, and supervises daily operations. This role has more privileges than
a customer.
Key Characteristics:
• Role: Bank staff, typically employees such as clerks or administrators responsible for
handling customer accounts and supervising transactions.
• Access Rights:
o Full Account Access: Bank staff can view and modify all customer accounts
(e.g., change account details, deactivate accounts).
o Transaction Oversight: Bank staff can view transaction history for all customers
and can perform administrative transactions like modifying account balances.
o Add/Remove Users: Can create new accounts for customers and remove or
suspend accounts in case of fraud or other issues.
o Generate Reports: Can generate transaction and account-related reports for
internal auditing or customer inquiries.
Expected Behaviour:
• Bank staff will typically:
o Log in using a secure staff account with administrative privileges.
o Access and modify customer accounts, such as changing account details or
performing administrative actions.
o Handle customer inquiries related to account balance, transaction status, etc.
o Administer system configurations or user account settings.
o Manage and update the system logs for auditing purposes.
System Interaction:
• User Interface:
o Bank staff will interact with the system through a more comprehensive admin
interface that allows access to all customers’ data and administrative
functionalities.
o The interface might include additional menus for handling customer account
management, reporting, and other administrative functions.
• Authentication:
o Bank staff will have more robust authentication mechanisms, such as multi-
factor authentication (e.g., username/password and a one-time passcode) to
ensure secure access to sensitive operations.
• Error Handling:
o The system should alert the bank staff to issues that need administrative
attention, such as potential fraud alerts, or insufficient permissions for a certain
operation.

3. System / Security Administrator

Description:
• The system administrator is responsible for managing the overall security and
configuration of the Bank Management System (BMS). This user manages the system’s
settings, including security features, user roles, and backups.
Key Characteristics:
• Role: IT staff or system administrator responsible for maintaining the security and
performance of the BMS.

49
 • Access Rights:
o Complete Access: Has full access to the entire system, including user
management, system configurations, security settings, and data backups.
o Security and Privacy: Responsible for ensuring data privacy, implementing
encryption, and auditing user activities.
o Backup Management: Manages backups of the system, ensuring data is regularly
backed up and can be restored in the event of a failure.
o System Monitoring: Monitors the health of the system and ensures that it is
operating as expected without disruptions.
Expected Behaviour:
• The system administrator will:
o Configure the system and assign roles to users (such as customers and bank
staff).
o Perform regular security checks (e.g., ensure passwords are hashed, encryption
is active).
o Monitor system logs for errors, unauthorized access, and potential security
threats.
o Manage system updates and patches.
System Interaction:
• User Interface:
o The system administrator interacts with a specialized interface (e.g., command-
line or management console) for configuring the system and managing user roles
and security settings.
o The administrator interface may have features to reset user passwords, configure
access control lists (ACLs), and perform other administrative tasks.
• Authentication:
o The system administrator will authenticate with the most secure access method
available, likely involving multiple layers of security (e.g., encrypted passwords,
two-factor authentication).
• Error Handling:
o The system should generate alerts in case of security breaches, unauthorized
access attempts, or system failures.

4. Guest / Unauthenticated User

Description:
• A guest user is someone who has not logged in or authenticated. They may have limited
access to the system or just be browsing through public-facing functionalities, such as
checking general information about the bank.
Key Characteristics:
• Role: Typically, a person who does not yet have an account with the bank or has not
logged in.
• Access Rights:
o Limited Access: Guests can typically only access basic information such as bank
policies, terms of service, and possibly contact details for customer support.
o No Transaction Access: Guests cannot perform any transactions or access
sensitive information (e.g., their account balances, transaction history).
Expected Behaviour:
• The guest will typically:
o Browse the bank’s public-facing website or app, if applicable.
o Request more information about the bank, including services and contact details.
o Register for an account if they wish to become a customer of the bank.
50
System Interaction:
• User Interface:
o Guests interact with the system in a very limited way through a public-facing
interface. They can access basic menus and view general information but are
restricted from performing any banking operations.
• Authentication:
o No authentication is required for guest users. However, they may be prompted
to create an account or log in to access banking services.

5. Interaction Flow for Different Users

Customer Interaction Flow:
• Login:
o The customer enters their username and password.
o The system validates the credentials.
o On successful login, the customer is presented with a menu of options (e.g.,
check balance, make a deposit, view transaction history).
• Perform Actions:
o The customer can choose to make a deposit, withdrawal, or transfer funds, and
the system will handle the transaction logic.
o The customer can view their transaction history or check their account balance.
• Log Out:
o After completing their operations, the customer logs out securely to ensure their
data is protected.
Bank Staff Interaction Flow:
• Login:
o The bank staff member logs in using their credentials.
o The system validates their credentials and grants access to an administrative
interface.
• Account Management:
o The bank staff member can view and edit customer accounts, process
transactions, or generate reports.
o They can create new accounts or suspend accounts as needed.
• Log Out:
o After completing administrative tasks, the bank staff logs out securely.
System Administrator Interaction Flow:
• Login:
o The system administrator logs in with a highly secure method (e.g., multi-factor
authentication).
• System Configuration:
o The administrator configures system settings (e.g., user roles, access control).
o They manage security features such as password encryption, backups, and data
privacy settings.
• Monitor and Maintain:
o The administrator monitors system health and ensures that data is securely stored
and backed up.
o They perform necessary updates and patches.
• Log Out:
o The administrator logs out after performing system maintenance tasks.
51
4.5 Entity Relationship Diagram
Entity relationship diagrams are a way to represent the structure and layout of a database. It is
used frequently to describe the database schema. ER diagrams are very useful as they provide
a good conceptual view of any database, regardless of the underlying hardware and software.
An ERD is a model that identifies the concepts or entities that exist in a system and the
relationships between those entities. An ERD is often used to visualize a relational database:
each entity represents a database table, and the relationship lines represent the keys in one table
that point to specific records in related tables.
ERDs may also be more abstract, not necessarily capturing every table needed within a
database, but serving to diagram the major concepts and relationships. This ERD is of the latter
type, intended to present an abstract, theoretical view of the major entities and relationships
needed for management of electronic resources. It may assist the database design process for
an e-resource management system but does not identify every table that would be necessary for
an electronic resource management database.
OBJECTS

There are three main objects on an ER Diagram:

1. Entities
2. Relations
3. Attributes
1. Entities:
An entity is a concept or object in the database. Entities are concepts within the data model.
Each entity is represented by a box within the ERD. Entities are abstract concepts, each
representing one or more instances of the concept in question. An entity might be
considered a container that holds all the instances of a particular thing in a system. Entities
are equivalent to database tables in a relational database, with each row of the table
representing an instance of that entity.
2. Attributes:
The Account Number, Account Holder Name, Account Type etc. A given attribute
belonging to a given entity occurrence can only have one value. Therefore, if a supplier
could have more than one address or telephone number then this should be determined
before defining the attributes of that entity type. In this example the defined entity may
require two or three address and/or telephone number attributes. It is the maximum practical
instances of a given attribute that should be catered for in the entity type definition.
3. Relationships:
Relations are the connections between two or more entities. Relationship lines indicate that
each instance of an entity may have a relationship with instances of the connected entity,
and vice versa. Each entity type can always be described in terms of attributes, and these
attributes will apply to all occurrences of that given entity type.

52
 CHAPTER 5

FINAL DESIGN SCREENS

Figure 5.1: Main Menu

Figure 5.2: Customer Menu

53
Figure 5.3: Account Management Menu

Figure 5.4: Creating New Account

54
 CHAPTER 6

CONCLUSION AND FUTURE SCOPE

Conclusion

The Bank Management System (BMS) developed in C++ aims to provide an efficient, reliable,
and secure solution for managing customer accounts, transactions, and administrative functions
in a banking environment. The system successfully implements key functionalities such as:
• Account Management: Allows customers to create, view, and modify their accounts. It
provides the flexibility to manage account details such as balance and account type.
• Transaction Handling: Facilitates transactions like deposits, withdrawals, and transfers,
with proper validation to ensure secure and accurate operations.
• Security: The system incorporates basic security mechanisms, including user
authentication (login using username/password), to protect sensitive data and ensure
that only authorized users can perform certain actions.
• Data Storage: Implements persistent storage using file handling (e.g., text files) to store
account details, transaction history, and logs, ensuring data is retained even after the
system is shut down.
• User Interface: A simple and intuitive text-based menu system, which allows both bank
customers and bank staff to interact with the system easily.
The project has met the initial goals of creating a functional, console-based application that
manages various aspects of banking. It can perform essential banking operations, ensuring data
integrity, and providing a secure environment for users.

Future Scope

While the current Bank Management System serves its basic purpose, there are several areas
where the system can be enhanced and expanded in the future. Below are some potential
improvements and future scope of this project:
1. Integration with Database Management System (DBMS)
• Current Limitation: The system uses text files for storing data, which can be inefficient
and prone to data corruption in case of system crashes.
• Future Scope: Transitioning the storage system from text files to a robust Database
Management System (DBMS) like MySQL, SQLite, or PostgreSQL would allow better
data management, data integrity, and more complex queries. A relational database would
enable scalable data storage, facilitate complex reporting, and provide greater flexibility
for future expansion.
2. Graphical User Interface (GUI)
• Current Limitation: The current system is a console-based application, which may not
be as user-friendly or visually appealing as a modern GUI-based application.
• Future Scope: Implementing a Graphical User Interface (GUI) using frameworks such
as Qt or wxWidgets in C++ would enhance the user experience. A GUI would make it
easier for users to navigate through the system, visually monitor account balances and
transaction history, and perform actions using buttons, forms, and interactive elements.
3. Multi-User and Multi-Session Support
• Current Limitation: The current system does not support concurrent access by multiple
users or handle multiple sessions at the same time.

55
 • Future Scope: Implementing multi-threading or networking functionality could allow
multiple users to interact with the system simultaneously. A server-client model could
be implemented to allow a multi-user environment where different customers and bank
staff members can access the system at the same time without interfering with each
other’s sessions.
4. Mobile Application Integration
• Current Limitation: The system is designed for desktop usage and is not optimized for
mobile devices.
• Future Scope: With the increasing reliance on mobile devices for banking, the system
could be extended into a mobile banking app. Developing a mobile application for
Android or iOS using cross-platform tools such as Flutter or React Native could provide
greater accessibility to customers. This would allow users to access their accounts,
check balances, and perform transactions on-the-go.
5. Advanced Security Features
• Current Limitation: The current system implements basic security measures like
password authentication but lacks advanced security features.
• Future Scope: To enhance security, the system could integrate two-factor authentication
(2FA), data encryption for sensitive information (e.g., account balances, transaction
data), and role-based access control (RBAC) for more granular security measures.
Biometric authentication (e.g., fingerprint or face recognition) could be added to
improve the security of the system.
6. Reporting and Analytics
• Current Limitation: The system does not currently offer advanced reporting or analytics
features.
• Future Scope: Incorporating reporting and analytics features would allow bank staff and
administrators to generate reports on customer activity, transaction trends, and system
usage. Features such as transaction summaries, account statistics, and audit logs would
provide valuable insights for decision-making and system optimization.
7. Integration with Real-time Payment Systems
• Current Limitation: The system currently only supports basic local transactions within
the bank (e.g., deposits and withdrawals) and does not support real-time transactions or
integration with external payment systems.
• Future Scope: Integrating the BMS with real-time payment systems (e.g., UPI, NEFT,
RTGS) or digital wallet services (e.g., Paytm, Google Pay) could allow users to perform
external transactions, pay bills, and transfer money between different banks and
payment services in real-time.
8. Support for Multiple Currencies
• Current Limitation: The current system is designed for a single currency (presumably
INR).
• Future Scope: The system could be enhanced to support multiple currencies, allowing
users to manage accounts in different currencies and perform cross-currency
transactions. This could be especially useful in banks that deal with international clients
or multiple regions.
9. Artificial Intelligence (AI) and Chatbot Integration
• Current Limitation: The system currently lacks advanced AI features.
• Future Scope: AI can be integrated to provide automated customer support via a chatbot.
The chatbot could assist with basic banking queries, guide customers through
transaction processes, and answer common questions. Additionally, AI could be used to
detect fraudulent activities by analyzing transaction patterns and alerting the bank staff.
10. Cloud Deployment

56
• Current Limitation: The system is currently designed to run on a local machine or
desktop environment.
• Future Scope: Migrating the system to the cloud (e.g., AWS, Azure) would make it
easier to scale, access remotely, and provide more robust backup and disaster recovery
features. Cloud deployment would also ensure better performance and availability.

57
 REFERENCES
Web References Date Accessed
• https://www.cplusplus.com/reference/ 1.10.24
• https://www.geeksforgeeks.org/file-handling-c-classes/ 1.10.24
• https://www.tutorialspoint.com/cplusplus/index.htm 2.10.24
• https://owasp.org/ 2.10.24
• https://www.geeksforgeeks.org/cryptography-in-cpp/ 2.10.24
• https://dev.mysql.com/doc/ 6.10.24
• https://www.sqlite.org/docs.html 6.10.24
• https://www.geeksforgeeks.org/c-plus-plus/ 8.10.24
• https://stackoverflow.com/questions/tagged/c%2b%2b 8.10.24
• https://medium.com/tag/software-engineering 9.10.24
• https://www.tutorialspoint.com/cplusplus/cpp_files_streams.htm 9.10.24

58