ATM System Design: Requirements, Refinement, Traceability, Architecture

This document outlines the requirements, refinement, traceability, and architecture of an Automated Teller Machine (ATM) software system. It covers stakeholders, functional and non-functional requirements, use cases, class diagrams, and the Model-View-Controller (MVC) pattern.

ATM System Design
[Name]
[Institution]

Contents
Task 1: Requirement specification..................................................................................................2
1. Introduction..............................................................................................................................2
1.1 Purpose..............................................................................................................................2
1.2 Product Description...........................................................................................................2
2. Product Decomposition............................................................................................................3
2.1 Stakeholders......................................................................................................................3
2.2 Stakeholder's Functional Requirements............................................................................3
2.3 Non-functional Requirements...........................................................................................3
2.4 System Use Cases.............................................................................................................3
2.3.1 Use Case Specifications......................................................................................................4
Task 2: Refinement and Traceability...............................................................................................6
Check Account Balance...............................................................................................................6
Withdraw Funds...........................................................................................................................7
Deposit Funds..............................................................................................................................8
Class Diagrams............................................................................................................................9
Traceability Matrix......................................................................................................................9
Task 3: Architecture Design..........................................................................................................10
Key Advantages of using MVC.................................................................................................12
Task 4: Cloud-based ATM............................................................................................................14
References......................................................................................................................................16

Task 1: Requirement specification
1. Introduction
1.1 Purpose
The purpose of this document is to present a detailed description of An Automated Teller
Machine (ATM) Software System. This requirement specification document outlines the features
of the software, users, use cases, interfaces and operating constraints. The document is intended
for use as a blueprint for the implementation of the system by developers, and a reference point
for the software architecture by maintenance personnel.
1.2 Product Description
The software to be developed in this project will run an Automated Teller Machine (ATM). An
ATM is a highly complex system that is both real-time and safety-critical. It plays a critical role
in helping financial institutions handle more transactions by increasing accessibility of services
to account holders, while reducing the need for additional staff. The basic building blocks of an
ATM are the hardware, software , a backend database and network connecting the ATM to a
financial institution's core banking system. This project focus on the software that runs and
simulates the operations of an ATM.
The system outlined in this specification document avails users with features to allow them to
check balance, withdraw cash and deposit cash. It also allows an operator to load cash into the
system and manage all the features of the system.
2. Product Decomposition
2.1 Stakeholders
The ATM software has two main stakeholders;
 Customer: a bank customer who will be interacting with the ATM to either deposit,
check balance or withdraw cash.
 Operator: will interact with the ATM when loading or offloading cash from the
machine. The operator will have an option to switch off the system; effectively shutting
down the services to the customers.

2.2 Stakeholder's Functional Requirements
 -Menu with all the options for interacting with the ATM
 -Verify a user with account number and pin
 -Option to View balance
 -Withdraw cash
 -Select withdrawal amount
 -Check if an account has sufficient funds
 -Check if the ATM has enough funds to dispense
 -Deposit funds
 -Exit from the system
2.3 Non-functional Requirements
 Menu items to be displaced in a clear manner for ease of use
 Provide a user with an option to exit from any given process
 Handle errors gracefully
 The system should be able to recover from an error condition without affecting financial
records
 Secure data communication
2.4 System Use Cases
Use Case ID Use Case Description
UC01 Authenticate a User A user is presented with a welcome screen when one types in a
five digit account number and PIN. the system verifies if the
account number is valid and if the PIN is correct. If the account
and PIN are okay, the system displays the main menu with
options, else it displays an error message and returns to the
welcome screen.
UC02 Check Account
Balance
If a user selects option 1 on the main menu, the system queries
the bank's database for the account balance and displays the
balance to the user.
UC03 Withdraw Funds If a user chooses option 2; Withdraw Funds, the system displays
a menu options with standard withdrawal amounts;: £20 (option
1), £40 (option 2), £60 (option 3), £100 (option 4) and £200, as
well as an option to allow the user to cancel the transaction
(option 6).
-Upon the user selecting the amount to withdraw, the system
queries the bank's database for the account balance
- If the account balance can service the withdrawal request the
system queries the cash dispenser to check if there are enough
funds to satisfy the request; otherwise the an error message is
displayed
-If there is enough funds in the dispenser, funds are dispensed

