Atm Srs PDF

THE UNIVERSITY OF MALAWI
THE POLYTECHNIC
FACULTY OF ENGINEERING
DEPARTMENT OF ELECTRICAL ENGINEERING
MODULE:
SOFWARE ENGINEERING
SUBMITTED BY:
GIDEON MATICK (ELE/10/NE/017)
ECKHARIE BEULAH (ELE/10/NE/001)
ROBERT WARD (ELE/10/NE/30)
CHAWEZI CHIRWA(ELE/10/NE/032)
SUBMITTED TO:
MR L KAMWENDO
DUE DATE: 4/03/2015

Software Requirements Specification
for an
ATM OPERATIONAL SOFTWARE
Version 1.0 approved
Prepared by BECE 4
POLYTECHNIC COMPUTER ENGINEERS
4TH MARCH 2015

Page iii
Table of Contents
Table of Contents ......................................................................................................................... iii
1. Preface .......................................................................................................................................1
2. Introduction ..............................................................................................................................2
2.1 Purpose.............................................................................................................................2
2.2 Document Conventions ....................................................................................................2
2.3 Intended Audience and Reading Suggestions ..................................................................2
2.4 Product Scope ..................................................................................................................2
2.5 References ........................................................................................................................3
3. Overall Description ..................................................................................................................4
3.1 Product Perspective ..........................................................................................................4
3.2 Product Functions ............................................................................................................4
3.3 User Classes and Characteristics......................................................................................4
3.4 Scenarios ..........................................................................................................................4
3.5 Use Case Model Survey ...................................................................................................6
3.6 Operating Environment ....................................................................................................9
3.7 User Documentation ......................................................................................................10
3.8 Assumptions and Dependencies ....................................................................................10
4. External Interface Requirements .........................................................................................11
4.1 User Interfaces ...............................................................................................................11
4.2 Hardware Interfaces .......................................................................................................12
4.3 Software Interfaces.........................................................................................................12
4.4 Communications Interfaces............................................................................................13
5. Functional requirements .......................................................................................................14
5.1 Authentification .............................................................................................................14
5.2 Banking transactions ......................................................................................................14
6. Other Nonfunctional Requirements .....................................................................................17
6.1 Performance Requirements ............................................................................................17
6.2 Safety Requirements ......................................................................................................17
6.3 Security Requirements ...................................................................................................17
6.4 Software Quality Attributes ...........................................................................................17
6.5 Business Rules ...............................................................................................................17
7. System Evolution ....................................................................................................................18
8. Supporting information .........................................................................................................19
Appendix A: Glossary .................................................................................................................20
Software Requirements Specification for an ATM OPERATIONAL SOFTWARE
Page 1
1. Preface
This Software Requirements Specification (SRS) is intended for users and managers of the ATM
OPERATIONAL SOFTWARE and those evaluating its potential use. It is also
useful to any maintainers of the interface's codebase. Version One of the SRS covers the
interface at the time of Release.
Page 2
2. Introduction
2.1 Purpose
This document describes the software requirements and specification (SRS) of an automated teller
machine (ATM). This document is intended for the customer and developer (designer, testers and
maintainers).
The reader is assumed to have a basic knowledge of banking accounts and accounts services.
Knowledge and understanding of unified modeling languages (UML) diagrams is also required.
2.2 Document Conventions
 PIN (Personal identification number):

Is a numeric password shared between a user and a system that can be used to authenticate
the user to the system.
 Account:
A single account at a bank against which a transaction can be applied. A customer can only
hold one account.
 ATM (Automated Teller machine):
An electronic telecommunications device that enables the customers of a financial
institution to perform financial transactions without the need for a human cashier, clerk
or bank teller.
2.3 Intended Audience and Reading Suggestions
The intended audience for this SRS consists of:

 Software engineers
 System engineers
 System customers
 System test engineers
 System customers
 System maintenance engineers
 Managers
