SlideShare a Scribd company logo
Software Requirements
Specification
For
ATM
Software Requirements Specification for <ATM> - ii -
Table of Contents
1. Introduction..............................................................................................................................1
1.1 Purpose.................................................................................................................................1
1.2 Document Conventions........................................................................................................1
1.3 Intended Audience and Reading Suggestions......................................................................1
1.4 Definitions, acronyms, abbreviations ..................................................................................1
1.5 Scope…………………………………………………………………………………… 3
2. Overall Description..................................................................................................................3
2.1 Product Perspective..............................................................................................................3
2.2 Product Features...................................................................................................................4
2.3 User Classes and Characteristics .........................................................................................5
2.4 Operating Environment........................................................................................................5
2.5 Design and Implementation Constraints..............................................................................5
2.6 Assumptions and Dependencies ..........................................................................................6
3. Specific Requirements .............................................................................................................7
3.1 Functional Requirement.......................................................................................................7
3.2 Requirements of the bank computer for the ATM…………………………………… ………..11
4. External Interface Requirements.........................................................................................13
4.1 User Interfaces ...................................................................................................................13
4.2 Hardware Interfaces...........................................................................................................13
4.3 Software Interfaces ............................................................................................................13
5. Other Nonfunctional Requirements.....................................................................................14
5.1 Performance Requirements................................................................................................14
5.2 Safety Requirements ..........................................................................................................14
5.3 Security Requirements.......................................................................................................14
5.4 Software Quality Attributes...............................................................................................14
6. Other Requirements ..............................................................................................................15
Software Requirements Specification for <ATM> Page 1
1.Introduction
1.1 Purpose
This document describes the software requirements and specification for an automated teller
machine (ATM) network.
1.2 Document Conventions: font: TNR 11
1.3 Intended Audience and Reading Suggestions
The document is intended for all the stakeholders customer and the developer (designers, testers,
maintainers). The reader is assumed to have basic knowledge of banking accounts and account
services. Knowledge and understanding of UML diagrams is also required.
1.4 Definitions, abbreviations
1.4.1 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.
• Bank computer
Software Requirements Specification for <ATM> Page 2
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 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, but we should not preclude the possibility of printing checks or
accepting cash or checks. We may also want to provide the flexibility to operate on accounts of
different customers, although it is not required yet. The different operations must balance properly.
1.4.2 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.
➢ n : is the minimum cash in the ATM to permit a transaction.
➢ t : is the total fund in the ATM at start of day.
Software Requirements Specification for <ATM> Page 3
1.5 Project Scope
The software supports a computerized banking network. The network enables customers to
complete simple bank account services via automated teller machines (ATMs) that may be located
off premise and that need not be owned and operated by the customer’s bank. The ATM identifies a
customer by a cash card and password. It collects information about a simple account transaction
(e.g., deposit, withdrawal, transfer, bill payment), communicates the transaction information to the
customer’s bank, and dispenses cash to the customer. The banks provide their own software for
their own computers. The bank software requires appropriate record keeping and security
provisions. The software must handle concurrent accesses to the same account correctly.
2. Overall Description
2.1 Product Perspective
The ATM network does not work independently. It works together with the banks’ computers and
the software run by the network’s banks.
Communication interface: The ATMs communicate with the banking systems via a
communication network.
Software interface: The messages sent via the communication network are specific to the target
banking software systems. At present, two known banking systems will participate in the ATM
network.
Hardware interface: The software will run on an ATM computer yet to be chosen.
User interfaces
Customer: The customer user interface should be intuitive, such that 99.9% of all new ATM users
are able to complete their banking transactions without any assistance.
Bank Security Personnel: Bank security personnel are responsible for removing deposits and
adding cash to ATMs. There should be a simple interface (e.g., a switch or button) that they can use
to initialize the ATM whenever they restock.
Maintainer: The maintainer is responsible for adding new ATMs to the network and servicing
existing ATMs. A maintainer should be possible to add a new ATM to the network within 1 hour.
Software Requirements Specification for <ATM> Page 4
2.2 Product Features
The ATM should work 24 hrs. The ATM identifies a customer by a cash card and password. It
collects information about a simple account transaction (e.g., deposit, withdrawal, transfer, bill
payment), communicates the transaction information to the customer’s bank, and dispenses cash to
the customer. The banks provide their own software for their own computers. The bank software
requires appropriate record keeping and security provisions. The software must handle concurrent
accesses to the same account correctly.
Software Requirements Specification for <ATM> Page 5
2.3 User Classes and Characteristics
Characteristics: There are several users of the ATM network:
Customers are simply members of the general public with no special training.
Bank security personnel need have no special education or experience.
Maintainers must be experienced network administrators, to be able to connect new ATMs to the
network.
2.4 Operating Environment
The hardware, software and technology used should have following specifications:
• Ability to read the ATM card
• Ability to count the currency notes
• Touch screen for convenience
• Keypad (in case touchpad fails)
• Continuous power supply
• Ability to connect to bank’s network
• Ability to take input from user
• Ability to validate user
2.5 Design and Implementation Constraints
• Login
Validate Bank Card:
• Validate for Card Expiration Date
• Validate that the card's expiration date is later than today's date
• If card is expired, prompt error message "Card is expired"
Validate for Stolen or Lost Card:
Software Requirements Specification for <ATM> Page 6
• Validate that the card is not reported lost or stolen
• If card is lost, prompt error message, "Card has been reported lost"
• If card is stolen, prompt error message, "Card has been reported stolen"
Validate for Disabled Card:
• Validate that the card is not disabled
• If card is disabled, prompt error message, "Card has been disabled as of <expiration date>"
Validate for Locked Account:
• Validate that the account is not locked
• If account is locked, prompt error message "Account is locked"
Validate PIN:
• Validate that the password is not blank
• If PIN is blank, prompt error message "Please provide PIN"
• Validate that the password entered matches the password on file
• If password does not match, prompt error message "Password is Incorrect"
Lock Account:
• If number of consecutive unsuccessful logins exceeds three attempts, lock account
• Maintain Consecutive Unsuccessful Login Counter
• Increment Login Counter
• For every consecutive Login attempt, increment logic counter by 1.
• Reset login counter to 0 after login is successful.
• Get Balance Information
• Withdraw Cash
• Transfer Funds
2.6Assumptions and Dependencies
• Hardware never fails
• ATM casing is impenetrable
Software Requirements Specification for <ATM> Page 7
• Limited number of transactions per day (sufficient paper for receipts)
• Limited amount of money withdrawn per day (sufficient money)
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.
3.1.1 Requirements of the automated teller machine
The requirements for the automated teller machine are organized in the following way General
requirements, requirements for authorization, requirements for a transaction.
General
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:
Software Requirements Specification for <ATM> Page 8
• Description: The ATM has to check if the entered card is a valid cash-card.
• Input: Customer enters the cash card.
• Processing: Check if it is a valid cash card. It will be valid if
➢ The information on the card can be read.
➢ 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.
Software Requirements Specification for <ATM> Page 9
-“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: 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.
Software Requirements Specification for <ATM> Page 10
• 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 “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.
Functional requirement 15:
• Description: If the money is dispensed, collects amount.
• Input: The amount requested is dispensed to the customer.
• Processing: the attaches the amount of money against the serial number of the card.
• Output: Amount 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.
3.1.2 Requirements of the bank computer for the ATM
Software Requirements Specification for <ATM> Page 11
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: 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.
• 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:
Software Requirements Specification for <ATM> Page 12
• 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 “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.
• Input: Request to process transaction.
Software Requirements Specification for <ATM> Page 13
• Processing: Check if the amount of money doesn’t 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.
4. External Interface Requirements
4.1 User Interfaces
The customer user interface should be intuitive, such that 99.9% of all new ATM users are able to
complete their banking transactions without any assistance
4.2 Hardware Interfaces
The hardware should have following specifications:
• Ability to read the ATM card
• Ability to count the currency notes
• Touch screen for convenience
• Keypad (in case touchpad fails)
• Continuous power supply
• Ability to connect to bank’s network
• Ability to take input from user
• Ability to validate user
4.3 Software Interfaces
The software interfaces are specific to the target banking software systems.
Software Requirements Specification for <ATM> Page 14
5. Other Nonfunctional Requirements
5.1 Performance Requirements
• It must be able to perform in adverse conditions like high/low temperature etc.
• Uninterrupted interrupted connections
• High data transfer rate
5.2 Safety Requirements
• Must be safe kept in physical aspects, say in a cabin
• Must be bolted to floor to prevent any kind of theft
• Must have an emergency phone outside the cabin
• There must be an emergency phone just outside the cabin
• The cabin door must have an ATM card swipe slot
• • The cabin door will always be locked, which will open only when user swipes his/her
ATM card in the slot & is validated as genuine
5.3 Security Requirements
• Users accessibility is censured in all the ways
• 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 will be three
5.4 Software Quality Attributes
Security.
Performance.
Software Requirements Specification for <ATM> Page 15
5.4.1 Availability: The ATM network has to be available 24 hours a day.
5.4.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.
5.4.3 Maintainability: Only maintainers are allowed to connect new ATMs to the network.
6. Other Requirements
6.1 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 data base
transaction (Atomicity, Consistency, Isolation, Durability).

