Laboratory Manual Of Software Engineering

(III B.Tech-I Semester)

Software Requirements Specification Document

for
Automated Teller Machine

Student Details

Name Of the Student J Kartheek Reddy

Roll Number 21881A0528

Class III B.Tech CSE-A

Subject SOFTWARE ENGINEERING

Academic Year 2023-24

Faculty Incharge
Dr S.Venu Gopal
 Case Study-1
Automated Teller Machine

1
Problem Statement
The State Bank of India is set to implement an Automated Teller Machine (ATM) system,
aiming to offer convenient withdrawal services for its customers, regardless of their physical
presence at a bank. A dedicated software will be developed to oversee ATMs equipped with
a magnetic stripe reader for ATM card validation, a customer console for user interaction, a
deposit slot for envelopes, a cash dispenser (in denominations of Rs.100), and a printer for
issuing customer receipts. The bank utilizes computers for internal account management and
transaction processing.

The ATM is designed to cater to one customer at a time, requiring the insertion of an ATM
card and entry of a Personal Identification Number (PIN). Both the card and PIN will be sent
to the bank for validation during each transaction. Once validated, the customer can execute
one or more transactions. The ATM will retain the card until the customer indicates the com-
pletion of transactions.

Transactions will be communicated to the bank for verification. In case of an invalid PIN,
the customer must re-enter it for the transaction to proceed. After three unsuccessful at-
tempts, the machine permanently retains the card, necessitating the customer to contact the
bank for retrieval. If a transaction fails for reasons other than an invalid PIN, the ATM will
display an explanation and inquire whether the customer wishes to initiate another transaction.

For error resolution due to hardware failures during transactions, the ATM maintains an inter-
nal transaction log. Entries are made during startup and shutdown, message exchanges with
the bank, cash dispensing, and envelope receiving. The log entries may include card numbers
and amounts but never contain PINs for security reasons.

To access the ATM facility, customers must hold an account with the bank and apply for
an ATM card. Each customer may have one or more accounts, limited to one ATM card per
account. The bank also offers SMS updates for every customer account transaction. To receive
updates, customers need to register their mobile numbers with their accounts at the bank.

2
Contents
1 Introduction 4
1.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Definitions, Acronyms and Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5
1.4 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.5 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Overall Description 6
2.1 Product Perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Product Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 User Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.5 Assumptions and Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.5.1 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.5.2 Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3 External Interface Requirements 10

3.1 User Interface Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2 Hardware Interface Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3 Software Interface Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.4 Communication Interface Requirements . . . . . . . . . . . . . . . . . . . . . . . 12

4 System Features 12
4.1 Remote Banking and Account Management . . . . . . . . . . . . . . . . . . . . 12
4.2 Reciept Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

5 Other Non-Functional Requirements 13

5.1 Performance Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1.1 Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1.2 Dynamic requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1.3 Quality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.2 Software System Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.2.1 Reliability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.2.2 Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.2.3 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.2.4 Maintainability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.3 Business Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

6 Other Requirements 16

7 Appendix A: Glossary 16

3
1 Introduction
The software ATMExcl 3.0TM Version 1.0 is to be developed for Automated Teller Ma-
chines (ATM). An automated teller machine (ATM) is a computerized telecommunications
device that provides a financial institution’s customers a secure method of performing financial
transactions, in a public space without the need for a human bank teller. Through ATMExcl
3.0TM, customers interact with a user-friendly interface that enables them to access their
bank accounts and perform various transactions.

1.1 Purpose
This SRS defines External Interface, Performance, and Software System Attributes require-
ments of ATMExcl 3.0TM. This document is intended for the following group of people:
• Developers for the purpose of maintenance and new releases of the software.
• Management of the bank.
• Documentation writers.
• Testers.