2.4 Product Scope
The software supports a computerized banking system. The system enables customers to complete
simple bank account service via an ATM. An ATM session consists of authenticating a user (i.e.,
proving the user's identity) based on an account number and personal identification number (PIN),
followed by creating and executing financial transactions. To authenticate a user and perform
transactions, the ATM must interact with the bank's account information database. For each bank
account, the database stores an account number, a PIN and a balance indicating the amount of
money in the account. ATM users should be able to view their account balance, withdraw cash (i.e.,
take money out of an account) and deposit funds (i.e., place money into an account).
Page 3
2.5 References
[1] Software engineering / Ian Sommerville. — 9th ed.

[2]Requirements Engineering: Processes and Techniques’ by G. Kotonya and I. Sommerville, John
Wiley & Sons, 1998
www.scribd.com/doc/11934168/srs-of-atm#scribd
Page 4
3. Overall Description
3.1 Product Perspective
COMPUTER BANKING DATABASE

/ATM SYSTEM
USER
This ATM’s software is to run on a new ATM hardware that a local bank wants to install for its
customers. This product will be developed from an existing system of the same local bank or from
another bank that has similar characteristics of this local bank. The system will be designed in such
a way that the user will access and use the ATM and then accesses the banking system, which
updates, configures and accesses the details and data of the user from his/her database. The system
will also accommodate an operator who will load money in the ATM machine, validate deposits
made by a customer, and make sure the system hardware is always on and on power.
3.2 Product Functions
The functions of the system are:

 Login
 Balance inquiry
 Cash withdraw
 Funds deposit
3.3 User Classes and Characteristics
 Open to all users but access level is dependent on knowledge of the system.
 Customers are simply members of the public with no special training.

 Bank security personnel need have no special education or experience.
 Maintainers must be experienced system administrators, able to upgrade and repair the
system.
3.4 Scenarios
3.4.1 Initial assumption

The assumption made are:
Page 5
 An individual with a valid bank account and valid unique PIN attempts to access the banking
system services using the ATM.
 The ATM machine has money loaded that will be able to be withdrawn by a customer
 The customer knows how to use the ATM machine.
 The ATM is always on.
3.4.2 Normal
For the user:

 The customer enters the account number and pin and is successfully validated by the
banking system
 The customer is logged in the system and is able to withdraw cash after entering the pin and
account number
 The customer is logged in the system and is able to Deposit cash after entering her pin and
account number
 The customer can request a query balance of his/her account
For the operator:
 The operator can successfully update the customer’s account and database after a deposit
transaction of a customer
 He/she is able to keep the ATM on power all the time
 He/she is able to load cash in the ATM machine, which customers will be able to withdraw
3.4.3 What can go wrong
 Unauthorized access for an account by a user who is not the owner of that particular account
 Failure to update the bank account database after a customer makes a transaction
 Operator making an accounting error and updating a customer’s account wrongly after a
customer deposits cash
 A customer trying to withdraw cash that is greater than that is in the customer’s account
3.4.4 Other activities
 Deposits by a customer are manually updated by the operator

 The operator and system administrator customizes, updates and manages the database of the
bank customers
3.4.5 System state on completion
 Customer is logged on to the ATM and bank system and can make various transactions
 Operator can load cash into the ATM machine for customers to withdraw
Page 6
 The operator can update the database of the customer after the customer deposits cash
 The database is updated after the customer withdraws cash from the ATM
 The ATM is always online for the customers to be accessing it
3.5 Use Case Model Survey
This subsection include actors and use cases that are present.
3.5.1 USE CASE DIAGRAMS
DATABASE
ENTER A/C
NO. AND PIN
BALANCE
USER ENQUIRY
BANKING
VALIDATE SYSTEM
WITHDRAW
MONEY
DEPOSIT
MONEY
EXIT
Page 7
Figure:3.1 use case diagram for user
DATABASE
BANKING
SYSTEM
SYSTEM
COUNT CASH
ADD CASH
OPERATOR
START UP
SHUT DOWN
Page 8
Figure:3.2 use case diagram for operator
DATABASE
ENTER A/C
NO. AND PIN
USER BALANCE
ENQUIRY
BANKING
VALIDATE SYSTEM
WITHDRAW
MONEY
COUNT
CASH
DEPOSIT
MONEY
ADD CASH
EXIT OPERATOR
START UP
SHUT
DOWN
Figure3.3 use case diagram for both user and operator

Page 9
3.5.2 USE CASES
a)login
This is a use case used to verify the authentication of the user. The user types their allotted
account number and pin as input. The system then verifies whether their account number and pin
stored on the data base matches or not ,if it matches then it allows the user to use the system or else
it asks the user to enter the pin number again.
b)balance inquiry
This use case is used to check the account balance.After every transaction the balance in the
user’s account is updated .
c)withdrawal
This use case facilitates the user to withdraw money from their account.After the money is
withdrawn it is updated in the user’s account.
d)deposit
This use case is used to execute the deposit transaction by the user. Even though the account
balance is updated after the deposit. The deposited amount is only available after it is updated
manually.
c)exit
This use case enables the user to exit the system and to enable a new user to access the system.
The following list offers a brief outline and description of the functionalities of the ATM software
system.
3.6 Operating Environment
The hardware, software and technology used should have the following:
 Ability to read values from a keyboard
 Ability to count the currency notes
 Continuous power supply
 Ability to connect to bank’s network
 Ability to validate user
