Software Engineering Lab 2012

AUTOMATIC TELLER MACHINE (ATM) ABSTRACT

INTRODUCTION: An automated teller machine (ATM) or automatic banking machine (ABM) is a computerized telecommunications device that provides the clients of a financial institution with access to financial transactions in a public space without the need for a cashier, human clerk or bank teller. On most modern ATMs, the customer is identified by inserting a plastic ATM card with a magnetic stripe or a plastic smart card with a chip, that contains a unique card number and some security information such as an expiration date or CVVC (CVV). Authentication is provided by the customer entering a personal identification number (PIN). ATM is known as Automated Teller Machine which basically deals with transactions between a bank and its account holder. ATM as the name states it is an automatic machine which connects to the bank server to make transactions easily and efficiently. The important features of ATM are as follows:1. 2. 3. 4. 5. 6. An ATM machine can be accessed 24*7 hrs. Whenever an account holder makes transactions using ATM, all these transactions are reflected back (updated) to his current account. Every account holder who has an ATM card as provided by the bank is given a distinct pass code to access that particular ATM machine. This process works faster than a normal bank transaction which gives a lot of overhead. This kind of transaction is much more secure than the normal transaction. An account holder can access his/her account from any ATM located in the city or state irrespective of the name of the bank. However, the main disadvantage concerned with this ATM is that an account holder can withdraw a credit of limited amount.

PROBLEM STATEMENT
When they came into being, ATMs were treated to be a boon for the general public. There was no need to stand in queues in banks to withdraw money, no need to go the branch for years even to get a cheque deposited, cash deposited or for getting the cheque book issued. 1. 2. 3. 4. When ATM was first developed, there were only few ATMs and people had to travel long distance to access ATM. People who were not familiar to the ATM machines, they faced a lot of problems for accessing it. There were many security issues faced before ATM was introduced and after its introduction some security issues were solved. Some ATMs display the message Your request cannot be processed now, the meaning of which has to be interpreted by the customer only. It can mean that the ATM does not have sufficient funds, or that your account has some problem or it may also mean that the server of the bank is not working. The servers of the banks working so slowly that it is difficult to understand if the problem is with the machine or the banks's server.

5.

PROPOSED SYSTEM
The following features should be added for a proposed system: 1. An account holder should be able to deposit amount in his/her account through ATM.

Case Study

Page 1

Software Engineering Lab 2012

2. 3. 4. 5. An account holder should be able to transfer funds from his/her account to any person located anywhere in the world. An account holder should be able to check his recent or past bank statements .e.g. Online credit card purchases. An account holder should be provided wit h foreign currency exchange software , so that the customer can exchange currency depending on his needs. An ATM should be equipped with a security system which should scan the thumb impression of the account holder after he had entered the pin code. This will make ATM transaction more secure.

1. INTRODUCTION 1 . 1 P u r p o s e : This document describes the software requirements for an automated teller machine network (ATM). It is intended for the designer, developer and maintainer of the ATM. 1 . 2 S c o p e : The function of the ATM is to support a computerized banking network. 1. 3 Overview: The remainder of this document is organized as follows: There will be some definitions of important terms. Section 2 contains a general description of the ATM. Section 3 identifies the specific functional requirements, the external interfaces and performance requirements of the ATM. 1.4 Definitions: a. 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. b. ATM: A station that allows customers to enter their own transactions using cash cards as identification. The ATM interacts with the customer to gather transaction information sends the transaction information to the central computer for validation and processing and dispenses cash to the customer. We assume that an ATM need not operate independently of the network. c. Bank: A financial institution that holds accounts for customers and that issues cash cards authorizing access to accounts over the ATM network. d. 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. e. Cash Card: A card assigned to a bank customer that authorizes access to accounts using an ATM machine. Each card contains a bank code and a card number coded in accordance with national standards on credit cards and cash cards. The bank code uniquely identifies the bank within the consortium. The card number determines the accounts that the card can access. A card does not necessarily access all of a customers accounts. Each cash card is owned by a single customer but multiple copies of it may exist, so the possibility of simultaneous use of the same card from different machines must be considered. f. 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. g. Transaction: A single integral request for operations on the accounts of a single customer. We only specified that ATMs must dispense cash but we should not preclude the possibility of printing checks or accepting cash or checks. We may also want to provide the edibility to operate on accounts of different customers although it is not required yet. The different operations must balance properly. 2. General Purpose Descriptions 2.1 Product Perspective: An automated teller machine (ATM) is a computerized telecommunications device that provides the customers of a financial institution with access to financial transactions in a public space without the need for a human clerk or bank teller. On most modern ATMs, the customer is identified by inserting a plastic ATM card with a magnetic stripe or a plastic smartcard with a chip that contains a unique card number and some security information, such as an expiration date or CVC (CVV). Security is provided by the customer entering a personal identification number (PIN).