1.2 Scope
This document applies to Automated Teller Machine software ATM 3.0TM. This software
facilitates the user to perform various transactions in his account without going to the bank.
This software offers benefits such as cash withdrawals, balance transfers, deposits, inquiries,
credit card advances, and other banking-related operations for customers. It also allows the
administrator to fix the tariffs and rules as and when required.
The software takes as input the login Id and the bank account number of the user for
login purposes. The outputs then comprise an interactive display that lets the user select the
desirable function that he wants to perform.
The software is expected to complete in a duration of six months, and the estimated cost is
Rs18 lakhs.

4
1.3 Definitions, Acronyms and Abbreviations

AC Alternate Current

AIMS ATM Information Management System

ATM An unattended electronic machine in a public place, connected to a data system and
related equipment and activated by a bank customer to obtain cash withdrawals and
other banking services.

Braille A system of writing and printing for blind or visually impaired people, in which varied
arrangements of raised dots representing letters and numerals are identified by touch

BMS Bank Management Software

CDMA Code Division Multiple Access - A reliable data communication protocol

CMS Card Management Software

DES Data Encryption Standard

Dial-up Message format for low-cost communication

POS

Electronic For easier, safer information storage, related to modem

Journal

Internet An interconnected system of networks that connects computers around the world via
the TCP/IP protocol

MB Mega Bytes

Ms milli seconds

Sec Seconds

Smart Card without hardware which stores the user‘s private keys within a tamper proof
Card software guard

Tactile Specil Keyboard for visually impaired

Keyboard

TCP/IP Transmission Control Protocol/ Internet Protocol

V Volts

VGA Video Graphics Adapter

5
1.4 References
• www.google.com
• www.wikipedia.com
• IEEE SRS Std 830-1993
• Chevy Chase Bank, UMBC Branch
• Russel c.Bjork Requirements Statement for Example ATM System
• URL: https://www.math-cs.gordon.edu/local/courses/cs211/ATMExample

1.5 Overview
The Software Requirements Specification (SRS) document presents a comprehensive outline of
requirements and specifications for the development, implementation, and testing of an Auto-
mated Teller Machine (ATM) system. It serves as a pivotal guide for developers, testers, project
managers, and stakeholders, delineating functional and non-functional elements crucial for a
robust, secure, and user-centric ATM software. This document delves into user interactions,
transaction processing, security measures, user interface design, and hardware integration, fo-
cusing solely on software requirements while omitting hardware specifics and banking policies.
Structured into multiple sections, it offers clarity on system functionalities and constraints,
catering to diverse stakeholders involved in the development lifecycle, aiming to ensure align-
ment with project objectives and user expectations.

2 Overall Description
2.1 Product Perspective
The proposed Automated Teller Machine (ATM) system functions as an independent entity
within the banking infrastructure. While it directly engages with the bank’s core database
systems for transaction processing and account information retrieval, it operates autonomously
in terms of user interactions and transaction execution. Real-time connectivity to the central
banking network is not a constant requirement; instead, the system periodically synchronizes
data and validates transactions using secure communication protocols. This design allows the
ATM system to seamlessly integrate with existing banking software, guaranteeing compatibil-
ity and compliance with industry standards like ISO 8583 for transaction messaging and EMV
specifications for card authentication and security.

The ATM system interfaces with various hardware components, including card readers, cash
dispensers, receipt printers, and security modules, ensuring a secure and user-friendly banking
experience. It’s essential to emphasize that while the system interacts with external networks
and databases, it maintains a self-contained environment to ensure reliability and security, even
in the face of intermittent network disruptions.