Design and Implementation Constraints
 login
 validate account number
 validate if the account number is hosted bank, if not prompt an error message
 validate if the account number is functional, if not prompt an error message
 validate PIN
 validate that PIN is not blank, if blank ,prompt error message ”please enter
PIN”
 validate that PIN matches with the account number, if not prompt error
message” Incorrect PIN, please try again ”
Page 10
3.7 User Documentation
 User manual
3.8 Assumptions and Dependencies
 Hardware never fails

 Limited amount of money withdrawn per day
 Limited number of transactions per day
 ATM casing is impenetrable
Page 11
4. External Interface Requirements
4.1 User Interfaces
Upon first approaching the ATM, the user should experience the following sequence of events
(shown in Fig. 1):
1. The screen displays a welcome message and prompts the user to enter an account number.
2. The user enters a five-digit account number, using the keypad.
3. The screen prompts the user to enter the PIN (personal identification number) associated
with the specified account number.
The user enters a five-digit PIN, using the keypad.
Figure: 4.1
If the user enters a valid account number and the correct PIN for that account, the screen displays
main menu
the main menu (Fig. 2). I
Figure:4.2
If the user enters 2 to make a withdrawal the screen displays the menu in figure 4.3.
Page 12
Figure:4.3
4.2 Hardware Interfaces
 A screen that displays messages to the user

 A keypad that receives numeric input from the user
 A cash dispenser that dispenses cash to the user and
 A deposit slot that receives deposit envelopes from the user.
Figure:4.4
4.3 Software Interfaces
Software requirements at the end user are:

1. Operation systems
Page 13
 Windows XP
 Windows 7, 8 e.t.c.
2. Languages supported
 C++
3. Database
4.4 Communications Interfaces
There is no restriction of the ATM network to a specific network protocol as long as the
performance requirements are satisfied.
Page 14
5. Functional requirements
The following list offers a brief outline and description of the main features and functionalities of
the ATM software system.
5.1 Authentification
5.1.1 Description and Priority
The ATM provides access to the banking system services .In order for a customer to
perform a transaction with the bank the system needs to validate the user through
their user credentials- a unique account number and pin.
This feature is of high priority since it is the starting point of the user access the
system.
5.1.2 Stimulus/Response Sequences

The response/stimulus for different class of users are
 Welcome- welcome message
 Please enter your account number: user login credential
 Enter your pin: user login credentials