Case Study

Page 2

Software Engineering Lab 2012

2.2 Product Functions: Using an ATM, customers can access their bank accounts in order to make cash withdrawals (or credit card cash advances) and check their account balances. The functions of the system are: 1. Login 2. Get Balance Information 3. Withdraw Cash 4. Transfer Funds 2.3 User Characteristics: There are several users of the ATM network Customer: The customer interacts with the ATM network via the ATM. It must be very easy for them to use the ATM. They should be supported by the system in every possible way. Maintainer: It should be easy to maintain the whole system. The maintainer should be the only person that is allowed to connect a new ATM to the network.

2.4 Abbreviations: Throughout this document the following abbreviations are used k is the maximum withdrawal per day and account m is the maximum withdrawal per transaction is the minimum cash in the ATM to permit a transaction t is the total fund in the ATM at start of day. 3. Specific Requirements 3.1 Functional Requirements: The functional requirements are organized in two sections. First, requirements of the ATM and second, requirements of the bank. Requirements of the ATM: Functional requirement 1 Description Initialize parameters t_k_m_n Input ATM is initialized with t dollars k_m_n are entered Processing Storing the parameters Output Parameters are set Functional requirement 2 Description If no cash card is in the ATM the system should display initial display. Functional requirement 3 Description If the ATM is running out of money no card should be accepted.An error message is displayed. Input A card is entered Processing The amount of cash is less than t. Output Display an error message .Return cash card. Authorization The authorization starts after a customer has entered his card in the ATM. Functional requirement 4 Description The ATM has to check if the entered card is a valid cash card. Input Customer enters the cash card Processing

Case Study

Page 3

Software Engineering Lab 2012

Check if it is a valid cash card. It will be valid if. T h e i n f o r m a t i o n o n t h e c a r d c a n b e r e a d . 2.it is not expired Output Display error message and return cash card if it is invalid. Functional requirement 5 Description If the cash card is valid, the ATM should read the serial number and bank code. Input Valid cash card. Processing Read the serial number. Output Initiate authorization dialog Functional requirement 6 Description The serial number should be logged. Input Serial number from cash card Processing Log the number. Output Update to log file. Functional requirement 7 Description Authorization dialog: The user is requested to enter his password. The ATM verifies the bank code and password with the bank computer. Input Password from user, bank code from cash card. Processing Send serial number and password to bank computer, receive response from bank. Output Accept or reject authorization from bank. Functional requirement 8 Description Different negative answers from bank computer for authorization dialog. Input Response from bank or authorization dialog: bad password if the password was wrong.- bad bank code if the cash card of the bank is not supported by the ATM. - bad account if there are problems with the account. Processing If the ATM gets any of these messages from the bank computer the card will be ejected and the user will get the relevant error message. Output Card is ejected and error message is displayed. Functional requirement 9 Description If password and serial number are ok , the authorization process is finished. Input The ATM gets accept from the bank computer from authorization process. Processing Finishing authorization. Output

Case Study

Page 4

Software Engineering Lab 2012