6
2.2 Product Functions
1. User Authentication
• Function: Verify user identity before allowing access to account information or trans-
actions.
• Features: PIN-based authentication, card scanning, biometric verification (if sup-
ported), and account validation.
2. Transaction Processing
• Function: Facilitate various financial operations for users.
• Features: Cash withdrawals, cash deposits, fund transfers between accounts, balance
inquiries, mini statements, PIN change, and currency conversions.
3. Security Measures
• Function: Ensure the security and integrity of user data and transactions.
• Features: Data encryption for communication, secure PIN entry, card retention mech-
anisms in case of suspicious activities, anti-skimming technology, and periodic security
updates.
4. User Interface
• Function: Provide an intuitive and user-friendly interface for interactions.
• Features: Clear graphical user interface (GUI) displaying transaction options, multi-
language support, accessibility features for visually impaired users, and error handling
guidance.
5. Hardware Integration
• Function: Interact with physical components of the ATM.
• Features: Reading bank cards through card readers, dispensing cash through cash
dispensers, printing transaction receipts via receipt printers, and ensuring secure con-
nectivity.
6. System Monitoring and Maintenance
• Function: Ensure continuous operation and facilitate maintenance procedures.
• Features: Monitoring system health, self-diagnostic capabilities, alert notifications for
maintenance requirements, and remote updates for software enhancements.
7. Error Handling and Recovery
• Function: Manage errors and recover from failures to maintain user confidence and
system reliability.
• Features: Error code identification and display, transaction rollback in case of failure,
and fallback mechanisms for offline transactions.

7
2.3 User Profiles
1. End Users
• Description: General banking customers who engage with the ATM for diverse fi-
nancial transactions.
• Characteristics:
(a) Diverse demographic profile, encompassing individuals of various ages, backgrounds,
and technical competencies.
(b) Varying levels of technological familiarity, ranging from tech-savvy users to those
with limited digital literacy.
(c) Expectations for a banking experience that is simple, intuitive, and secure.
2. Bank Staff and Maintenance Personnel
• Description: Personnel responsible for ATM installation, maintenance, and trou-
bleshooting.
• Characteristics:
(a) Technical expertise in ATM operations, hardware maintenance, and software trou-
bleshooting.
(b) Need access to diagnostic tools and administrative functions for system monitoring
and maintenance.
(c) Swift response and resolution to technical issues to minimize downtime.
3. Administrators and System Managers
• Description: Individuals overseeing the overall functioning and performance of the
ATM system.
• Characteristics:
(a) Proficiency in system management, covering configuration settings, security pro-
tocols, and software updates.
(b) Authorization for system-wide changes, access control management, and adherence
to regulatory compliance standards.
(c) Responsible for ensuring system integrity, security, and compliance with banking
regulations.
4. Security and Compliance Personnel
• Description: Personnel dedicated to ensuring the security and regulatory compliance
of the ATM system.
• Characteristics:
(a) Expertise in cybersecurity measures, including encryption protocols, threat assess-
ment, and risk mitigation strategies.
(b) Knowledge of banking regulations and standards, ensuring the ATM system’s com-
pliance with legal and industry requirements.
(c) Continuous monitoring and evaluation of system vulnerabilities and potential se-
curity threats.

8
2.4 Constraints
The major constraints that the project has are as follows:
• The ATM must service at most one person at a time.
• The number of invalid PIN entries attempted must not exceed three. After three unsuc-
cessful login attempts, the card is seized/blocked and needs to be unlocked by the bank.
• Simultaneous access to an account through both the ATM and the bank is not supported.
• The minimum amount of money a user can withdraw is Rs 100/-, and the maximum
amount of money a user can withdraw in a session is Rs. 10,000/-. The maximum amount
he can withdraw in a day is Rs 20,000/-.
• Before the transaction is carried out, a check is performed by the machine to ensure that
a minimum amount of Rs 1000/- is left in the user‘s account after the withdrawal, failing
which the withdrawal is denied.
• The minimum amount a user can deposit is Rs 100/-, and the maximum amount he can
deposit is Rs 10,000/-.
• A user can select only that cellular operator for mobile bill clearings that is supported by
the bank.
• The software requires a minimum memory of 20GB.
• The database used should be Oracle 7.0.
• There shall be a printer installed with the machine to provide the user with the printed
statement of the transaction.
• For voice interactions, speakers should also be there to accompany the machine.

2.5 Assumptions and Dependencies

2.5.1 Assumptions