5.1.3 Functional Requirements
The banking system provides services to a large number of users. The system should
identify individual users of the banking system by the account number and account
pin.
Input: Account Number, Account PIN
Output: Main Menu
5.2 Banking transactions
5.2.1.1 Priority
The utility is executable from the main menu displayed numbered options. It enables various users
to request balance enquiry, perform withdrawals and carryout deposits.
5.2.1.2 Stimulus and response
The response/stimulus for the different classes of users are :
1) Balance enquiry option: the screen displays the user's account balance
2) Withdrawal Option: The screen displays a menu containing standard withdrawal amounts: $20
(option 1), $40 (option 2), $60 (option 3), $100 (option 4) and $200 (option 5). The menu also
contains an option to allow the user to cancel the transaction (option 6).
Page 15
3) Deposit feature: The user enters a deposit amount or 0
Functional requirements
The system should be able to perform banking transactions from the main menu that the user selects
at the ATM.
Input : Main Menu Option

Output: Executed Banking transaction
5.3 Verify withdrawals and deposits
5.3.1 Description and priority
This feature enables users not to overdraw their accounts and update their accounts when deposits
have been carried out.
If the user makes a balance inquiry, the screen displays the user's account balance.
5.3.2 Stimulus and response
If withdrawn amount chosen is greater than users account balance: the screen should display this to
the user
If the withdrawn amount is acceptable: The ATM proceeds to the next withdrawal step
If the user deposits an envelope.The amount is add to the users bank balance but not available for
withdrawal until physical verified
Functional requirement
The system should be able to verify the withdrawals and deposits.

Input : withdrawal or deposit
Output : ATM proceeds to the next step of transaction or displays message of failure to proceed to
the next step.
5.4 User exit interface
5.4.1 Description and priority
The feature enables the user to exit the system and to display the welcome message for the next
user.
5.4.2 Stimulus and response

Page 16
Exit the system (option 4): thank you message, then display the welcome message for the next user
5.4.3 Functional requirement
The system should log out the user to control access the users bank account
Input :exit the system (option 4).
Output :thank you message, then display the welcome message for the next user.
Page 17
6. Other Nonfunctional Requirements
6.1 Performance Requirements
 It must be able to perform in adverse conditions

 Must have high data transfer rate
6.2 Safety Requirements
 Must be safe in physical aspect, say in a booth

 Must be sealed to the floor to prevent any kind of theft
 There must be a guard just outside the booth for man power security
6.3 Security Requirements
 Users are advised to change their PIN on first use

 Users are advised not to tell their PIN to anyone
 The maximum number of attempts to enter PIN are limited to three
6.4 Software Quality Attributes
 Easy to learn usage for an ordinary person .i.e. within 10 minutes

 Easy to understand operation from an engineering perspective .i.e. one week
 The system will be down for 30 minutes in each 24 hour cycle
 System can be easily integrate with bank system
 Software can be installed on a number of ATMs without affecting current operation status
 Easy to troubleshoot and maintain in case system fails abruptly
6.5 Business Rules
N/A
Page 18
7. System Evolution
The expected evolutions and software changes to the ATM’s software are:
 The deposit transaction by a user should be automatically done. That is the ATM’s software
should count the cash deposited by a customer automatically with the help of special
hardware, without the need for the ATM operator manually counting the cash
 The cash loaded in the ATM machine for withdrawal purposes should be counted
automatically
 Update the customer’s database automatically once he/she makes a valid deposit transaction
 Update the customer’s database when he/she makes a valid deposit transaction
 The software must run and operate on the ATM’s hardware effectively and efficiently
 The software must properly interface with the existing banking system and the existing
banking database system
 The ATM should produce transaction script after exit from the system
 The ATM should be integrated with different network service provider systems to
accommodate utility bill payments
 The graphic user interface should be more user friendly and accommodate changes that will
come as more functionality and services will be added and made to the software as user and
system requirements change
 More security and limiting features like:
