Software Requirements

Specification
for

<Project>

Version 1.0 approved

Prepared by <author>

<organization>

<date created>

Copyright © 1999 by Karl E. Wiegers. Permission is granted to use, modify, and distribute this document.
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 Stackeholder and Reading Suggestions..........................................................................................1
1.4 Product Scope.................................................................................................................................1
1.5 References.......................................................................................................................................1
2. Overall Description..................................................................................................................2
2.1 Product Perspective........................................................................................................................2
2.2 Product Functions...........................................................................................................................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. External Interface Requirements...........................................................................................3
3.1 User Interfaces................................................................................................................................3
3.2 Hardware Interfaces........................................................................................................................3
3.3 Software Interfaces.........................................................................................................................3
3.4 Communications Interfaces............................................................................................................3
4. System Features.......................................................................................................................4
4.1 System Feature 1............................................................................................................................4
4.2 System Feature 2 (and so on)..........................................................................................................4
5. Other Nonfunctional Requirements.......................................................................................4
5.1 Performance Requirements.............................................................................................................4
5.2 Safety Requirements.......................................................................................................................5
5.3 Security Requirements....................................................................................................................5
5.4 Software Quality Attributes............................................................................................................5
5.5 Business Rules................................................................................................................................5
6. Other Requirements................................................................................................................5
Appendix A: Glossary...................................................................................................................5
Appendix B: Analysis Models.......................................................................................................5
Appendix C: To Be Determined List...........................................................................................6

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

1. Introduction

1.1 Purpose

1.1.1 System Requirements Specifications Purpose

The purpose of this document is to detail the requirements for a “Biometric ATM Banking System”
software. This formal document will be used to define the stakeholders’ problem and solutions to solve
the problem.

1.1.2 System Requirements Specifications Intended Audience

This document is intended for the developers, engineers, managers, the customer and all other stakeholders in
the system.

1.2 Document Conventions

<Describe any standards or typographical conventions that were followed when writing this SRS, such as fonts or
highlighting that have special significance. For example, state whether priorities for higher-level requirements are
assumed to be inherited by detailed requirements, or whether every requirement statement is to have its own
priority.>

1.3 Stakeholders and Reading Suggestions

A stakeholder is any entity that has a vested or declared interest in the success or failure of a
system or software being developed. Stakeholder Analysis (SA) during a software or system elicitation
process since a stakeholder has a “stake” in the end product. SA is a method that accounts for and often
incorporates the needs of the stakeholders. Understanding the stakeholders’ role, interests and weight
that their input carries will facilitate realistic and sustainable development.

During system elicitation, selected stakeholders are needed to provide divergent viewpoints,
shed light on the impact, identify opposing opinions, and address any potential issues with the
expected solution being developed. Stakeholders range in form, size and capacity and can be
individuals, organizations or unorganized groups.

1.3.1 Stakeholders and Roles

The new Lock Bank Biometric ATM Banking System has both internal and external
stakeholders that should be considered during elicitation. In the following Table 2.2.1
Software Requirements Specification for <Project> Page 4

Stakeholders and Roles, key stakeholders are identified and their roles are defined.
Software Requirements Specification for <Project> Page 5

1.3.2 Table 2.2.1 Stakeholders and Roles

Lock Bank Biometric ATM Banking System Stakeholders

Acquirers Develop a plan and oversee procurement of the system that will
meet the goals of and address the problem presented by Lock Bank.
Assessors Ensure that the system conforms to the needs, standards and legal
regulations.
Bank managers Oversee the bank personnel and are responsible for ensuring they
adhere to policies and job role duties. Also responsible for issue resolution at
branch location.
Communicators Contributors that communicate with, document and provide training
to stakeholders germane to the system.
Competition Representatives of other banks
Counter staff Bank tellers that assist or account specialists that assist with various
banking needs.
Customer Sometimes referred to as the client, the customer pays for the
development. The customer often includes "C" level management (e.g.
CEO, CFO, CIO) and can hinder development usability over
costs.
Database Develop, configure, identify and resolve issues of all features and
administrators capabilities of the database system.
Developers Use system specifications to develop or lead a team in the
development of the system.
Maintainers Responsible for managing the system as it evolves once
operational.
Production Design, deploy, and manage the hardware and software the system
Engineers will be built, tested, and run on.
Security Oversees security of the system by leading a security that monitors the
managers system use and network traffic. Security teams watch and
respond to security system alerts.
Suppliers Provide necessary components for which the system will run (e.g.
hardware, software, infrastructure, etc.).
Supporters Helps the user with the system once it is in place and operational.
System Keep the system operational, administer users, and perform system
administrators configuration.
Testers Test the system to verify it is ready for use.
User Users can be divided into two types: content providers and content
consumers. Content providers (e.g. bank personnel) input information into
the system. Content consumers (e.g. bank account
holders) use the system to access and consume system resources.
Software Requirements Specification for <Project> Page 6