• Stable Power Supply: The ATM system relies on a consistent and reliable power supply
to ensure continuous operation during regular use.
• Internet Connectivity: It assumes stable internet connectivity for real-time transaction
processing and communication with the bank’s servers.
• Compliance with Regulatory Changes: The assumption is made that regulatory
requirements and standards will remain relatively stable during the system development
phase. Updates will be accommodated as necessary post-deployment.

2.5.2 Dependencies

• Vendor Support and Compatibility: The successful implementation of the ATM sys-
tem depends on vendor support for hardware components and their compatibility with the
software.
• External APIs and Interfaces: There is a dependency on third-party APIs and in-
terfaces for functionalities such as currency conversion, transaction authorization, and
communication with banking networks.
• Availability of Skilled Personnel: The system relies on the availability of skilled tech-
nicians and support personnel for maintenance and troubleshooting.

9
3 External Interface Requirements
3.1 User Interface Requirements
1. A login screen is provided at the beginning for entering the required username/pin no.
and account number.
2. An unsuccessful login leads to a reattempt (maximum three) screen for entering the same
information again. The successful login leads to a screen displaying a list of supported
languages from which a user can select any one.
3. In case of the administrator, a screen will be shown having options to reboot system, shut
down system, block system, disable any service.
4. In case of reboot/shut down, a screen is displayed to confirm the user‘s will to reboot and
also allows the user to take any backup if needed.
5. In case of blocking system, a screen is provided asking for the card no. By entering the
card number of a particular user, system access can be blocked for him.
6. The administrator is also provided with a screen that enables him to block any service
provided to the user by entering the name of the service or by selecting it from the list
displayed.
7. After the login, a screen with a number of options is then shown to the user. It contains
all the options along with their brief description to enable the user to understand their
functioning and select the proper option.
8. A screen will be provided for the user to check his account balance.
9. A screen will be provided that displays the location of all other ATMs of the same bank
elsewhere in the city.
10. A screen will be provided for the user to perform various transactions in his account.

Reports Generated

The following reports will be generated after each session dealt with in the machine:

1. The login time and logout time along with the user‘s pin no and account number are
registered in the bank‘s database.
2. The ATM‘s branch ID through which the session is established is also noted down in the
bank‘s database.
3. Various changes in the user‘s account after the transactions, if any, are reported in the
database.
4. A printed statement is generated for the user displaying all the transactions he performed.

10
Other User Interface Requirements

Various user interface requirements that need to be fulfilled are as follows:

• The display screen shall be of 10” VGA color type.
• The display screen shall have 256 color resolution.
• The display screen shall also support touchscreen facility.
• The speakers shall support Yamaha codecs.
• The keypad shall consist of 16 tactile keys.
• There shall be 8 tactile function keys.
• The keyboard will be weather resistant.
• The transaction receipt shall be 3.1” × 6”.
• The statement receipt shall be 4.2” × 12”.
• The deposit envelopes shall be 9” long and 4” wide.

3.2 Hardware Interface Requirements

For the proper functioning of the software, certain hardware interface requirements must be
met, as outlined below:
• The ATM power supply must include a manual switch for toggling between 110V and
220V AC.
• The ATM card is expected to adhere to specific physical dimensions:
– Width: 85.47mm - 85.72mm
– Height: 53.92mm - 54.03mm
– Thickness: 0.76mm ± 0.08mm
• The card reader is designated to be a magnetic stripe reader.
• The card reader should also provide a Smart card option.
• The card slot in the reader may feature an additional indentation to accommodate the
embossed area of the card. This indentation serves as a polarization key, aiding in the
correct insertion orientation of the card. This feature complements the magnetic field
sensor, which operates based on the magnetic stripe and is utilized to open a mechanical
gate in devices like ATMs.

11
3.3 Software Interface Requirements
In order to perform various functions, this software needs to interact with various other software.
So there are certain software interface requirements that need to be fulfilled:
• The transaction management software used to manage the transaction and keep track of
resources shall be BMS version 2.0.
• The card management software used to verify pin no and login shall be CMS version 3.0.
• Yamaha codec 367/98 for active speakers.
• The database used to keep a record of user accounts shall be Oracle version 7.0.