More Related Content

Similar to srs_ATM_example_for_reference.pdf

Bank management system
Bank management systemBank management system
Bank management system
sumanadas37
 
Document Atm machine using c language mini project.pdf
Document  Atm machine using c language mini project.pdfDocument  Atm machine using c language mini project.pdf
Document Atm machine using c language mini project.pdf
NEERAJRAJPUT81
 
Atm
AtmAtm
IRJET - Anti-Fraud ATM Security System
IRJET  - Anti-Fraud ATM Security SystemIRJET  - Anti-Fraud ATM Security System
IRJET - Anti-Fraud ATM Security System
IRJET Journal
 
Design.pptx
Design.pptxDesign.pptx
Design.pptx
SeetPuriTeachs
 
IRJET- Secured Merchant Payment using Biometric Transaction
IRJET-  	  Secured Merchant Payment using Biometric TransactionIRJET-  	  Secured Merchant Payment using Biometric Transaction
IRJET- Secured Merchant Payment using Biometric Transaction
IRJET Journal
 
BIOMETRIC AND MAGIC PIN AUTHENTICATION SYSTEM FOR ATM
BIOMETRIC AND MAGIC PIN AUTHENTICATION SYSTEM FOR ATMBIOMETRIC AND MAGIC PIN AUTHENTICATION SYSTEM FOR ATM
BIOMETRIC AND MAGIC PIN AUTHENTICATION SYSTEM FOR ATM
IRJET Journal
 
