PRODUCT DESIGN SPECIFICATION:

AUTOMATIC TELLER MACHINE (ATM)

April 10, 2018

Version <1.0>

Authors:
Ajla Sokol, 140302103
Emina Topalovi¢, 140302120
Faruk Bozkurt, 130304004

1
1 Introduction
An Automated Teller Machine (ATM) is a real-time system that is highly com-
plicated in design and implementation. As a real-time control system, the main
characteristic of ATM system, that shows the complexity of it, is the interac-
tion with hardware devices and users. ATM is an electronic telecommunication
device that enables customers of some nancial institutions (such as banks) to
perform tasks regarding the nances, such as cash withdrawals, deposits, trans-
fer funds, and even obtaining account information at any time and without the
need for direct interaction with bank sta. For implementation of such soft-
ware, one of the most ecient ways is to programme it using object oriented
programming language, such as C++, in order to make use out of the object
oriented way of implementing software, in other words, to make a software by
implementing classes.

1.1 Purpose

This paper presents the formal design, specication, and modeling of the ATM
system. This document is intended for the following group of people:
• professor
• students

1.2 Scope

This document applies to Automated Teller Machine software. The software for
ATM allows user to perform various transactions in his account without need of
interaction with employees of bank. Some of the benets that it oers are cash
withdrawals, balance transfers, deposits, and other banking related operations.
The software takes the bank account number and PIN number as inputs. The
outputs of the system are shown on the interactive display that lets the user
select the desirable function that he wants to perform. The software is expected
to be completed in duration of two months.

2 The Overall Description

2.1 Product prospective

• The ATM provides 24 hours service

• The ATM provides privacy in banking communications
• The ATMs reduce the work load banks sta
• The ATM may give customer new currency notes
• The ATMs are convenient to banks customers
• The ATM is very benecial for travelers

2
2.2 Product functions

• Withdrawal/Deposit: The operation that software should perform will be

entered by user (for example, if the user wants to withdraw or deposit
money). The amount to be withdrawn or deposited is then mentioned by
the user.
• This software allows the user to access their bank accounts remotely
through an ATM, without any additional help of the bank sta.
• The user is also provided with the facility to mention the required denom-
inations. Once he enters his requirements the machine goes through the
system based on current resources to check whether it is possible or not. If
yes, the amount is given to the user otherwise other possible alternatives
are displayed.

2.3 Constraints

The major constraints that the project has are as follows:

• The number of invalid pin entries attempted must not exceed three. After
three unsuccessful login, account is locked.
• The ATM must service at most one person at a time.
• The minimum amount of money a user can withdraw is 10 KM and the
maximum amount of money a user can withdraw in a session is 1000 KM.
• The minimum amount of money a user can deposit is 10 KM and the
maximum amount of money a user can deposit in a session is 1000 KM.
• The software requires some amount of memory.

3 User Interface Requirements

The interface provided to the user should be user-friendly. The following screens
will be provided:
1. A login screen is provided in the beginning for entering the required pin
number
2. An unsuccessful login leads to a reattempt screen for again entering the
same information (it can be reattempted at most two additional times)
3. The successful login leads to a screen displaying a list of transactions from
which a user can select one
4. A screen will be provided for user to check his account balance