3.4 Communication Interface Requirements

The machine is required to establish communication with the main branch during each session,
facilitating various functions like login verification, account access, and more. Consequently, the
following communication interface requirements must be met to ensure the successful operation
of the software:
• The system will employ dial-up POS with the central server for low-cost communication.
• The communication protocol used shall be TCP/IP.
• The protocol used for data transfer shall be File Transfer Protocol (FTP).

4 System Features
4.1 Remote Banking and Account Management
Description: The system offers users the capability of remote banking, carrying out diverse
functions through an interface without the involvement of a human bank teller. The opera-
tional sequence of the system unfolds as follows:

• At the start, the user is provided with a login screen and is required to enter his PIN NO.
and Account details, which are then verified by the machine.
• In case of an unsuccessful attempt, the user is asked again for his credentials, but the
maximum number of attempts given to the user is limited to 3 only. Failing which, his
card is blocked and needs to be unblocked by the bank for any future use.
• After a successful login, the user is presented with a list of languages. The user can select
any one in the list for interaction with the machine for the entire session.
• After the language selection, the user is also asked whether he wants to fix that language
for future use so that he is never asked for language in the future. In addition, there is
also a facility for the user to switch to any other language during that session.
• After the language selection, the user is directed towards a main page that displays a
set of options/services along with their brief description, enabling the user to understand
their functioning. The user can select any of the listed options and can continue with the
transaction.

12
 • The machine also provides the user with a number of miscellaneous services such as:
– The machine lists a set of operators that are supported by the bank. A user can clear
off his pending mobile phone bills by selecting his operator.
– The machine also has the facility to display a map that marks the location of other
ATMs of the same bank in the city. This may help the user to look for the ATM
nearest to his destination.
• At any moment if the user wants to abort the transaction, he is provided with an option
to cancel it. Just by pressing the abort button, he can cancel all the changes made so far
and can begin with a new transaction.
• After the user is finished with his work, for security purpose, he is required to log out and
then take his card out of the slot.

4.2 Reciept Generation

After each transaction user has performed, a receipt is generated that contains all the informa-
tion about the transaction. The format of the generated receipt is as shown below:-

JKR BANK
Branch name/Id (address)
Login Time:-
Date:-
Account No:-
User Name:-
TRANSACTIONS:
FROM TO TYPE AMOUNT

Logout Time:- BARCODE

Thank You For your visit.
See you soon.

5 Other Non-Functional Requirements

5.1 Performance Requirements
5.1.1 Capacity

The ATM shall provide customers a 24-hour service.

5.1.2 Dynamic requirements

• The card verification time must not exceed 0.8 sec. under normal server workload and 1
sec. under peak server workload.
• The pin number verification time must not exceed 0.3 sec. under normal server workload
and 0.5 sec. under peak server workload.
• Account balance display time must not exceed 2 sec. under normal server workload and 3
sec. under peak server workload.
• Account balance transfer time must not exceed 3 sec. under normal server workload and
4 sec. under peak server workload.

13
 • Cash withdrawal transaction time must not exceed 4 sec. under normal server workload
and 5 sec. under peak server workload.
• Deposit transaction time after insertion of the deposit envelope must not exceed 5 sec.
under normal server workload and 6 sec. under peak server workload.
• Receipt printing time must not exceed 3 sec. under normal server and peak server work-
load.
• Touch screen and button response time must not exceed 5000ms.
• Credit card advance time must not exceed 6 sec. under normal traffic and server and peak
traffic and server workload.

5.1.3 Quality

The primary objective is to produce quality software. As the quality of a piece of software
is difficult to measure quantitatively, the following guidelines will be used when judging the
quality of the software:
1. Consistency – All code will be consistent with respect to the style. (This is implied when
adhering to the standard).
2. Test cases – All functionality will be thoroughly tested.

5.2 Software System Attributes

5.2.1 Reliability