o Accommodating only 3 wrong password or account number attempts made by user
on the ATM
o Limit daily cash withdrawals of a customer
o Deposited cash from customer is the same and exact amount he/she stated when
making the deposit transaction
o Updating and validating a customer’s deposit transaction if and only the posited ash
from customer is the same exact figure as the amount he/she stated upon initiating
the deposit transaction
Page 19
8. Supporting information
 Use case diagrams
 Activity diagram
Page 20
Appendix A: Glossary
 Account
A single account in a bank against which transactions can be applied. Accounts maybe of
various types with at least checking and savings. A customer can hold more than one account.
 ATM
An electronic telecommunications device that enables the customers of a financial institution to
perform financial transactions without the need for a human cashier, clerk or bank teller.
 Bank
A financial institution that holds accounts for customers and that issues account numbers and
passwords authorizing access to accounts over the ATM network
 Bank computer
The computer owned by a bank that interfaces with the ATM network and the banks own
cashier stations. A bank may actually have its own internal network of computers to process
accounts but we are only concerned with the one that interacts with the network.
 Customer
The holder of one or more accounts in a bank. A customer can consist of one or more
Persons or corporations the correspondence is not relevant to this problem. The same person
holding an account at a different bank is considered a different customer.
 Transaction
A single integral request for operations on the accounts of a single customer. We only
specified that ATMs must dispense cash, accept cash deposits and view balance. The ATM
does not give a print of these but rather displays them on the screen.
 Database
A database is an organized collection of data stored on a computer.

Atm Srs PDF

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Atm Srs PDF

Uploaded by

Copyright:

Available Formats

THE UNIVERSITY OF MALAWI

DEPARTMENT OF ELECTRICAL ENGINEERING

ECKHARIE BEULAH (ELE/10/NE/001)

ROBERT WARD (ELE/10/NE/30)

DUE DATE: 4/03/2015

ATM OPERATIONAL SOFTWARE

Version 1.0 approved

POLYTECHNIC COMPUTER ENGINEERS

4TH MARCH 2015

2.2 Document Conventions

 PIN (Personal identification number):

2.3 Intended Audience and Reading Suggestions

The intended audience for this SRS consists of:

2.4 Product Scope

[1] Software engineering / Ian Sommerville. — 9th ed.

3.1 Product Perspective

COMPUTER BANKING DATABASE

3.2 Product Functions

The functions of the system are:

3.3 User Classes and Characteristics

 Customers are simply members of the public with no special training.

3.4.1 Initial assumption

For the user:

3.4.3 What can go wrong

3.4.4 Other activities

 Deposits by a customer are manually updated by the operator

3.4.5 System state on completion

3.5 Use Case Model Survey

3.5.1 USE CASE DIAGRAMS

Figure:3.1 use case diagram for user

Figure:3.2 use case diagram for operator

Figure3.3 use case diagram for both user and operator

3.5.2 USE CASES

3.6 Operating Environment

3.7 User Documentation

3.8 Assumptions and Dependencies

 Hardware never fails

4. External Interface Requirements

4.1 User Interfaces

the main menu (Fig. 2). I

4.2 Hardware Interfaces

 A screen that displays messages to the user

4.3 Software Interfaces

Software requirements at the end user are:

4.4 Communications Interfaces

5.1.1 Description and Priority

5.1.2 Stimulus/Response Sequences

5.1.3 Functional Requirements

Input: Account Number, Account PIN

Output: Main Menu

5.2 Banking transactions

3) Deposit feature: The user enters a deposit amount or 0

Input : Main Menu Option

5.3 Verify withdrawals and deposits

5.3.1 Description and priority

5.3.2 Stimulus and response

The system should be able to verify the withdrawals and deposits.

5.4 User exit interface

5.4.1 Description and priority

5.4.2 Stimulus and response

5.4.3 Functional requirement

6. Other Nonfunctional Requirements