3
4 System overview
The ATM will service one customer at a time. A customer will be required to
enter a personal identication number (PIN), which will be sent to the bank
for validation as part of each transaction. The customer will then be able to
perform one or more transactions. The software must be able to provide the
following services to the customer:
• A customer must be able to make a cash withdrawl from any suitable
account linked to the card. Approval must be obtained from the bank
before cash is dispensed.
• A customer must be able to make a deposit to any account linked to the
card, consisting of cash and/or checks in an envelope. The customer will
enter the amount of the deposit into the ATM. Approval must be obtained
from the bank before physically accepting the deposit.
• A customer must be able to make a transfer of money between any two
accounts linked to the card.
• A customer must be able to make a balance inquiry of any account linked
to the card.
• ATM must interact with the bank's account information database for each
session, in order to authenticate user and perform transactions.
• The ATM will communicate each transaction to the bank and obtain ver-
ication that it was allowed by the bank. In the case of a cash withdrawl
or deposit, a second message will be sent after the transaction has been
physically completed.
• If the bank determines that the customer's PIN is invalid, the customer
will be required to re-enter the PIN before a transaction can proceed. If
the customer is unable to successfully enter the PIN after three tries, the
card will be permanently retained by the machine, and the customer will
have to contact the bank to get it back.
• If a transaction fails for any reason other than an invalid PIN, the ATM
will display an explanation of the problem, and will then ask the customer
whether he/she wants to do another transaction.
• The ATM will provide the customer with a printed receipt for each success-
ful transaction, showing the date, time, machine location, type of trans-
action, account, amount, and ending and available balance of the aected
account

4
5 Design Map

Figure 1: Activity diagram of ATM

6 Software description
The ATM software will consist of three main classes with several child classes.
To have a better explanation of the work principle of classes, CRC model will
be used.
A Class Responsibility Collaborator (CRC) model is a collection of standard
index cards that have been divided into three sections: class name, responsi-
bilities and collaborators. A class represents a collection of similar objects, a
responsibility is something that a class knows or does, and a collaborator is
another class that a class interacts with to fulll its responsibilities.
The software will consists of three main classes: ATM, BANK, TRANSAC-
TION. Inside of all of these classes, the child classes will be implemented (such
as display, receipt and so on). For example, the TRANSACTION class will
consists of the Withdrawl class, Deposit class, Transfer class.
The ATM needs to interact with the information from the database of bank.
In order for accuracy of information, database needs to be updated constantly
with any additional transaction made. Database needs to be changed automat-
ically (with every transaction), or it can be changed by the administrator (bank
workers).

5
 6

Figure 2: CRC model for transaction , bank and ATM class

6.1 System Attributes

• security

• reliability
• availability

To ensure the system attributes are up to standards, the security of ATM needs
to be updated. To secure the ATM system, the additional attributes can be
added to hardware:
• sensors that can send alerts (and/or take the ATM oine) when anything
is attached to the card reader or keypad
• additional security cameras
To ensure the security of protocol system, Transport Layer Security (TLS) or
RSA protocol can be implemented. Both protocols are based on handshake
principle. TLS is 'stateful' protocol, meaning that all handshake messages need
to be stored in memory by both communicating parties. RSA protocol is 'state-
less', meaning that it does not need to store previously exchanged messages
between communicating parties, but rather store key material. Memory re-
quirement is, therefore, smaller compared to that in TLS protocol. We would
like to implement RSA protocol to secure the system additionally.
RSA protocol has three stages:
• Handshake stage (negotiating protocol version and algorithm suite; client
sends Hello message, while server sends Welcome message)
• Certicate Exchange Stage (excange of selected protocol version and se-
lected algorithm suite)
• Mutual authentication and key establishment stage

7
6.2 User Interface Mockup

Figure 3: Insert card slide

Figure 4: Enter PIN slide

8
 Figure 5: Content slide

7 Architecture of ATM
The main input devices of ATM are:
• Card reader
• Keypad
The main output devices of ATM are:
• Display screen
• Receipt printer
• Cash depositor

These devices are interfaced to the processor that makes the heart of the ATM
machine. All the ATM machines working around the world are based on cen-
tralized database system. The ATM has to connect and communicate with the
host processor (server). The host processor is communicating with the internet
service provider (ISP). It is the gateway through all the ATM networks available
to the card holder.

9
 Figure 6: The conceptual model of ATM

The interface of the software will be implemented in cross-platform software

development tool called Qt. The code will be simulated on the Raspberry Pi as
the simulation for the ATM device. The add-on for the hardware part will be
keypad and the monitor that is implemented on the Raspberry Pi and will work
as a touch-screen display of ATM. For more advanced usage, the cash depositor
and receipt printer can also be implemented as the part of the hardware.

10