• The data communication protocol shall be such that it ensures reliability and quality of
data and voice transmission in a mobile environment. For example, CDMA.
• The memory system shall be of a non-volatile type.

5.2.2 Availability

• The product will have a backup power supply in case of power failures.
• Any abnormal operations shall result in the shutting down of the system.
• After an abnormal shutdown of the ATM, the system shall have to be manually restarted
by maintenance personnel.
• There should be no inconsistency introduced in the account during whose transaction the
system is abnormally shut down.

5.2.3 Security

• The system shall be compatible with AIMS security standards.

• The system shall have two levels of security, i.e., ATM card and pin verification both
authenticated by the CMS software.
• The Encryption standard used during pin transmission shall be triple DES.
• The password shall be 6-14 characters long.
• Passwords shall not contain the name of customers as they are easy to be hacked.
• Passwords can contain digits, hyphen, and underscore.

14
 • The user should be provided with only three attempts for login failing which his card needs
to be blocked.
• There shall be a security camera installed near the ATM.
• There shall be a secured cash vault with a combination locking system.
• The product cabinet cover shall be manufactured using fiberglass for security purposes.

5.2.4 Maintainability

• The system components, i.e., modem, memory, disk, drives shall be easily serviceable
without requiring access to the vault.
• The system should have the mechanism of self-monitoring periodically to detect any fault.
• The system should inform the main branch automatically as soon as it detects any error.
The kind of fault and the problem being encountered should also be mentioned by the
system automatically.

5.3 Business Rules

The business rules for the software are as follows:
• The Administrator has the authority to fix the rules and regulations and to set or update
the policies as and when required.
• The staff at the bank performs the following:
1. Making the entries in the system regarding all the details of the bank account of the
user.
2. Keeping the bank account of the user updated as soon as changes are encountered so
that the data is in a consistent state.
3. Blocking or seizing the account of the user on discovery of any illegal transaction.
4. Unblocking of ATM card that got blocked due to more than three unsuccessful login
attempts.
5. Blocking of a lost/stolen ATM card on the complaint of the user, only if he presents
his verification and an FIR filed for that case.
6. Constantly monitor all the ATMs in the city to check whether any one of them is
encountering any fault.
7. Immediately correct any fault discovered in any of the ATM.
8. Maintain the backup of all the accounts for reliability purposes.
9. Rollback all the changes made in an account during whose transaction an ATM got
an abnormal shutdown.
• In case of loss of the ATM card, the user has to lodge a First Investigation Report(FIR)
and present its one copy to bank officials for card blocking purposes.
• A log of the following annexure is generated by the system:
1. User bank account details.
2. Updations made in the user account along with date, time and the changes made.
3. Schedule of fixed assets.

15
6 Other Requirements
None

7 Appendix A: Glossary
AIMS ATM Information Management System.
ATM An unattended electronic machine in a public place, connected to
a data system and related equipment and activated by a bank cus-
tomer to obtain cash withdrawals and other banking services.
Braille A system of writing and printing for blind or visually impaired
people, in which varied arrangements of raised dots representing
letters and numerals are identified by touch.
CDMA Code Division Multiple Access, a reliable data communication pro-
tocol.
CMS Card Management Software developed by KPM Bank.
Dial-Up A message format for low-cost communications.
POSInternet An interconnected system of networks that connects computers
around the world via the TCP/IP protocol.

16
USE CASE DIAGRAM

Figure 1: Use Case Diagram for ATM System

17
CLASS DIAGRAM

Figure 2: Class Diagram for ATM System

18
DEPLOYMENT DIAGRAM

Figure 3: Deployment Diagram for ATM System

19
COMPONENT DIAGRAM

Figure 4: Component Diagram for ATM System

20
SEQUENCE DIAGRAM

Figure 5: Sequence Diagram for ATM System

21
STATE CHART DIAGRAM

Figure 6: State Chart Diagram for ATM System

22
ACTIVITY DIAGRAM

Figure 7: Activity Diagram for ATM System

23