and the bank's database updated with the transaction details.
UC04 Deposit Funds The system prompts for deposit amount from the user or 0 zero
to cancel.
If deposit amount is entered, the system requests the user to
insert the deposit envelope into the deposit slot.
When the deposit envelope is inserted, the system credits the
user account with the amount, although the amount is not
immediately available for download until bank employees verify
the transaction. The system then returns to the main menu.
2.3.1 Use Case Specifications
Use Case Name: Withdraw Funds
Primary Actor : Bank Customer
Summary Description: The use case makes it possible for a bank customer to withdraw cash
from their bank account.
Priority: Must Have
Risk Level: High
Pre-Condition: The ATM machine is functional and the user is already authenticated.
Post-Condition: The customer has received their cash. The bank has debited the customer’s
bank account and recorded details of the transaction.
Basic Path:
1. A customer selects the cash withdrawal option from the main menu
2. The ATM displays a menu with withdrawal amount options
3. The user selects a withdrawal amount by inputting the selected option
4. The ATM checks if the withdrawal amount is greater than the user's account balance; if
the amount is greater than the account balance, alternative path 4a is taken. If the account
balance can cover the withdrawal amount, step 5 below is taken. If the user opts to cancel
the transaction, step 4b is taken.
5. The ATM checks if the cash dispenser has sufficient funds to service the transaction. If
the amount is insufficient, step 5a is taken, else step 6 is taken.
6. The ATM debits the withdrawal amount from the user's account in the bank's database.
7. A notification is displayed on the screen to remind the customer to collect the money.
8. The ATM completes the transaction, logs out the user and displays a welcome screen.
Alternative Paths;

4a. If the account balance is less than withdrawal amount, the ATM displays a message
requesting the user to choose a smaller amount; the ATM returns to step 1.
4b. If a user chooses to cancel the transaction, the ATM displays the main menu.
5a. If the dispenser has less funds than withdrawal amount, the ATM displays a message
requesting the user to choose a smaller amount; the ATM returns to step 1.
Use Case Name: Deposit Funds
Primary Actor : Bank Customer
Summary Description: The use case allows a bank user to deposit funds into their account
using an automated teller machine.
Priority: Must Have
Risk Level: High
Pre-Condition: The ATM machine is functional and the user is already authenticated.
Post-Condition: The customer's account has been credited with the amount, although not
available for withdrawal., and transactions detailed saved.
Basic Path:
1. The system requests the user to key in the deposit amount or 0 to exit.
2. The user enters the deposit amount.
3. If the user enters a valid deposit amount, Step 4 is taken, else if the user entered 0
Step 3a is taken.
4. The system requests the user to insert the deposit envelop into the deposit slot.
5. If deposit envelop is received within two minutes by the deposit slot, the system
credits the amount to the customer's account and updates the banks database. If
deposit envelope is not received within 2 minutes, alternative step 5a is taken.
6. The system displays the main menu and waits for user inputs.
Alternative Paths;
3a. The system cancels the transaction and displays the main menu and waits for user inputs
5a. The system terminates the transaction, displays the main menu and waits for user inputs.
Task 2: Refinement and Traceability

Problem: Authenticate a User
 Initial Solution:
1. Display Welcome Message
2. Get user input for account number
3. Prompt user to enter PIN
4. Query bank database; confirm is account number and PIN are correct
5. Display Main Menu
 Refinement:
1. Display Welcome Message
2. Get User Inputs for account number
2.1 Prompt User to enter PIN
2.2 Get user inputs for PIN
3. Verify user credentials;
3.1 Get PIN for the given account from the bank's database
3.2 Compare entered PIN against the queried PIN
if( entered PIN is same as Queried PIN) {
Display Main Menu }
else{ display an error and display welcome screen }
Check Account Balance
 Initial Solution:
-Query bank's database for the given account
-Print out account balance to the screen
Withdraw Funds
 Initial Solution:
1. Displays a menu with standard withdrawal amounts
2. Get User option
3. Verify that the customer's account balance can service the withdrawal amount
4. Verify amount available in the cash dispenser
5. Debit customer's account
6. Dispense the withdrawn amount
7. Display reminder message
Refinement
1. Displays a menu with standard withdrawal amounts
2. Get User option

3. Verify that the customer's account balance can service the withdrawal amount
if( GetAccountBalance(Accnt No) < Withdrawal Amount)
{
Display error message, Go to step 1
}
else if(GetAccountBalance(Accnt No) >= Withdrawal Amount)
{
if( GetDispenserBalance >= Withdrawal Amount)
{
-DebitCustomerAccount(Accnt No)
-Dispense withdrawn amount
-Display reminder on the screen
}
}else{
Display error message, Go to step 1
}
GetAccountBalance(Accnt No) {
balance=select balance from bank's database where account no. = Accnt No;
return balance; }
DebitCustomerAccount (Accnt No, amount) {
update bank's database set balance = (balance - amount) where account no. =
Accnt No;
}
Deposit Funds
Check Account Balance
 Initial Solution:

