SRS for ATM System

1 Introduction
Banking is one of the common and day to day attribute of life. Nowadays
it is totally different from that existed a few years ago banking has become
completely computerized new facilities such as credit cards, debit cards & ATM
has been introduced. ATM is automatic teller machine which is basically used
to withdraw money from an account.
1.1 Objectives
The objective of this software is similar to ATM software installed in
ATM center. It should first validate the pin in the ATM card. Then the type of
transaction is enquired and the information from the customer is validated. If it
is a withdrawal the amount is asked. After the money is delivered the
transaction just made is updated in the database where the customer’s
information is stored.
1.2 Scope
The scope of the project is to design an ATM system that will help in
completely automatic banking this software is going to be designed for
withdrawal and deposit of money and register the transaction in the database
where the customer’s information is stored.
1.3 Definitions
Account
A single account in a bank against which transactions can be applied.
Accounts may be of various types with at least checking and savings. A
customer can hold more than one account.
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.
Bank
A financial institution that holds accounts for customers and that issues
cash cards authorizing access to accounts over the ATM network.
the computer owned by a bank that interfaces with the ATM network and the
bank's 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.
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 customer's 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.
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 f considered
a different customer.
Transaction
a single integral request for operations on the accounts of a single
customer. We only specied 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 exibility to operate on accounts of different custom
1.4 Problem Statement
ATM is another type of banking where the most frequently type of
transaction made is withdrawal. A user may withdraw as much as many amount
as he wants until his account holds a sum greater than his withdrawal amount.
ATM is completely automated and there is no necessity of the ATM center
being placed at the bank itself. It can be placed in the shopping malls, airports,
railway stations etc. This ATM system can use any kind of interface. But it
should be user friendly and not confusing. Help manuals should be provided in
case any customer has problem working with the software. The system will
retain information on the entire customer who has necessity rights to access the
service. It will contain the balance amount in the account, rate of interest, any
special allowance for that customer and most of all pin number of the customer.
The ATM system should be compatible with any kind of database such as MS-
ACCESS, DB2, ORACLE, SQL, SERVER etc. the emphasis here is on
consistency.Some customer could have availed some special offers on his ATM
cards. So this must be taken care of and the appropriate data should be dealt
with.The ATM should provide easy access to the data for the customer. It
should also have a highly secure interface so that one can take money one
behalf of others. So the security is one of the main aspects in ATM.

2. Problem statement(Use case) analysis

2.1 Identified use cases
i. Login:
Here the user enters the card and the inputs his password to enter into the
main form. If the password is incorrect, the system will display an error
message.
ii. Transaction:
 This is the important part of the ATM system, where there are two types