1.4 Product Scope

1.4.1 Products for Production

The products to be developed include the Biometric ATM Banking System and
a Biometric Database.

1.4.2 Inclusions

The Biometric ATM Banking System will allow customers to logon to their bank
accounts using biometrics and a pin. Customers will sign up at any Lock Bank
location. Their biometric profile of their unique features and characteristics will be
stored in a database for comparison during account access requests. Approved
access will give the customer limited banking functions.
The software will allow biometric logon using a mobile application if it is compatible.

1.4.3 Exclusions

Excluded from this project are the required hardware, mobile application
development and device compatibility outside of the Lock Bank equipment. While
the application does allow for mobile application access, the development of the
mobile application is third party and support for the mobile application is not
included. Mobile applications and privately owned equipment functions are
introduced but not within this scope. All details pertaining to mobile applications,
mobile devices and privately own equipment are included solely for future
considerations and expansion of this project. Functions that the software will not
allow includes: access to tax documents or the ability to download activity.

1.4.4 Application Benefits, Objectives and Goals

Lock Bank recognizes that there are several risk factors associated with plastic
ATM card use for banking. Carrying an ATM card has risks that are a result of:
card fraud, card duplication, card sharing by family and friends, inability to trace
use by unauthorized users, PIN copying, loss and theft. The benefit of using a
Biometric ATM is that it is safer and secure. There is no need to carry a card that
could be lost, stolen or skimmed.

Lock Bank’s goal for the Biometric ATM Banking System is to provide
convenience and security for their banking customers that sign up. With this new
system, Lock Bank will provide
greater services than their competition in order to stay competitive. Account access
monitoring accuracy will be increased since biometric authentication is based on a
Software Requirements Specification for <Project> Page 7

customer’s unique characteristics.

Software Requirements Specification for <Project> Page 1

1.5 References
American Bank. (n.d.). Bank acronyms. Retrieved from
https://www.ambnk.com/custom/fi/ambnk/fb/disclosure/BANK-
ACRONYMS.pdf

Boult, T. E. (n.d.). Software Requirements Specification (SRS) Template.

Retrieved from University of Colorado Colorado Springs website:
www.uccs.edu/Documents/tboult/srs.doc
Chappell, D. (2012, March 16). The three aspects of software quality:
Functional, structural, and process [PDF]. Retrieved from
http://www.davidchappell.com/writing/white_papers/
The_Three_Aspects_of_Software_ Quality_v1.0-Chappell.pdf
Collofello , James S. (1988). Introduction to software verification and
validation. Pittsburgh, PA: Carnegie Mellon University, Software Engineering
Institute.
Davies, P. J. (n.d.). Requirement’s analysis and use-case diagrams [PPT].
Retrieved from https://web.cs.dal.ca/~hawkey/3130/UseCaseDiagrams.ppt
Software Requirements Specification for <Project> Page 2

2. Overall Description

2.1 Product Perspective

Fingerprint Based ATM is a desktop application where fingerprint of the user

issued as an authentication. The fingerprint minutiae features are different
foreach human being so the user can be identified uniquely. Instead of using
ATM card, Fingerprint Based ATM is safer and secure. There is no worry of
losing ATM card and no need to carry ATM card in your wallet

2.2 Product Functions

Withdrawal - The user selects withdraw from the menu and withdraws cash
from the ATM.

Deposit -The user selects deposit option from the menu and deposits cash
or cheques into the ATM.

Print transaction -ATM prints a record after a transaction.

Exits -user completes session with ATM and retrieves card

2.3 User Classes and Characteristics