1-Get user input for deposit amount
1.1-if deposit amount is 0, cancel the transaction and display the main menu
2. Display Message; request user to insert deposit envelope within two minutes
3. If envelope is received within two minutes
3.1 Credit the amount to the customer's account
4 Else if no envelope in the deposit slot within two minutes
4.1 Cancel the transaction and display a error message
4.2 Display main menu and wait for user inputs.
Refinement
1-Get user input for deposit amount
if( userInput == 0) {
-Cancel the transaction
-Display the main menu and wait for user inputs
}else{
-Request user to insert deposit envelope within two minutes
if(timePassed >2min && noEnvelop){
-Cancel transaction
-Display Error message
-Display main menu and wait for user input
} else{
-CreditUserAccount(AccntNo, Amount);
}
}
CreditUserAccount(AccntNo, Amount){
update bank's database set balance = balance + Amount where account = AccntNo;
}
Class Diagrams

Traceability Matrix
Use Cases Class Diagram
ID Use Case ID Class
UC01 Authenticate a User C01 Login
UC02 Check Account Balance C02 CheckAccountBalance
UC03 Withdraw Funds C03 Withdraw
UC04 Deposit Funds C04 Deposit
From the use cases identified, and the subsequent decomposition of the requirements through
step-wise refinement, four classes were derived, required to model the ATM system. The classes
are; Login, Check balance, withdraw and deposit. The four classes corresponds to the four main
use cases. The four classes encapsulate all the key functions and operations required to have a
fully operational ATM system. Three of the classes, namely, Deposit, Withdraw and Check
Balance are all dependent on the Login class. This is because a user can only perform the
operations after successfully being verified.

Task 3: Architecture Design
With the growth and development in the software development field, a number of architectural
patterns have been proposed, for use in designing and implementing software systems. For
desktop and web applications, the most commonly used patterns include; Model–view–
controller (MVC), Model-View-Presenter (MVP) and Model-View-ViewModel (MVVM).
The Model–view–controller pattern finds wide usage in the development of software
applications with user interfaces (Deacon,2009). The model subdivides such an application into
three distinct parts; Model, View and Controller. The subdivision is informed by the need to
separate the internal representation of information from the way it is entered by a user or how it
is presented to the user (Boodhoo, 2006). The separation of the components promotes
modularity, allowing for efficient code reuse and parallel development (Mak, 2008). The pattern
also allows applications to be more flexible and easy to interact with.
The three components of the MVC pattern are;
 Model: the model plays the central role of the pattern, acting as an application's dynamic
data structure which is decoupled from the user interface. The model handles all the
logic, business rules and data, independent of how data is presented on the user interface
(Lindberg and Rydin, 2002).
 View: the view outputs information to the user in multiple possible formats, such as text,
graphs , charts etc.
 Controller: a controller receives user's inputs and converts them to appropriate
commands that manipulates the model. The controller enables a user to manipulate the
system through the model (Lucassen and Maes, 2006).

What makes it possible for parallel development is the fact that the model and the view were
designed to be totally independent, thus they need not know what happens on the other side. For
that reason, developers can simultaneously work on the various components of a software
application without affecting one another.
Key Advantages of using MVC
 Simultaneous development – Teams of developers can work on the different components ;
views, controller and model simultaneously.
 Cohesion: with MVC related actions can be logically grouped , views for a given model can
also be grouped.
 Low Coupling: the components are loosely coupled, making it possible to make changes on
one component without affecting the other components.
 Ease of modification – one component can be modified without affecting another.
For the case of the Model-View-Presenter (MVP), the controller is substituted with a presenter.
The model in MVP is similar to the MVC model and is responsible for defining business rules

and data manipulation (Potel, 1996). Similarly, the View represents all components of the user
interface. The presenter addresses the events from the user interfaces. The presenter collects user
inputs through the View and passes the inputs to the model (Pau, Mihailescu and Stanescu,
2010).
The MVVM Design Pattern provides support for data binding between ViewModel and the
View, allowing for an automated propagation of any changes from the ViewModel to the View
(Garofalo, 2011). The model employs an observer pattern to communicate changes to the Model
from the ViewModel. The Model in this pattern handles the data manipulation, while the View
holds all the user interface components (Sorensen and Mikailesc, 2010).
From the analysis of the functional and non-functional requirements of the ATM system, the
MVC pattern is the most ideal for application in this case. MVC is fairly straight forward to
design and implement in comparison to the other models such as MVVM. With MVC, the model
and view are simply connected by use of a controller which facilitates data model manipulation
by the view. Since the ATM system will have a number of views, a pattern like the MVVM