Fingerprint based transaction system
Fingerprint based transaction systemFingerprint based transaction system
Fingerprint based transaction system
sagar solanky
 
Concepts of Digital Banking
Concepts of Digital BankingConcepts of Digital Banking
Concepts of Digital Banking
AbinayaS31
 
ATM / Electronic Clearing Service
ATM / Electronic Clearing ServiceATM / Electronic Clearing Service
ATM / Electronic Clearing Service
ANANDHU BALAN
 
What is ATM
What is ATMWhat is ATM
What is ATM
insharah khan
 
python pre-submission report.pdf
python pre-submission report.pdfpython pre-submission report.pdf
python pre-submission report.pdf
SruthiMugle
 
Presentation On ATM Technology
Presentation On ATM TechnologyPresentation On ATM Technology
Presentation On ATM Technology
VINOD KUMAR RAMKUMAR
 
vinodkumarpptitpresentation-180916071852 (1).pdf
vinodkumarpptitpresentation-180916071852 (1).pdfvinodkumarpptitpresentation-180916071852 (1).pdf
vinodkumarpptitpresentation-180916071852 (1).pdf
desalewminale
 
Tounchpoint VAS Linkin
Tounchpoint VAS LinkinTounchpoint VAS Linkin
Tounchpoint VAS Linkin
Muhammad Ehrar Hussain
 
IRJET- Face Recognition System with HOG in ATMS
IRJET- Face Recognition System with HOG in ATMSIRJET- Face Recognition System with HOG in ATMS
IRJET- Face Recognition System with HOG in ATMS
IRJET Journal
 
IRJET-Efficient Cash Withdrawal from ATM Machine using Mobile Banking
IRJET-Efficient Cash Withdrawal from ATM Machine using Mobile BankingIRJET-Efficient Cash Withdrawal from ATM Machine using Mobile Banking
IRJET-Efficient Cash Withdrawal from ATM Machine using Mobile Banking
IRJET Journal
 
Atm project
Atm projectAtm project
A secured-&-effective-system-for-remote-monitoring-of-large-network-of-hetero...
A secured-&-effective-system-for-remote-monitoring-of-large-network-of-hetero...A secured-&-effective-system-for-remote-monitoring-of-large-network-of-hetero...
A secured-&-effective-system-for-remote-monitoring-of-large-network-of-hetero...
R Systems International
 
IRJET- Artificial Intelligence based Smart ATM
IRJET- Artificial Intelligence based Smart ATMIRJET- Artificial Intelligence based Smart ATM
IRJET- Artificial Intelligence based Smart ATM
IRJET Journal
 

Similar to srs_ATM_example_for_reference.pdf (20)

Bank management system
Bank management systemBank management system
Bank management system
 
Document Atm machine using c language mini project.pdf
Document  Atm machine using c language mini project.pdfDocument  Atm machine using c language mini project.pdf
Document Atm machine using c language mini project.pdf
 
Atm
AtmAtm
Atm
 
IRJET - Anti-Fraud ATM Security System
IRJET  - Anti-Fraud ATM Security SystemIRJET  - Anti-Fraud ATM Security System
IRJET - Anti-Fraud ATM Security System
 
Design.pptx
Design.pptxDesign.pptx
Design.pptx
 
IRJET- Secured Merchant Payment using Biometric Transaction
IRJET-  	  Secured Merchant Payment using Biometric TransactionIRJET-  	  Secured Merchant Payment using Biometric Transaction
IRJET- Secured Merchant Payment using Biometric Transaction
 