Start transaction dialog. Functional requirement 10 Description If a card was entered more than three times in a row at any ATM and the password was wrong each time, the card is kept by the ATM. A message will be displayed that the customer should call the bank. Input Entering a wrong password for the fourth time in succession Processing Initiate authorization process. Response from bank computer is to keep the card. Output Display error message that the customer should call the bank. Functions These are the requirements for the different functions the ATM should provide after authorization. Functional requirement 11 Description The kind of transactions the ATM offers is : withdrawal Input Authorization successfully completed. Enter the amount to withdraw. Processing Amount entered is compared with m. Output Amount of money to be dispensed is displayed. Begin initial withdrawal sequence. Functional requirement 12 Description Initial withdrawal sequence If it is too much withdrawal redo the transaction. Input Customer has entered the amount of money Processing Error if the amount is greater than m. Output Start transaction or re-initiate transaction dialog if the amount is not within the pre-defined transaction policy. Functional requirement 13 Description Perform transaction. Input Initial withdrawal sequence successful Processing Send request to the bank computer. Output Wait for response from the bank computer. Functional requirement 14 Description If the transaction is successful, the money is dispensed. Input ATM gets message that transaction succeeded from the bank computer. Processing ATM prints receipt updates t and ejects the card. Dialog Customer should take the card. Output After the Customer has taken the card the money is dispensed.

Case Study

Page 5

Software Engineering Lab 2012

Functional requirement 15 Description If the money is dispensed and the amount is logged. Input The number of $20 bills requested is dispensed to the customer. Processing Log the amount of money against the serial number of the card. Output Amount logged together with the serial number. Response sent to bank for money dispensed. Functional requirement 16 Description If the transaction is not successful an error message should be displayed. The card should be ejected. Input ATM gets message transaction not successful from the bank computer. Processing ATM displays error message. Dialog: Customer should take the card. Output Eject card. Requirements of the bank computer for the ATM: Authorization: The bank computer gets a request from the ATM to verify an account. Functional requirement 1 Description The bank computer checks if the bank code is valid. A bank code is valid if the cash card was issued by the bank. Input Request from the ATM to verify card Serial number and password. Processing Check if the cash card was issued by the bank. Output Valid or invalid bank code. Functional requirement 2 Description If it is not a valid bank code, the bank computer will send a message to the ATM. Input I invalid bank code. Processing Process message. Output The bank computer sends the message bad bank code to the ATM. Functional requirement 3 Description The bank computer checks if the password is valid for a valid cash card. Input Request from the ATM to verify password. Processing Check password of the customer. Output Valid or invalid password. Functional requirement 4 Description If it is not a valid password, the bank computer will send a message to the ATM.

Case Study

Page 6

Software Engineering Lab 2012

Input Invalid password Processing Process message. Update count for invalid password for the account. Output The bank computer sends the message bad password to the ATM. Functional requirement 5 Description If it is a valid cash card and a valid password but there are problems with the account, the bank will send a message to the ATM that there are problems. Input Valid cash card and password Processing Process message Output The bank sends message bad account to the ATM. Functional requirement 6 Description If it is a valid cash card, a valid password and there are no problems with the account the bank computer will send a message to the ATM that everything is ok. Input Valid cash card, password and account Processing Process message. Output Send account ok to the ATM. Transaction: The bank computer gets a request to process a transaction from the ATM. Functional requirement 7 Description After a request the bank computer processes the transaction. Input Request to process a transaction on an account and amount m to withdraw. Processing Process transaction together with the software of the bank Update k for amount. Output If transaction succeeded, the bank computer sends the message transaction succeeded to the ATM. If not it will send transaction failed.

Functional requirement 8 Description Update account after money is dispensed Input Response from ATM about money dispensed. Processing Updates account Output New account record. Functional requirement 9 Description Each bank has a limit k for each account about the amount of money that is available via cash card each day/monthly.

Case Study

Page 7

Software Engineering Lab 2012

Input Request to process transaction. Processing Check if the amount of money doesnt exceed k. Output If the amount exceeds the limit, the transaction will fail. Functional requirement 10 Description The bank only provides security for their own computer and their own software.

Case Study

Page 8