would not be applicable. This is because, unlike the controller in MVC which facilitates loose
coupling of the View and the Model, the ViewModel in MVVM binds data between the View
and the Model, which makes it ideal for use with a single page application; but in this case, the
ATM system has several interfaces, thus making the use of the pattern a bit complicated.
MVC-based architecture design
In this systems MVC design, the ATM system will have a number of views for the same model
and controller. Depending on the user selection, a the model will display a given view. The
approach was taken owing to the fact that an ATM has static interfaces that do not change except
for the data displayed.

Task 4: Cloud-based ATM
With the advent of cloud computing, and the numerous benefits that comes with this model of
delivering computing resources, the banking industry is slowly shifting some service delivery to
the cloud. Currently, a great number of ATMs are thick-client PCs, with most of them running
outdated operating systems such as Windows XP. A shift to the cloud presents unique
opportunities for the banking industry, particularly the fact that the machines can be run
remotely, ease of performing software updates, besides the obvious cloud computing advantages
such as flexibility, scalability, lowering the total cost of ownership and foster a peacefully co-
existence between ATMs and mobile.
Cloud ATM makes it possible for an institution to quickly scale, provide quick upgrades to the
software running the ATM and centralized management. These requirements therefore requires
that the ATM software entirely run on the server side; with a thin client on the physical ATM
machine.
The MVC architecture is still a viable option for use in developing software for a cloud ATM.
The special characteristics of MVC such as loose coupling means that the ATM View or
Controller or Model can be updated without affecting the operations of the other components. As
such, a cloud ATM can comfortably use the MVC pattern.
Deploying a cloud ATM can take many forms, such as Infrastructure as a Service (IaaS),
Platform as a Service (PaaS), Software as a Service (SaaS). Each of the three provision model
has both advantages and disadvantages. However, deploying using the Software as a Service
(SaaS) model would be the most ideal for a cloud ATM. With SaaS, a bank would easily scale its

operations and only pay for the services consumed such as the number of ATMs deployed,
unlike PaaS and IaaS where the bank would have to pay for the platform and still incur
additional charges in developing and maintaining the ATM software. With Software as a
Service, a financial institution would focus on its core business; and leave the task of developing,
maintaining and ensuring software security to specialist firms.
The ownership model in this case would be a private cloud deployment. This is informed by the
fact that financial records and data are very sensitive and their deployment on a public cloud
would make the given platform a major target for hacking attempts; exposing highly confidential
and sensitive data to exploitation. A private ownership model or a hybrid model would be ideal
for handling financial transactions, since it guarantees that the multi-tenancy nature of public
clouds would not be exploited to gain access to the financial records.

References
Boodhoo, J.P., 2006. Design Patterns-Model view presenter. MSDN Magazine-Louisville, pp.91-
100.
Deacon, J., 2009. Model-view-controller (mvc) architecture. Online][Citado em: 10 de março de
2006.] http://www. jdl. co. uk/briefings/MVC. pdf.
Garofalo, R., 2011. Building enterprise applications with Windows Presentation Foundation and
the model view ViewModel Pattern. Microsoft Press.
Lucassen, J.M. and Maes, S.H., International Business Machines Corp, 2006. MVC (model-view-
controller) based multi-modal authoring tool and development environment. U.S. Patent
6,996,800.
Lindberg, H. and Rydin, P., EON COMPANY, 2002. Model view controller. U.S. Patent
Application 09/768,389.
Mak, G., 2008. Spring MVC framework. In Spring Recipes (pp. 321-393). Apress.
Potel, M., 1996. MVP: Model-View-Presenter the Taligent programming model for C++ and
Java. Taligent Inc, p.20.
Pau, V.C., Mihailescu, M.I. and Stanescu, O., 2010. Model view presenter design
pattern. Journal of Computer Science & Control Systems, 3(1).
Sorensen, E. and Mikailesc, M., 2010. Model-View-ViewModel (MVVM) Design Pattern using
Windows Presentation Foundation (WPF) Technology. MegaByte Journal, 9(4), pp.1-19.