of transaction-withdrawal and deposit. While withdrawing the user specifies the
amount and may request for the printed output also.
iii. Maintaining Customer Information:
Here the administrator plays an important role, whose work is to add
customer, delete customer account, update customer account, etc.
2.2 Identified Actors
i Administrator:
Administrator plays an important role. He is the system designer. All the
updating works is done by him only like adding, deleting customer accounts.
ii Database:
All the transaction works-withdrawal and deposit are updated in the
database.
iii Customer:
He is the external user the ATM system for taking money and depositing
money also.
3. Functional Requirements
Each requirement will be an independent class
3.1. Registration:
Customer will register his/her ATM card, and get acknowledged by
email.
• Choose PIN number
• Give personal information (CNIN# for verification)
• More information is extracted by card scanner
Verify info: Verification of card and user input will be done,Three tries are
allowed. Is available for interactive back
3.2 Withdraw amount:
User will withdraw amount according to its package.
o Golden Card:500<=Amount<=100,000
o Master Card:500<=Amount<=40,000
o VISA Card:500<=Amount<=25,000
o All packages are changeable
Receipt is recommended on each withdrawal of money with updates the bank
balance also.
3.3 Transfer Amount:
Two ways money transfer,
• Inter-Bank (Bank to Bank tax deduction 5 Rs per thousand) Changeable
• Intra-Bank (Within Bank tax deduction 2.5 per thousand) Changeable
• Account number of receiver is needed
• Acknowledgement on mobile text
• Transacted amount in addition to deduction will be subtracted from Current
Balance
• Receipt is recommended on each transfer.
• All packages are changeable
3.4 Mini Statement:
Mini statement of account current state will be available on the choice of
user. Thermal Printer as a subsystem will take on its own responsibility.
3.5 Change Pin#
User can change his/her pin number according to constraints given below.
• Four Decimal digits are allowed
• Three tries are allowed
• Previous pin# is recommended
• In case of illegal entry a complaint will be entered against respective account.
This will warn the related person to verify the details of this ATM recently
updated its complaint.
3.6 Configure ATM:
In case of any sort of administration configurations ATM will set to
configuration mode.
• Go to configuration mode
• Changing in settings.
• Save your recent settings
• Assuring Configuration will not harm saved database
• Back to user Mode
3.7 Under Maintenance:
A message will be displayed in case of any backend issue.“Sorry ATM is
under Maintenance please wait few minutes

4. External Interface Requirements

4.1 Hardware Interfaces
The ATM network has to provide hardware interfaces to:
 various printers
 various ATM machines (There are several companies producing the
ATM machines.)
 several types of networks The exact specification of the hardware
interfaces is not part of this document.
4.2 Software Interfaces
The ATM network has to provide software interfaces to: the software
used by different banks different network software. The exact, detailed
specification of the software interfaces is not part of this document.
4.3 Interfaces
There is no restriction of the ATM network to a specific network protocol
as long as the performance requirements are satisfied.
4.4 Performance Requirements
 Performance requirement
 1 Description :
o Error message should be displayed at least 30 sec.
  Performance Requirement
 2 Description:
o If there is no response from the bank computer after a request
within 2 minutes the card is rejected with an error message.
 Performance Requirement
 3 Description :
o The ATM dispenses money if and only if the withdrawal from the
account is processed and accepted by the bank.
 Performance Requirement
 4 Description:
o Each bank may be processing transactions from several ATMs at
the same time.

4.5 Attributes
4.5.1 Availability
The ATM network has to be available 24 hours a day.
4.5.2 Security
The ATM network should provide maximal security. In order to make
that much more transparent there are the following requirements:
1. It must be impossible to plug into the network.
4.5.3 Maintainability
Only maintainers are allowed to connect new ATM's to the network.
4.6 Other Requirements
Data Base
The ATM must be able to use several data formats according to the data
formats that are provided by the data bases of different banks. A transaction
should have all the properties of a database transaction.
Use case Diagram:
Class Diagram:
Activity Diagram:
Sequence Diagram:
ER Diagram:
Use Cases:

ID: CIS375-01
Title: Login
Description: Customer logs into the system by inserting the card and
entering pin
code.
Primary Actor: User/Customer
Preconditions: Customer has a bank account and an ATM Card.
Post conditions: Customer logged in to his/her account
Main success 1. Customer inserts the card
scenario: 2. Enter PIN if applicable
3. System checks if the card is authorized
4. System displays a list of possible transactions that
customer can perform
Extensions: 3a. Card is not authorized by the bank
3a1. System displays failure
attempt message 3a2. Eject the
card.
3b. PIN code is incorrect.
3b1. System displays a message to renter
the PIN code 3b2. Customer enters pin code
again
3b3. System checks if the pin code is correct
Frequency of Every time when user starts a session
Use:
Priority: High
ID: CIS375-02
Title: Check Balance
Description: Customer aims to know the balance in his/her account
Primary Actor: User/Customer
Precondition: Customer logged on to his/her account
Post conditions: Customer got information about balance
Main success 1. Customer clicks on check Balance from the
scenario: available list.
2. System extracts the information about
balance from bank database.
3. System displays the balance amount to the user.
4. System asks the user whether he want to do
some other transaction.
Frequency of Almost every time when user logs in.
Use:
Priority: High

ID: CIS375-03
Title: Deposit Cash
Description: Customer aims to deposit cash to her/his account.
Primary Actor: User/Customer
Preconditions: Customer logged on to his/her account
Post conditions: The balance of the customer is increased by the amount
of the inserted cash.
Main success 1. Customer selects deposit cash
scenario: 2. Customer inserts cash in the cash slot
3. System reads and calculates the inserted cash.
4. System displays the total amount inserted and asks
the user if the calculated amount is correct
5. System updates the account balance information
6. System displays the new balance
7. System asks the user whether he want to do
some other transaction.
Extensions: 4a. Customer does not agree on the displayed amount.
4a1. System recalculates the cash and displays the
amount. 4a2. System asks the user again if the cash
deposited is correct. 4a3.If the user agrees then the
steps in the main scenario
continue. In case the user does not agree then the system
ejects back the cash.
Priority: Medium
ID: CIS375-04
Title: Deposit Check
Description: Customer aims to deposit check to her/his account.
Primary Actor: User/Customer
Preconditions: Customer logged on to his/her account
Post conditions: The balance of the customer is increased by the amount
of the inserted check.
Main Success 1. Customer selects deposit check
Scenario: 2. Customer inserts check in the check slot
3. System reads and displays the check amount and
asks the user if the amount is correct
4. System reads and authorize the check and checks
the availabilityof balance in the account associated
with the check
5. System displays the check amount and asks
the user if the amount is correct
6. System updates the account balance information of
the user and deducts the same amount from the
check associated account.
7. System displays the new balance
8. System asks the user whether he want to do
some other transaction.
Extensions: 3a. Customer does not agree on the displayed amount.
3a1. System reads the check again and displays the
amount.
3a2. System asks the user again if the displayed
amount is correct. 3a3. If the user agrees then the steps
in the main scenario continue and in case the user does
 not agree then the system ejects back the check.
4a. Check is not authorized by the bank
4a1. System displays error message and ejects back the
check
4b. The amount is not available in the account associated
with the check.
4b1. System displays error message and ejects back the
check
Priority: Medium

ID: CIS375-05
Title: Withdraw Cash
Description: Customer aims to withdraw cash from her/his account.
Primary Actor: User/Customer
Preconditions: Customer logged on to his/her account
Post conditions: The balance of the customer is decreased by the amount
withdrawn.
Main Success 1. Customer selects withdraw cash.
Scenario: 2. Customer types the amount to be withdrawn.
3. System checks if the amount is available.
4. Cash is dispensed.
5. System updates the account balance information of
the user.
6. System displays the new balance
7. System asks the user whether he want to do
some other transaction.
Extensions: 3a. When cash is not available
3a1. System displays the current balance and asks user
 to update the amount entered

Priority: Medium

ID: CIS375-06
Title: Transfer money from one account to another
Description: Customer aims to transfer money to another account
Primary Actor: User/Customer
Preconditions: Customer logged on to his/her account
Post conditions: The balance of the customer is decreased by the
transferred amount and the receiver account is increased by
the amount transferred.
Main Success 1. Customer selects Transfer money.
Scenario: 2. Customer enters the account number of the receiver.
3. Customer types the amount to be transferred
4. System checks if the amount is available.
5. System updates the account balance information of
the user and the receiver.
6. System displays the new balance
7. System asks the user whether he/she want to do
some other transaction.
Extensions: 3a. When desired amount is not available in account
3a1. System displays the current balance and asks user
to update the amount entered to transfer.
Priority: Medium
5. Design of ATM system
5.1 Design Documentation
1. Login
1.1 Brief description:
This use case describes how the user logs into the System.
1.2 Flow of events:
1.2.1 Basic flow: This use case starts with the actor wishes to log in to the
ATM System.
1. The system requests the user to enter the name and PIN.
2. The actor enters the name and PIN.
3. The system validates the name and the PIN and logs the user into the
system.
1.2.2 Alternative flow:
1. If the user enters the wrong name and the PIN then the system
displays an error message.
2. The actor can either return to the basic flow or cancel login at
which point use case ends.
1.3 Pre conditions: None
1.4 Post conditions:
User will perform corresponding transaction.
2. Transaction
2.1 Brief description:
This describes the transaction that the user is doing.
2.2 Flow of events:
2.2.1 Basic flow:
This use case starts after the user has logged on to the system.
1. The system requests the user to enter the type of transaction of
either withdrawal or deposit and asks for customer information.
 2. The actor enters the type of transaction and the customer
information.
3. The system displays the corresponding transaction screen.
2.2.2 Alternative flow:
If the customer enters any wrong information then the system
displays an error message.
2.3 Pre Condition:
The user logs on to the system.
2.4 Post Condition:
Based on the transaction he gets the transaction screen.
3. Maintain Information about Customer
3.1 Brief description:
This describes how administrator takes care of customer information.
3.2 Flow of events:
3.2.1 Basic flow:
This use case starts after the administrator has logged into the
system.
1. The system asks the administrator whether he wants to add or
delete customer information.
2. The administrator then enters the type of maintenance.
3.2.2 Alternative flow: None
3.3 Pre Condition:
The administrator logs on to the system before this use case begin.
3.4 Post Condition:
Administrator gets the corresponding maintenance screen according to his
choice.

3.2.1.1 Adding Customer

 3.2.1.1.1 Basic flow:
1. This use case starts when the administrator has chosen to add
customer’s information.
2. The system asks the administrator to enter customer information.
3. The administrator enters the customer information.
4. The system displays the updated information.
3.2.1.1.2 Alternative flow:
If the administrator enters any wrong information the system
displays an error message.
3.2.1.2 Deleting Customer
3.2.1.2.1 Basic flow:
1. This use case starts when the administrator has chosen to delete
an existing customer from the system.
2. The system asks the administrator to enter the customer
information.
3. Administrator enters the corresponding user information.
4. The system then displays updated results.