The system will be used in the ATM. , Bank agent, ATM operator & LockBank
Acctholder will be the main users. Given the condition that not all the users are
computer-literate some users may have to be trained on using the system. The
system is also designed to be user-friendly. It uses a Graphical User Interface
(GUI).
Software Requirements Specification for <Project> Page 3

Bank agent: Bank agent has some basic computer training. They are
responsible for managing ATM .

LockBank Acctholder : LockBank Acctholder has some basic computer

knowledge. They can make enquires, view their profile details and can apply
for gym membership.

ATM operator: They all have post-secondary education relating to general

business administration practices. Every administrator has basic computer
training. They are responsible for all of the Adding/updating different user
roles.

2.4

2.5 Operating Environment

2.5.1 SOFTWARE REQUIREMENTS:

•OS Windows-7 is used as OS as it is stable and supports more features and is more user-friendly.
•Database MySQL/No SQL is used as Database as it is easy to maintain and retrieve records by
simple queries which are in English language which are easy to understand, easy to write.
•Development tools and programming languages. JavaScript, HTML are used to write the WWE
code and develop Web Pages with JavaScript for styling work and PHP for server-side scripting.

2.5.2 HARDWARE REQUIREMENTS:

•Intel Atom(or) Intel Dual Core Processor higher by using the processor, we can keep on
developing our project without any worries.

•At least 512 MB RAM is required and 1.10 GB free space(or)higher.

•QR-code scanner required

2.6 Design and Implementation Constraints

Developers may implement the ATM System using a data store to curate data and template
information. All ATM System and administrative services must be available over a RESTful API.
The ATM System must be able to curate data collected in batches from the Industrial-Equipment
Network. At a predetermined time each calendar day, the ATM System must process all curated
Software Requirements Specification for <Project> Page 4

data and populate a list of available elements for query. Setup and maintenance of the ATM System
application are the responsibility of the customer. Setup and maintenance include: installation,
hosting, host-security configuration, and administration.

2.7 User Documentation

Any user of the software system is the target audience for user documentation generated about the
software system. A range of short document types (e.g., guidelines, tutorials, frequently asked
questions) in Hypertext Markup Language (HTML) and/or Portable Document Format (PDF)
format must describe the use of the software system.

3. External Interface Requirements

3.1 User Interfaces

<Describe the logical characteristics of each interface between the software product and the
users. This may include sample screen images, any GUI standards or product family style guides
that are to be followed, screen layout constraints, standard buttons and functions (e.g., help) that
will appear on every screen, keyboard shortcuts, error message display standards, and so on.
Define the software components for which a user interface is needed. Details of the user interface
design should be documented in a separate user interface specification.>

3.2 Hardware Interfaces

<Describe the logical and physical characteristics of each interface between the software product
and the hardware components of the system. This may include the supported device types, the
nature of the data and control interactions between the software and the hardware, and
communication protocols to be used.>

3.3 Software Interfaces

<Describe the connections between this product and other specific software components (name
and version), including databases, operating systems, tools, libraries, and integrated commercial
components. Identify the data items or messages coming into the system and going out and
describe the purpose of each. Describe the services needed and the nature of communications.
Refer to documents that describe detailed application programming interface protocols. Identify
data that will be shared across software components. If the data sharing mechanism must be
implemented in a specific way (for example, use of a global data area in a multitasking operating
system), specify this as an implementation constraint.>

3.4 Communications Interfaces

<Describe the requirements associated with any communications functions required by this
product, including e-mail, web browser, network server communications protocols, electronic
forms, and so on. Define any pertinent message formatting. Identify any communication
Software Requirements Specification for <Project> Page 5

standards that will be used, such as FTP or HTTP. Specify any communication security or
encryption issues, data transfer rates, and synchronization mechanisms.>

4. System Features

4.1 Fingerprint verification

4.1.1 Description and Priority

When ever user try to access system, they must have to verify them fingerprint after that they can
perform any operation on system which is available. This feature is under high priority because if
it’s failed than whole system goes down

4.1.2 Stimulus/Response Sequences

 Welcome Screen User Interface: The welcome screen will prompt the user to
choose either a Biometric Profile or ATM card account identification.

 Biometric Profile Selection: If user selects biometric profile they will be