BIOMETRIC AND MAGIC PIN AUTHENTICATION SYSTEM FOR ATM
BIOMETRIC AND MAGIC PIN AUTHENTICATION SYSTEM FOR ATMBIOMETRIC AND MAGIC PIN AUTHENTICATION SYSTEM FOR ATM
BIOMETRIC AND MAGIC PIN AUTHENTICATION SYSTEM FOR ATM
 
Fingerprint based transaction system
Fingerprint based transaction systemFingerprint based transaction system
Fingerprint based transaction system
 
Concepts of Digital Banking
Concepts of Digital BankingConcepts of Digital Banking
Concepts of Digital Banking
 
ATM / Electronic Clearing Service
ATM / Electronic Clearing ServiceATM / Electronic Clearing Service
ATM / Electronic Clearing Service
 
What is ATM
What is ATMWhat is ATM
What is ATM
 
python pre-submission report.pdf
python pre-submission report.pdfpython pre-submission report.pdf
python pre-submission report.pdf
 
Presentation On ATM Technology
Presentation On ATM TechnologyPresentation On ATM Technology
Presentation On ATM Technology
 
vinodkumarpptitpresentation-180916071852 (1).pdf
vinodkumarpptitpresentation-180916071852 (1).pdfvinodkumarpptitpresentation-180916071852 (1).pdf
vinodkumarpptitpresentation-180916071852 (1).pdf
 
Tounchpoint VAS Linkin
Tounchpoint VAS LinkinTounchpoint VAS Linkin
Tounchpoint VAS Linkin
 
IRJET- Face Recognition System with HOG in ATMS
IRJET- Face Recognition System with HOG in ATMSIRJET- Face Recognition System with HOG in ATMS
IRJET- Face Recognition System with HOG in ATMS
 
IRJET-Efficient Cash Withdrawal from ATM Machine using Mobile Banking
IRJET-Efficient Cash Withdrawal from ATM Machine using Mobile BankingIRJET-Efficient Cash Withdrawal from ATM Machine using Mobile Banking
IRJET-Efficient Cash Withdrawal from ATM Machine using Mobile Banking
 
Atm project
Atm projectAtm project
Atm project
 
A secured-&-effective-system-for-remote-monitoring-of-large-network-of-hetero...
A secured-&-effective-system-for-remote-monitoring-of-large-network-of-hetero...A secured-&-effective-system-for-remote-monitoring-of-large-network-of-hetero...
A secured-&-effective-system-for-remote-monitoring-of-large-network-of-hetero...
 
IRJET- Artificial Intelligence based Smart ATM
IRJET- Artificial Intelligence based Smart ATMIRJET- Artificial Intelligence based Smart ATM
IRJET- Artificial Intelligence based Smart ATM
 

Recently uploaded

The Ultimate Guide to Top 36 DevOps Testing Tools for 2024.pdf
The Ultimate Guide to Top 36 DevOps Testing Tools for 2024.pdfThe Ultimate Guide to Top 36 DevOps Testing Tools for 2024.pdf
The Ultimate Guide to Top 36 DevOps Testing Tools for 2024.pdf
kalichargn70th171
 
The Power of Visual Regression Testing_ Why It Is Critical for Enterprise App...
The Power of Visual Regression Testing_ Why It Is Critical for Enterprise App...The Power of Visual Regression Testing_ Why It Is Critical for Enterprise App...
The Power of Visual Regression Testing_ Why It Is Critical for Enterprise App...
kalichargn70th171
 
DECODING JAVA THREAD DUMPS: MASTER THE ART OF ANALYSIS
DECODING JAVA THREAD DUMPS: MASTER THE ART OF ANALYSISDECODING JAVA THREAD DUMPS: MASTER THE ART OF ANALYSIS
DECODING JAVA THREAD DUMPS: MASTER THE ART OF ANALYSIS
Tier1 app
 
The Role of DevOps in Digital Transformation.pdf
The Role of DevOps in Digital Transformation.pdfThe Role of DevOps in Digital Transformation.pdf
The Role of DevOps in Digital Transformation.pdf
mohitd6
 
Folding Cheat Sheet #5 - fifth in a series
Folding Cheat Sheet #5 - fifth in a seriesFolding Cheat Sheet #5 - fifth in a series
Folding Cheat Sheet #5 - fifth in a series
Philip Schwarz
 
Secure-by-Design Using Hardware and Software Protection for FDA Compliance
Secure-by-Design Using Hardware and Software Protection for FDA ComplianceSecure-by-Design Using Hardware and Software Protection for FDA Compliance
Secure-by-Design Using Hardware and Software Protection for FDA Compliance
ICS
 
Folding Cheat Sheet #6 - sixth in a series
Folding Cheat Sheet #6 - sixth in a seriesFolding Cheat Sheet #6 - sixth in a series
Folding Cheat Sheet #6 - sixth in a series
Philip Schwarz
 
