Software Requirements

Specification
for

<Project>

Version 1.0 approved

Prepared by <author>

<organization>

<date created>

Copyright © 2024
Software Requirements Specification for <Project> Page ii

Table of Contents
Table of Contents...........................................................................................................................ii
Revision History.............................................................................................................................ii
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…………………………………………………………………………………… 1
1.6 References.........................................................................................................................................1
2. Overall Description..................................................................................................................2
2.1 Product Perspective...........................................................................................................................2
2.2 Product Features................................................................................................................................2
2.3 User Classes and Characteristics......................................................................................................2
2.4 Operating Environment.....................................................................................................................2
2.5 Design and Implementation Constraints...........................................................................................2
2.6 User Documentation.........................................................................................................................2
2.7 Assumptions and Dependencies.......................................................................................................3
3. System Features.......................................................................................................................3
3.1 System Feature 1...............................................................................................................................3
3.2 System Feature 2 (and so on)............................................................................................................4
4. External Interface Requirements...........................................................................................4
4.1 User Interfaces..................................................................................................................................4
4.2 Hardware Interfaces..........................................................................................................................4
4.3 Software Interfaces...........................................................................................................................4
5. Other Nonfunctional Requirements.......................................................................................5
5.1 Performance Requirements...............................................................................................................5
5.2 Safety Requirements.........................................................................................................................5
5.3 Security Requirements......................................................................................................................5
5.4 Software Quality Attributes..............................................................................................................5
6. Other Requirements................................................................................................................5
Appendix A: Glossary....................................................................................................................5
Appendix B: Analysis Models.......................................................................................................6
Appendix C: Issues List.................................................................................................................6

Revision History
Name Date Reason For Changes Version
Software Requirements Specification for <Project> Page 1

1. Introduction

1.1 Purpose
This document delineates the software requirements and specifications for an Automated Teller
Machine (ATM) network. With the proliferation of banking services and the increasing demand for
convenient financial transactions, the need for a robust, reliable, and secure ATM network is
paramount. This document serves as a blueprint for the development and implementation of the
ATM network software, ensuring it meets the functional and non-functional requirements essential
for seamless operation and customer satisfaction.

1.2 Document Conventions

The document follows standard software requirements and specification (SRS) conventions,
adhering to clear formatting and consistent language throughout. The following conventions are
observed:

1. **Font and Formatting**: The document is presented in a clear and legible font, such as Arial or
Times New Roman, with appropriate headings, subheadings, and body text formatting to enhance
readability.

2. **Priority Specification**: Each requirement statement is assigned a priority level to indicate its
importance and urgency. Priorities are typically denoted using a standardized notation such as
"High," "Medium," or "Low," or numerical values (e.g., 1, 2, 3) to signify the order of importance.

3. **Requirement Numbering**: Requirements are numbered sequentially for easy reference and
tracking. Each requirement statement is uniquely identified by a number or alphanumeric code to
facilitate cross-referencing within the document.

4. **Highlighting**: Key terms, definitions, and important sections may be highlighted using bold,
italic, or underline formatting to draw attention to critical information.

5. **Traceability**: Requirements are linked to specific functional or non-functional aspects of the

ATM network system. Traceability matrices may be provided to establish relationships between
high-level requirements and their corresponding detailed specifications.

6. **Version Control**: The document includes version control information, indicating the revision
history and any updates made to the SRS over time. This ensures that stakeholders can track
changes and understand the evolution of the requirements.

7. **Terminology**: Standardized terminology and abbreviations are used consistently throughout

the document to promote clarity and avoid ambiguity. A glossary of terms may be included for
reference if necessary.

Overall, the document aims to provide a comprehensive overview of the software requirements and
specifications for the ATM network, following established conventions to ensure clarity,
consistency, and traceability.
Software Requirements Specification for <Project> Page 2

1.3 Intended Audience and Reading Suggestions

This document is intended for stakeholders involved in the design, development, deployment, and
maintenance of the ATM network software. This includes software developers, system architects,
quality assurance engineers, project managers, and other relevant personnel responsible for
ensuring the successful implementation and operation of the ATM network.

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 process-
ing, 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
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
Software Requirements Specification for <Project> Page 3

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.

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.

1.6 References
### 1.6 References

1. Vision and Scope Document

- Author: Acme Corporation
- Version: 1.0
- Date: January 1, 2024

2. User Interface Style Guide

- Author: UX Design Team
- Version: 2.1
- Date: February 15, 2024

3. System Requirements Specifications

- Author: Development Team
- Version: 3.0
- Date: March 10, 2024

4. Use Case Documents

- Author: Business Analysts
- Version: 1.2
- Date: March 5, 2024
Software Requirements Specification for <Project> Page 4

5. Contract
- Author: Legal Department
- Version: 4.5
- Date: December 20, 2023

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 <Project> Page 5

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.

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
Software Requirements Specification for <Project> Page 6

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
• 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.6 User Documentation

<List the user documentation components (such as user manuals, on-line help, and tutorials) that
will be delivered along with the software. Identify any known user documentation delivery formats
or standards.>

2.7 Assumptions and Dependencies

• Hardware never fails
• ATM casing is impenetrable
• Limited number of transactions per day (sufficient paper for receipts)
• Limited amount of money withdrawn per day (sufficient money)
Software Requirements Specification for <Project> Page 7

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 Gen_
eral 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.
Software Requirements Specification for <Project> Page 8

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
Check if it is a valid cash card.It will be valid if
1. the information on the card can be read.
2. it is not expired.
• Output
Display error message and return cash card if it is invalid.

__

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 <Project> Page 9

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

<Specify any additional quality characteristics for the product that will be important to either the
customers or the developers. Some to consider are: adaptability, availability, correctness,
flexibility, interoperability, maintainability, portability, reliability, reusability, robustness, testability,
and usability. Write these to be specific, quantitative, and verifiable when possible. At the least,
clarify the relative preferences for various attributes, such as ease of use over ease of learning.>

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.
Software Requirements Specification for <Project> Page 10

5.4.3 Maintainability
Only maintainers are allowed to connect new ATMs to the network.

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 data base transaction (Atomicity, Consistency, Isolation, Durability).

Appendix A: Glossary
<Define all the terms necessary to properly interpret the SRS, including acronyms and
abbreviations. You may wish to build a separate glossary that spans multiple projects or the entire
organization, and just include terms specific to a single project in each SRS.>

Appendix B: Analysis Models

<Optionally, include any pertinent analysis models, such as data flow diagrams, class diagrams,
state-transition diagrams, or entity-relationship diagrams.>

Appendix C: Issues List

< This is a dynamic list of the open requirements issues that remain to be resolved, including
TBDs, pending decisions, information that is needed, conflicts awaiting resolution, and the like.>