prompted with a list of options including fingerprint, iris, voice or facial
recognition.

 Fingerprint Selection: User will be prompted to place their finger on the

scanner until the system has recognized their finger print.

4.1.3 Functional Requirements

 User Setup: In order to use the biometric system, the user will have to create a
biometric profile. Profile must be created at a bank location with a bank agent
during normal business hours. The profile will be stored on a dedicated biometric
database server.

4.2 ATM card selection

4.2.1 Description and Priority

Whenever user try to access system, they must have to verify them fingerprint after that they have
to card entered in machine and give a pin to system machine verify if and user could go through
further
Software Requirements Specification for <Project> Page 6

4.2.2 Stimulus/Response Sequences

 ATM card selection: User will be prompted to enter their ATM card and then remove.

 Successful Identification: The system will welcome the user by name that
matches the record on file and prompt to confirm it is their account.

 PIN: After user confirms that the correct account has been found the system will
prompt for a second form of identification, a PIN.

 Successful Logon Options: Upon successful logon user will be prompted to

choose a transaction. The options are balance inquiry, balance transfer,
withdraw cash and deposit.

4.1.3 Functional Requirements

 User Setup: In order to use the biometric system, the user will have to create a
biometric profile. Profile must be created at a bank location with a bank agent
during normal business hours. The profile will be stored on a dedicated biometric
database server.
 User must have physical atm card for perform operation on machine

5. Other Nonfunctional Requirements

5.1 Performance Requirements

 Session Initialization
 Power up ATM
 Verify ID/Card Selection
 Wait for Account holder
 Verify PIN
 Transaction Loop
 End Transaction
 Power off ATM

5.2 Safety Requirements

In case the customer forgets or loses PIN, the repair functionality helps by choosing “forgot PIN”
option in the main login window.
Software Requirements Specification for <Project> Page 7

 To avoid any data loss backups can be taken.

 While typing the PIN, if the caps lock is on it must be notified.

5.3 Security Requirements

This system is provided with authentication without which no user can pass. So only the legitimate
users are allowed to use the application. If the legitimate user’s share the authentication information
then the system is open to outsiders

5.3.1 Validation

Stakeholders include Lock Bank personnel and Tech Rep, Inc. This iterative
review resulted in an agreed upon list of customer requirements based on their
needs as below.
 Create Profile
 Session
 Transaction
 Withdrawal
 Transfer
 Deposit
 Inquiry
 PIN Error
 Power ATM
 Service ATM

5.3.2 Verification

Prior to releasing this document to the design and development teams

it has been reviewed to check the quality of requirements specifications. Tech
Rep has met with the development and design teams to go over the
requirements specification to ensure all requirements are clearly defined
before development begins.

5.4 Software Quality Attributes

Reliability: Good validations of user inputs will be done to avoid incorrect storage of records.
Maintainability: During the maintenance stage, SRS document can be referred for any validations.
Portability: This system can be easily viewed in any browser.
Flexibility: The system keeps on updating the data according to the transactions that takes place.
Timeless: The system carries out all the operations with consumption of very less time.
Software Requirements Specification for <Project> Page 8

Security: Security of the system is maintained d by giving access to only authenticated user id and
password.

5.5 Business Rules

All the rules for the design and development of the ATM system will be under the
jurisdiction

Appendix A: Glossary

 Definitions, Acronyms

Definitions

Biometrics The quantifiable data or metrics based on human

characteristics or traits.
Biometric A form of identification and access control using biometrics and
Identification a computer device.
Fingerprint Customer finger matching to the unique marks of their
verification fingerprint.
Voice Customer speaks a word or phrase into biometric device for
verification speech matching
Ocular scanning Analyzes the unique patterns and features of the eye.
Analyzes the overall facial structure, including measurements of
Facial
distances between eyes, nose, mouth, and jaw edges.
recognition

Customer An account holder with Lock Bank

Any individual with a vested interested in the Biometric ATM
Stakeholder
Banking System

1.1.1 Acronyms

ATM Automated Teller Machine

PIN Personal Identification Number
POS Point of Sale
AB Account Balance
AN Account Number
EFT Electronic Funds Transfer
Software Requirements Specification for <Project> Page 9

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: To Be Determined List

<Collect a numbered list of the TBD (to be determined) references that remain in the SRS so they
can be tracked to closure.>