Why Apache Kafka Clusters Are Like Galaxies (And Other Cosmic Kafka Quandarie...
Why Apache Kafka Clusters Are Like Galaxies (And Other Cosmic Kafka Quandarie...Why Apache Kafka Clusters Are Like Galaxies (And Other Cosmic Kafka Quandarie...
Why Apache Kafka Clusters Are Like Galaxies (And Other Cosmic Kafka Quandarie...
Paul Brebner
 
The Comprehensive Guide to Validating Audio-Visual Performances.pdf
The Comprehensive Guide to Validating Audio-Visual Performances.pdfThe Comprehensive Guide to Validating Audio-Visual Performances.pdf
The Comprehensive Guide to Validating Audio-Visual Performances.pdf
kalichargn70th171
 
Best Practices & Tips for a Successful Odoo ERP Implementation
Best Practices & Tips for a Successful Odoo ERP ImplementationBest Practices & Tips for a Successful Odoo ERP Implementation
Best Practices & Tips for a Successful Odoo ERP Implementation
Envertis Software Solutions
 
Building the Ideal CI-CD Pipeline_ Achieving Visual Perfection
Building the Ideal CI-CD Pipeline_ Achieving Visual PerfectionBuilding the Ideal CI-CD Pipeline_ Achieving Visual Perfection
Building the Ideal CI-CD Pipeline_ Achieving Visual Perfection
Applitools
 
What is Continuous Testing in DevOps - A Definitive Guide.pdf
What is Continuous Testing in DevOps - A Definitive Guide.pdfWhat is Continuous Testing in DevOps - A Definitive Guide.pdf
What is Continuous Testing in DevOps - A Definitive Guide.pdf
kalichargn70th171
 
Cost-Effective Strategies For iOS App Development
Cost-Effective Strategies For iOS App DevelopmentCost-Effective Strategies For iOS App Development
Cost-Effective Strategies For iOS App Development
Softradix Technologies
 
Photoshop Tutorial for Beginners (2024 Edition)
Photoshop Tutorial for Beginners (2024 Edition)Photoshop Tutorial for Beginners (2024 Edition)
Photoshop Tutorial for Beginners (2024 Edition)
alowpalsadig
 
Superpower Your Apache Kafka Applications Development with Complementary Open...
Superpower Your Apache Kafka Applications Development with Complementary Open...Superpower Your Apache Kafka Applications Development with Complementary Open...
Superpower Your Apache Kafka Applications Development with Complementary Open...
Paul Brebner
 
Boost Your Savings with These Money Management Apps
Boost Your Savings with These Money Management AppsBoost Your Savings with These Money Management Apps
Boost Your Savings with These Money Management Apps
Jhone kinadey
 
Baha Majid WCA4Z IBM Z Customer Council Boston June 2024.pdf
Baha Majid WCA4Z IBM Z Customer Council Boston June 2024.pdfBaha Majid WCA4Z IBM Z Customer Council Boston June 2024.pdf
Baha Majid WCA4Z IBM Z Customer Council Boston June 2024.pdf
Baha Majid
 
Software Test Automation - A Comprehensive Guide on Automated Testing.pdf
Software Test Automation - A Comprehensive Guide on Automated Testing.pdfSoftware Test Automation - A Comprehensive Guide on Automated Testing.pdf
Software Test Automation - A Comprehensive Guide on Automated Testing.pdf
kalichargn70th171
 
Migration From CH 1.0 to CH 2.0 and Mule 4.6 & Java 17 Upgrade.pptx
Migration From CH 1.0 to CH 2.0 and  Mule 4.6 & Java 17 Upgrade.pptxMigration From CH 1.0 to CH 2.0 and  Mule 4.6 & Java 17 Upgrade.pptx
Migration From CH 1.0 to CH 2.0 and Mule 4.6 & Java 17 Upgrade.pptx
ervikas4
 
What’s New in VictoriaLogs - Q2 2024 Update
What’s New in VictoriaLogs - Q2 2024 UpdateWhat’s New in VictoriaLogs - Q2 2024 Update
What’s New in VictoriaLogs - Q2 2024 Update
VictoriaMetrics
 

Recently uploaded (20)

The Ultimate Guide to Top 36 DevOps Testing Tools for 2024.pdf
The Ultimate Guide to Top 36 DevOps Testing Tools for 2024.pdfThe Ultimate Guide to Top 36 DevOps Testing Tools for 2024.pdf
The Ultimate Guide to Top 36 DevOps Testing Tools for 2024.pdf
 
The Power of Visual Regression Testing_ Why It Is Critical for Enterprise App...
The Power of Visual Regression Testing_ Why It Is Critical for Enterprise App...The Power of Visual Regression Testing_ Why It Is Critical for Enterprise App...
The Power of Visual Regression Testing_ Why It Is Critical for Enterprise App...
 
DECODING JAVA THREAD DUMPS: MASTER THE ART OF ANALYSIS
DECODING JAVA THREAD DUMPS: MASTER THE ART OF ANALYSISDECODING JAVA THREAD DUMPS: MASTER THE ART OF ANALYSIS
DECODING JAVA THREAD DUMPS: MASTER THE ART OF ANALYSIS
 
The Role of DevOps in Digital Transformation.pdf
The Role of DevOps in Digital Transformation.pdfThe Role of DevOps in Digital Transformation.pdf
The Role of DevOps in Digital Transformation.pdf
 
Folding Cheat Sheet #5 - fifth in a series
Folding Cheat Sheet #5 - fifth in a seriesFolding Cheat Sheet #5 - fifth in a series
Folding Cheat Sheet #5 - fifth in a series
 
Secure-by-Design Using Hardware and Software Protection for FDA Compliance
Secure-by-Design Using Hardware and Software Protection for FDA ComplianceSecure-by-Design Using Hardware and Software Protection for FDA Compliance
Secure-by-Design Using Hardware and Software Protection for FDA Compliance
 
Folding Cheat Sheet #6 - sixth in a series
Folding Cheat Sheet #6 - sixth in a seriesFolding Cheat Sheet #6 - sixth in a series
Folding Cheat Sheet #6 - sixth in a series
 
Why Apache Kafka Clusters Are Like Galaxies (And Other Cosmic Kafka Quandarie...
Why Apache Kafka Clusters Are Like Galaxies (And Other Cosmic Kafka Quandarie...Why Apache Kafka Clusters Are Like Galaxies (And Other Cosmic Kafka Quandarie...
Why Apache Kafka Clusters Are Like Galaxies (And Other Cosmic Kafka Quandarie...
 
The Comprehensive Guide to Validating Audio-Visual Performances.pdf
The Comprehensive Guide to Validating Audio-Visual Performances.pdfThe Comprehensive Guide to Validating Audio-Visual Performances.pdf
The Comprehensive Guide to Validating Audio-Visual Performances.pdf
 
Best Practices & Tips for a Successful Odoo ERP Implementation
Best Practices & Tips for a Successful Odoo ERP ImplementationBest Practices & Tips for a Successful Odoo ERP Implementation
Best Practices & Tips for a Successful Odoo ERP Implementation
 
Building the Ideal CI-CD Pipeline_ Achieving Visual Perfection
Building the Ideal CI-CD Pipeline_ Achieving Visual PerfectionBuilding the Ideal CI-CD Pipeline_ Achieving Visual Perfection
Building the Ideal CI-CD Pipeline_ Achieving Visual Perfection
 
What is Continuous Testing in DevOps - A Definitive Guide.pdf
What is Continuous Testing in DevOps - A Definitive Guide.pdfWhat is Continuous Testing in DevOps - A Definitive Guide.pdf
What is Continuous Testing in DevOps - A Definitive Guide.pdf
 
Cost-Effective Strategies For iOS App Development
Cost-Effective Strategies For iOS App DevelopmentCost-Effective Strategies For iOS App Development
Cost-Effective Strategies For iOS App Development
 
Photoshop Tutorial for Beginners (2024 Edition)
Photoshop Tutorial for Beginners (2024 Edition)Photoshop Tutorial for Beginners (2024 Edition)
Photoshop Tutorial for Beginners (2024 Edition)
 
Superpower Your Apache Kafka Applications Development with Complementary Open...
Superpower Your Apache Kafka Applications Development with Complementary Open...Superpower Your Apache Kafka Applications Development with Complementary Open...
Superpower Your Apache Kafka Applications Development with Complementary Open...
 
Boost Your Savings with These Money Management Apps
Boost Your Savings with These Money Management AppsBoost Your Savings with These Money Management Apps
Boost Your Savings with These Money Management Apps
 
Baha Majid WCA4Z IBM Z Customer Council Boston June 2024.pdf
Baha Majid WCA4Z IBM Z Customer Council Boston June 2024.pdfBaha Majid WCA4Z IBM Z Customer Council Boston June 2024.pdf
Baha Majid WCA4Z IBM Z Customer Council Boston June 2024.pdf
 
Software Test Automation - A Comprehensive Guide on Automated Testing.pdf
Software Test Automation - A Comprehensive Guide on Automated Testing.pdfSoftware Test Automation - A Comprehensive Guide on Automated Testing.pdf
Software Test Automation - A Comprehensive Guide on Automated Testing.pdf
 
Migration From CH 1.0 to CH 2.0 and Mule 4.6 & Java 17 Upgrade.pptx
Migration From CH 1.0 to CH 2.0 and  Mule 4.6 & Java 17 Upgrade.pptxMigration From CH 1.0 to CH 2.0 and  Mule 4.6 & Java 17 Upgrade.pptx
Migration From CH 1.0 to CH 2.0 and Mule 4.6 & Java 17 Upgrade.pptx
 
What’s New in VictoriaLogs - Q2 2024 Update
What’s New in VictoriaLogs - Q2 2024 UpdateWhat’s New in VictoriaLogs - Q2 2024 Update
What’s New in VictoriaLogs - Q2 2024 Update
 

srs_ATM_example_for_reference.pdf

  • 2. Software Requirements Specification for <ATM> - ii - Table of Contents 1. Introduction..............................................................................................................................1 1.1 Purpose.................................................................................................................................1 1.2 Document Conventions........................................................................................................1 1.3 Intended Audience and Reading Suggestions......................................................................1 1.4 Definitions, acronyms, abbreviations ..................................................................................1 1.5 Scope…………………………………………………………………………………… 3 2. Overall Description..................................................................................................................3 2.1 Product Perspective..............................................................................................................3 2.2 Product Features...................................................................................................................4 2.3 User Classes and Characteristics .........................................................................................5 2.4 Operating Environment........................................................................................................5 2.5 Design and Implementation Constraints..............................................................................5 2.6 Assumptions and Dependencies ..........................................................................................6 3. Specific Requirements .............................................................................................................7 3.1 Functional Requirement.......................................................................................................7 3.2 Requirements of the bank computer for the ATM…………………………………… ………..11 4. External Interface Requirements.........................................................................................13 4.1 User Interfaces ...................................................................................................................13 4.2 Hardware Interfaces...........................................................................................................13 4.3 Software Interfaces ............................................................................................................13 5. Other Nonfunctional Requirements.....................................................................................14 5.1 Performance Requirements................................................................................................14 5.2 Safety Requirements ..........................................................................................................14 5.3 Security Requirements.......................................................................................................14 5.4 Software Quality Attributes...............................................................................................14 6. Other Requirements ..............................................................................................................15
  • 3. Software Requirements Specification for <ATM> Page 1 1.Introduction 1.1 Purpose This document describes the software requirements and specification for an automated teller machine (ATM) network. 1.2 Document Conventions: font: TNR 11 1.3 Intended Audience and Reading Suggestions The document is intended for all the stakeholders customer and the developer (designers, testers, maintainers). The reader is assumed to have basic knowledge of banking accounts and account services. Knowledge and understanding of UML diagrams is also required. 1.4 Definitions, abbreviations 1.4.1 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. • Bank computer
  • 4. Software Requirements Specification for <ATM> Page 2 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 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, but we should not preclude the possibility of printing checks or accepting cash or checks. We may also want to provide the flexibility to operate on accounts of different customers, although it is not required yet. The different operations must balance properly. 1.4.2 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. ➢ n : is the minimum cash in the ATM to permit a transaction. ➢ t : is the total fund in the ATM at start of day.
  • 5. Software Requirements Specification for <ATM> Page 3 1.5 Project Scope The software supports a computerized banking network. The network enables customers to complete simple bank account services via automated teller machines (ATMs) that may be located off premise and that need not be owned and operated by the customer’s bank. The ATM identifies a customer by a cash card and password. It collects information about a simple account transaction (e.g., deposit, withdrawal, transfer, bill payment), communicates the transaction information to the customer’s bank, and dispenses cash to the customer. The banks provide their own software for their own computers. The bank software requires appropriate record keeping and security provisions. The software must handle concurrent accesses to the same account correctly. 2. Overall Description 2.1 Product Perspective The ATM network does not work independently. It works together with the banks’ computers and the software run by the network’s banks. Communication interface: The ATMs communicate with the banking systems via a communication network. Software interface: The messages sent via the communication network are specific to the target banking software systems. At present, two known banking systems will participate in the ATM network. Hardware interface: The software will run on an ATM computer yet to be chosen. User interfaces Customer: The customer user interface should be intuitive, such that 99.9% of all new ATM users are able to complete their banking transactions without any assistance. Bank Security Personnel: Bank security personnel are responsible for removing deposits and adding cash to ATMs. There should be a simple interface (e.g., a switch or button) that they can use to initialize the ATM whenever they restock. Maintainer: The maintainer is responsible for adding new ATMs to the network and servicing existing ATMs. A maintainer should be possible to add a new ATM to the network within 1 hour.
  • 6. Software Requirements Specification for <ATM> Page 4 2.2 Product Features The ATM should work 24 hrs. The ATM identifies a customer by a cash card and password. It collects information about a simple account transaction (e.g., deposit, withdrawal, transfer, bill payment), communicates the transaction information to the customer’s bank, and dispenses cash to the customer. The banks provide their own software for their own computers. The bank software requires appropriate record keeping and security provisions. The software must handle concurrent accesses to the same account correctly.
  • 7. Software Requirements Specification for <ATM> Page 5 2.3 User Classes and Characteristics Characteristics: There are several users of the ATM network: Customers are simply members of the general public with no special training. Bank security personnel need have no special education or experience. Maintainers must be experienced network administrators, to be able to connect new ATMs to the network. 2.4 Operating Environment The hardware, software and technology used should have following specifications: • Ability to read the ATM card • Ability to count the currency notes • Touch screen for convenience • Keypad (in case touchpad fails) • Continuous power supply • Ability to connect to bank’s network • Ability to take input from user • Ability to validate user 2.5 Design and Implementation Constraints • Login Validate Bank Card: • Validate for Card Expiration Date • Validate that the card's expiration date is later than today's date • If card is expired, prompt error message "Card is expired" Validate for Stolen or Lost Card:
  • 8. Software Requirements Specification for <ATM> Page 6 • Validate that the card is not reported lost or stolen • If card is lost, prompt error message, "Card has been reported lost" • If card is stolen, prompt error message, "Card has been reported stolen" Validate for Disabled Card: • Validate that the card is not disabled • If card is disabled, prompt error message, "Card has been disabled as of <expiration date>" Validate for Locked Account: • Validate that the account is not locked • If account is locked, prompt error message "Account is locked" Validate PIN: • Validate that the password is not blank • If PIN is blank, prompt error message "Please provide PIN" • Validate that the password entered matches the password on file • If password does not match, prompt error message "Password is Incorrect" Lock Account: • If number of consecutive unsuccessful logins exceeds three attempts, lock account • Maintain Consecutive Unsuccessful Login Counter • Increment Login Counter • For every consecutive Login attempt, increment logic counter by 1. • Reset login counter to 0 after login is successful. • Get Balance Information • Withdraw Cash • Transfer Funds 2.6Assumptions and Dependencies • Hardware never fails • ATM casing is impenetrable
  • 9. Software Requirements Specification for <ATM> Page 7 • Limited number of transactions per day (sufficient paper for receipts) • Limited amount of money withdrawn per day (sufficient money) 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. 3.1.1 Requirements of the automated teller machine The requirements for the automated teller machine are organized in the following way General requirements, requirements for authorization, requirements for a transaction. General 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:
  • 10. Software Requirements Specification for <ATM> Page 8 • Description: The ATM has to check if the entered card is a valid cash-card. • Input: Customer enters the cash card. • Processing: Check if it is a valid cash card. It will be valid if ➢ The information on the card can be read. ➢ 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.
  • 11. Software Requirements Specification for <ATM> Page 9 -“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: 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.
  • 12. Software Requirements Specification for <ATM> Page 10 • 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 “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. Functional requirement 15: • Description: If the money is dispensed, collects amount. • Input: The amount requested is dispensed to the customer. • Processing: the attaches the amount of money against the serial number of the card. • Output: Amount 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. 3.1.2 Requirements of the bank computer for the ATM
  • 13. Software Requirements Specification for <ATM> Page 11 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: 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. • 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:
  • 14. Software Requirements Specification for <ATM> Page 12 • 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 “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. • Input: Request to process transaction.
  • 15. Software Requirements Specification for <ATM> Page 13 • Processing: Check if the amount of money doesn’t 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. 4. External Interface Requirements 4.1 User Interfaces The customer user interface should be intuitive, such that 99.9% of all new ATM users are able to complete their banking transactions without any assistance 4.2 Hardware Interfaces The hardware should have following specifications: • Ability to read the ATM card • Ability to count the currency notes • Touch screen for convenience • Keypad (in case touchpad fails) • Continuous power supply • Ability to connect to bank’s network • Ability to take input from user • Ability to validate user 4.3 Software Interfaces The software interfaces are specific to the target banking software systems.
  • 16. Software Requirements Specification for <ATM> Page 14 5. Other Nonfunctional Requirements 5.1 Performance Requirements • It must be able to perform in adverse conditions like high/low temperature etc. • Uninterrupted interrupted connections • High data transfer rate 5.2 Safety Requirements • Must be safe kept in physical aspects, say in a cabin • Must be bolted to floor to prevent any kind of theft • Must have an emergency phone outside the cabin • There must be an emergency phone just outside the cabin • The cabin door must have an ATM card swipe slot • • The cabin door will always be locked, which will open only when user swipes his/her ATM card in the slot & is validated as genuine 5.3 Security Requirements • Users accessibility is censured in all the ways • 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 will be three 5.4 Software Quality Attributes Security. Performance.
  • 17. Software Requirements Specification for <ATM> Page 15 5.4.1 Availability: The ATM network has to be available 24 hours a day. 5.4.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. 5.4.3 Maintainability: Only maintainers are allowed to connect new ATMs to the network. 6. Other Requirements 6.1 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 data base transaction (Atomicity, Consistency, Isolation, Durability).