EXPERIMENT NO.

1.1 Title: Software Requirement Specification (SRS).

1.2 Problem Statement: Write Software Requirement Specification (SRS) document for any
system.

1.3 Prerequisites: Fundamentals of Computer Programming, Object Oriented Programming.

1.4 Theory:
An SRS is basically an organization's understanding (in writing) of a customer or potential
client's system requirements and dependencies at a particular point in time (usually) prior to
any actual design or development work. It's a two-way insurance policy that assures that both
the client and the organization understand the other's requirements from that perspective at a
given point in time.
The SRS also functions as a blueprint for completing a project with as little cost growth as
possible. The SRS is often referred to as the "parent" document because all subsequent project
management documents, such as design specifications, statements of work, software
architecture specifications, testing and validation plans, and documentation plans, are related
to it.

 A well-designed, well-written SRS accomplishes four major goals:

1. It provides feedback to the customer.
An SRS is the customer's assurance that the development organization understands the
issues or problems to be solved and the software behavior necessary to address those
problems. Therefore, the SRS should be written in natural language (versus a formal
language, explained later in this article), in an unambiguous manner that may also include
charts, tables, data flow diagrams, decision tables, and so on.
2. It decomposes the problem into component parts.
The simple act of writing down software requirements in a well-designed format organizes
information, places borders around the problem, solidifies ideas, and helps break down the
problem into its component parts in an orderly fashion.
3. It serves as an input to the design specification.
As mentioned previously, the SRS serves as the parent document to subsequent
documents, such as the software design specification and statement of work. Therefore, the
SRS must contain sufficient detail in the functional system requirements so that a design
solution can be devised.
4. It serves as a product validation check.
The SRS also serves as the parent document for testing and validation strategies that will
be applied to the requirements for verification.

 Characteristics of a good SRS An SRS should be:

a) Correct
b) Unambiguous
c) Complete
d) Consistent
e) Ranked for importance and/or stability
f) Verifiable
g) Modifiable
h) Traceable

a. Correct:
This is like motherhood and apple pie. Of course you want the specification to be correct.
No one writes a specification that they know is incorrect. We like to say - "Correct and
Ever Correcting." The discipline is keeping the specification up to date when you find
things that are not correct.
b. Unambiguous:
An SRS is unambiguous if, and only if, every requirement stated therein has only one
interpretation. Again, easier said than done. Spending time on this area prior to
releasing the SRS can be a waste of time. But as you find ambiguities - fix them.
c. Complete:
A simple judgement of this is that it should be all that is needed by the software
designers to create the software.
d. Consistent:
The SRS should be consistent within itself and consistent with its reference documents.
If you call an input "Start and Stop" in one place, don't call it "Start/Stop" in another.
e. Ranked for Importance:
Very often a new system has requirements that are really marketing wish lists. Some
may not be achievable. It is useful to provide this information in the SRS.
f. Verifiable:
Don't put in requirements like - "It should provide the user a fast response." Another of
my favorites is - "The system should never crash." Instead, provide a quantitative
requirement like: "Every key stroke should provide a user response within 100
milliseconds."
g. Modifiable:
Having the same requirement in more than one place may not be wrong - but tends to
make the document not maintainable.
h. Traceable:
Often, this is not important in a non-politicized environment. However, in most
organizations, it is sometimes useful to connect the requirements in the SRS to a higher-
level document.
 Stop here…….

Note: Till here all students please

write as it is mentioned in
document.
Next your own SRS format and
SRS Example will come.
At last, again conclusion is given.
That you need to write as it is.
Read then write properly.

Below given SRS you can refer

(During your Final Year Project.
In detail it is provided.)
 A sample of basic SRS Outline:

1. Introduction
1.1 Purpose
1.2 Document conventions
1.3 Intended audience
1.4 Additional information
1.5 Contact information/SRS team members
1.6 References

2. Overall Description
2.1 Product perspective
2.2 Product functions
2.3 User classes and characteristics
2.4 Operating environment
2.5 User environment
2.6 Design/implementation constraints
2.7 Assumptions and dependencies

3. External Interface Requirements

3.1 User interfaces
3.2 Hardware interfaces
3.3 Software interfaces
3.4 Communication protocols and interfaces

4. System Features
4.1 System feature A
4.1.1 Description and priority
4.1.2 Action/result
4.1.3 Functional requirements
4.2 System feature B
5. Other Nonfunctional Requirements
5.1 Performance requirements
5.2 Safety requirements
5.3 Security requirements
5.4 Software quality attributes
5.5 Project documentation
5.6 User documentation

6. Other Requirements

Appendix A: Terminology/Glossary/Definitions list

Appendix B: To be determined
 SAMPLE SRS (For Reference)
Note: Students can select any topic and any SRS format according to
their choice.

SRS EXAMPLE FOR AUTOMATED TELLER MACHINE (ATM)

1. Introduction:
The software ATMExcl 3.0TM version1.0 is to be developed for Automated Teller Machines
(ATM). An automated teller machine (ATM) is a computerized telecommunications device
that provides a financial institution's customers with a secure method of performing financial
transactions, in a public space without the need for a human bank teller. Through ATMExcl
3.0TM ,customers interact with a user-friendly interface that enables them to access their bank
accounts and perform various transactions.

1.1 Purpose
This SRS defines External Interface, Performance and Software System Attributes
requirements of ATMExcl 3.0TM. This document is intended for the following group of
people:
 Developers for the purpose of maintenance and new releases of the software.
 Management of the bank.
 Documentation writers.
 Testers.

1.2 Scope
This document applies to Automated Teller Machine software ATM 3.0TM. This software
facilitates the user to perform various transactions in his account without going to the bank.
This software offers benefits such cash withdrawals, balance transfers, deposits, inquiries,
 credit card advances and other banking related operations for customers. It also allows the
administrator to fix the tariffs and rules as and when required.
The software takes as input the login Id and the bank account number of the user for login
purposes. The outputs then comprise of an interactive display that lets the user select the
desirable function that he wants to perform. The software is expected to be completed in the
duration of six months and the estimated cost is Rs18 lakhs.

1.3 Definitions, Acronyms, and Abbreviations.

1.4 References
The references for the above software are as follows:
i. www.google.co.in
ii. www.winkipedia.com
iii. IEEE. Software Requirements Specification Std. 830-1993.
iv. Chevy Chase Bank, UMBC Branch.
v. Russell C. Bjork Requirements Statement for Example ATM System. Online.

URL: http://www.math-cs.gordon.edu/local/courses/cs211/ATMExample

1.5 Overview
Section 1.0 discusses the purpose and scope of the software.
Section 2.0 describes the overall functionalities and constraints of the software and user
characteristics.
Section 3.0 details all the requirements needed to design the software.

2. The Overall Description

2.1 Product Perspective
 The ATM is a single functional unit consisting of various sub-components.
 This software allows the user to access their bank accounts remotely through an ATM
without any aid from a human bank teller.
 This software also allows them to perform various other functions apart from just accessing
their bank account such as mobile bill clearings etc.
 Some of its hardware components are cassettes, memory, drives, dispensers i.e. for receipts
and cash, a card reader, printer, switches, a console, a telephone dialer port, a networking
port and disks.
 The ATM communicates with the bank‘s central server through a dial-up communication
link.
  The Memory of the system shall be 20MB.
 The Cassette capacity shall be at least 2000 notes

2.2 Product Functions

The major functions that ATMExcl 3.0TM performs are described as follows: -

Language Selection: - After the user has logged in, the display provides him with a list of
languages from which he can select anyone to interact with the machine throughout that
session. After the language selection the user is prompted with an option that whether he wants
the selected language to be fixed for future use so that he is not offered with the language
selection menu in future thus making the transaction a bit faster. The user also has the freedom
to switch to a different language mentioned in the list in between that session.

Account Maintenance: - The various functions that a user can perform with his account are
as follows: -
 Account Type: -The user has the freedom to select his account type to which all the
transactions are made, i.e. he can select whether the account is a current account or
savings account etc.
 Withdrawal/Deposit: The software allows the user to select the kind of operation to be
performed, i.e. whether he wants to withdraw or deposit the money.
 Amount: - The amount to be withdrawn or deposited is then mentioned by the user.
 Denominations: - The user is also provided with the facility to mention the required
denominations. Once he enters his requirements the machine goes through its
calculations based on current resources to check whether it is possible or not. If yes,
the amount is given to the user otherwise other possible alternatives are displayed.
 Money Deposition: - Money deposit shall be done with an envelope. After typing the
amount to be deposited and verification of the same, the customer must insert the
envelope in the depositary.
 Balance Transfer: - Balance transfer shall be facilitated between either of two accounts
linked to the card, for example saving and checking account.
  Balance Enquiry: - Balance enquiry for any account linked to the card shall be
facilitated.

Billing: - Any transaction shall be recorded in the form of a receipt and the same will be
dispensed to the customer. The billing procedures are handled by the billing module that
enables user to choose whether he wants the printed statement of the transaction or just the
updating in his account.

Cancelling: - The customer shall abort a transaction with the press of a Cancel key. For
example, on entering the wrong deposit amount. In addition, the user can also cancel the entire
session by pressing the abort key and can start a fresh session all over again.

Map locating other machines: - The machine also has a facility for displaying the map that
marks the locations of other ATM machines of the same bank in the entire city.

Mobile Bills Clearings: - The machine also allows the user to clear off his pending mobile
bills there only if the name of his operator is mentioned there in the list. The machine displays
the list of the companies supported by that bank to the user.

2.3 User Characteristics

There are different kinds of users that will be interacting with the system. The intended user of the
software are as follows: -

User A: A novice ATM customer. This user has little or no experience with electronic means
of account management and is not a frequent user of the product. User A will find the product
easy to use due to simple explanatory screens for each ATM function. He is also assisted by
an interactive teaching mechanism at every step of the transaction, both with the help of visual
and audio help sessions.
 User B: An experienced customer. This user has used an ATM on several occasions before
and does most of his account management through the ATM. There is only a little help session
that too at the beginning of the session thus making the transaction procedure faster.

Maintenance Personnel: A bank employee. This user is familiar with the functioning of the
ATM. This user oversees storing cash into the ATM vault and repairing the ATM in case of
malfunction. This user is presented with a different display when he logs in with the
administrator’s password and is provided with options different from that of normal user. He
has the authority to change or restrict various features provided by the software in situations
of repair.

2.4 Constraints

The major constraints that the project has are as follows: -

 The ATM must service at most one person at a time.
 The number of invalid pin entries attempted must not exceed three. After three
unsuccessful login attempts, the card is seized/blocked and needs to be unlocked by the
bank.
 Simultaneous access to an account through both the ATM and the bank is not
supported.
 The minimum amount of money a user can withdraw is Rs 100/- and the maximum
amount of money a user can withdraw in a session is Rs.10,000/- and the maximum
amount he can withdraw in a day is Rs 20,000/
 Before the transaction is carried out, a check is performed by the machine to ensure
that a minimum amount of Rs 1000/- is left in the user‘s account after the withdrawal
failing which the withdrawal is denied.
 The minimum amount a user can deposit is Rs 100/- and the maximum amount he can
deposit is Rs 10,000/-.
 A user can select only that cellular operator for mobile bill clearings that is supported
by the bank.
  The software requires a minimum memory of 20GB.
 The database used should be Oracle7.0.
 There shall be a printer installed with the machine to provide the user with the printed
statement of the transaction.
 For voice interactions, speakers should also be there to accompany the machine.

2.5 Assumptions and Dependencies

The requirements stated in the SRS could be affected by the following factors:
 One major dependency that the project might face is the changes that need to be incorporated
with the changes in the bank policies regarding different services. As the policies change the
system needs to be updated with the same immediately. A delay in doing the same will result
in a tremendous loss to the bank. So, this should be changed as and when required by the
developer.
 Another constraint relating to the operating environment is that we are specific to Oracle
Database.
 The project could be largely affected if some amount is withdrawn from the user‘s account
from the bank at the same time when someone is accessing that account through the ATM
machine. Such a condition shall be taken care of.
 At this stage no quantitative measures are imposed on the software in terms of speed and
memory although it is implied that all functions will be optimized with respect to speed and
memory.

3. External Interface Requirements

3.1.1 User Interface Requirements The interface provided to the user should be a very user-friendly
one and it should provide optional interactive help for each of the services listed. The interface
provided is a menu driven one and the following screens will be provided: -
1. A login screen is provided in the beginning for entering the required username/pin no. and
account number.
2. An unsuccessful login leads to a reattempt (maximum three) screen for again entering the
same information. The successful login leads to a screen displaying a list of supported
languages from which a user can select anyone.
3. In the case of administrator, a screen will be shown having options to reboot the system,
shut down system, block system, disable any service.
4. In case of reboot/ shut down, a screen is displayed to confirm the user‘s will reboot and also
allow the user to take any backup if needed.
5. In the case of blocking system, a screen is provided asking for the card no. By entering the
card no of a particular user, system access can be blocked for him.
6. Administrator is also provided with a screen that enables him to block any service provided
to the user by entering the name of the service or by selecting it from the list displayed.
7. After login, a screen with several options is then shown to the user. It contains all the options
along with their brief description to enable the user to understand their functioning and select
the proper option.
8. A screen will be provided for the user to check his account balance.
9. A screen will be provided that displays the location of all other ATMs of the same bank
elsewhere in the city.
10. A screen will be provided for the user to perform various transactions in his account.

The following reports will be generated after each session dealt with in the machine: -
1. The login time and logout time along with the user‘s pin no and account number is registered
in the bank‘s database.
2. The ATM ‘s branch ID through which the session is established is also noted down in the
bank‘s database.
3. Various changes in the user‘s account after the transactions, if any, are reported in the
database.
4. A printed statement is generated for the user displaying all the transactions he performed.
 Other various user interface requirements that need to be fulfilled are as follows: -

 The display screen shall be of 10" VGA color type.

 The display screen shall have 256 color resolution.
 The display screen shall also support touchscreen facility.
 The speakers shall support Yamaha codecs.
 The keypad shall consist of 16 tactile keys.
 There shall be 8 tactile function keys.
 The keyboard will be weather resistant.
 The transaction receipt shall be 3.1" × 6".
 The statement receipt shall be 4.2" × 12".
 The deposit envelopes shall be 9" long and 4" wide.

3.1.2 Hardware Interface Requirement

There are various hardware components with which the machine is required to interact.
Various hardware interface requirements that need to be fulfilled for successful functioning of
the software are as follows: -
 The ATM power supply shall have a 10/220 V AC manual switch.
 The ATM card should have the following physical dimensions: -
o Width - 85.47mm-85.72mm
o Height - 53.92mm-54.03mm
o Thickness - 0.76mm+0.08mm
 The card reader shall be a magnetic stripe reader
 The card reader shall have a Smart card option.
 The slot for a card in the card reader may include an extra indentation for
the embossed area of the card. In effect it acts as a polarization key and
may be used to aid the correct insertion orientation of the card. This is an
additional characteristic to the magnetic field sensor which operates off
the magnetic stripe and is used to open a mechanical gate on devices such
 as ATMs.
 There shall be a 40-column dot matrix receipt printer.
 There shall be a 40-column dot matrix statement printer.
 The receipt dispenser shall be a maximum of 4" width and 0.5" thickness.
 The statement dispenser shall be a maximum of 5" width and 0.5"
thickness.
 The envelope depository shall be a maximum of 4.5" width, 10" length
and 0.5" thickness.
 Screen resolution of at least 800X600-required for proper and complete
viewing of screens. Higher resolution would not be a problem.

3.1.3 Software Interface Requirements

To perform various functions, this software needs to interact with various other software’s. So
there are certain software interface requirements that need to be fulfilled which are listed as
follows: -
 The transaction management software used to manage the transaction and
keep track of resources shall be BMS version 2.0.
 The card management software used to verify pin no and login shall be
CMS version 3.0.
 Yamaha codecs 367/98 for active speakers.
 The database used to keep record of user accounts shall be Oracle
version7.0.

3.1.4 Communication Interface Requirements

The machine needs to communicate with the main branch for each session for various functions
such as login verification, account access etc. so the following are the various communication
interface requirements that are needed to be fulfilled to run the software successfully: -
  The system will employ dial-up POS with the central server for low cost
communication.
 The communication protocol used shall be TCP/IP.
 Protocol used for data transfer shall be File Transfer Protocol. (FTP)

4. System Features

1. Remote Banking and Account Management

Description
The system is designed to provide the user with the facility of remote banking and
perform various other functions at an interface without any aid of human bank teller.

The functioning of the system shall be as follows: -

 At the start, the user is provided with a log in screen, and he is required to Enter his PIN
NO. and Account details which are then verified by the machine. In case of an unsuccessful
attempt a user is asked again for his credentials, but the maximum number of attempts
given to the user is limited to 3 only, failing which his card is blocked and need to be
unblocked by the bank for any future use.
 After a successful log in, the user is presented with a list of languages. The user can select
anyone in the list for interaction with the machine for the entire session.
 After the language selection the user is also asked whether he wants to fix that language
for future use also so that he is never asked for language in future. In addition, there is also
a facility for the user to switch to any other language during that session.
 After the language selection, the user is directed towards a main page that displays a set of
options/services along with their brief description, enabling the user to understand their
functioning. The user can select any of the listed options and can continue with the
transaction.
 The machine also provides the user with several miscellaneous services such as:
  The machine lists a set of operators that are supported by the bank. A user can clear off his
pending mobile phone bills be selecting his operator. The machine also has the facility to
display a map that marks the location of other ATMs of the same bank in the city. This
may help the user to look for the ATM nearest to his destination.
 At any moment if the user wants to abort the transaction, he is provided with an option to
cancel it. Just by pressing the abort button he can cancel all the changes made so far and
can begin a new transaction.
 After the user is finished with his work, for security purposes, he is required to log out and
then take his card out of the slot.

Validity Checks
To gain access to the system, the user is required to enter his/her correct user id/pin no and account
no failing which his card may be blocked. The user can access only one account at a time and can
enter only one account no.
Also, if the user is an administrator, he is required to enter his login id in order to access and change
the facilities provided by the system.

Sequencing Information
The information about the users and their account should be entered into the database prior to any
of the transactions and the backup be maintained for all account information.

Error Handling/ Response to Abnormal Situations

If any of the above validation/sequencing flow does not hold true, appropriate error messages will
be prompted to the user for doing the needful.

2. Receipt Generation
After each transaction user has performed, a receipt is generated that contains all the
information about the transaction. The format of the generated receipt is as shown below: -
5. Other Nonfunctional Requirements
5.1 Performance Requirements
The following list provides a summary of the performance requirements for the software:
5.1.1 Capacity
The ATM shall provide customers with a 24-hour service.

5.1.2 Dynamic requirements

 The card verification time must not exceed 0.8 Second under normal server workload and 1
Second under peak server workload.
 The pin number verification time must not exceed 0.3 Second under normal server workload
and 0.5 Second under peak server workload.
 Account balance display time must not exceed 2 Second under normal server workload and
3 Second under peak server workload.
 Account balance transfer time must not exceed 3 Second under normal server workload and
4 Second under peak server workload.
 Cash withdrawal transaction time must not exceed 4 Second under normal server workload
and 5 Second under peak server workload.
 Deposit transaction time after insertion of the deposit envelope must not exceed 5 Second
under normal server workload and 6 Second under peak server workload.
 Receipt printing time after must not exceed 3 Second under normal server and peak server
workload.
 Touch screen and button response time must not exceed 5000ms.
 Credit card advance time must not exceed 6 Second under normal traffic and server and
peak traffic and server workload.

5.1.3 Quality
The primary objective is to produce quality software. As the quality of a piece of software is
difficult to measure quantitatively, the following guidelines will be used when judging the
quality of the software:
 1. Consistency – All code will be consistent with respect to the style. (This is implied when
adhering to the standard).
2. Test cases – All functionality will be thoroughly tested.

5.2 Software System Attributes

5.2.1 Reliability
 The data communication protocol shall be such that it ensures reliability and quality of data
and voice transmission in a mobile environment. For example, CDMA.
 The memory system shall be of non-volatile type.

5.2.2 Availability
 The product will have a backup power supply in case of power failures.
 Any abnormal operations shall result in the shutting down of the system.
 After abnormal shutdown of the ATM, the system shall have to be manually restarted by a
maintenance personnel.
 There should be no inconsistency introduced in the account during whose transaction the
system is abnormally shut down.

5.2.3 Security
 The system shall be compatible with AIMS security standards.
 The system shall have two levels of security i.e. ATM card and pin verification, both
authenticated by the CMS software.
 The Encryption standard used during pin transmission shall be triple DES.
 The password shall be 6-14 characters long.
 Passwords shall not contain the names of customers as they are easy to hack.
 Passwords can contain digits, hyphens and underscores.
 User should be provided with only three attempts for login failing which his card needs to
be blocked.
 There shall be a security camera installed near the ATM.
 There shall be a secure cash vault with a combination locking system.
  The product cabinet cover shall be manufactured using Fiber glass for security purposes.

5.2.4 Maintainability
 The system components i.e. modem, memory, disk, drives shall be easily serviceable
without requiring access to the vault.
 The system should have the mechanism of self-monitoring periodically to detect any fault.
 The system should inform the main branch automatically as soon as it detects any error. The
kind of fault and the problem being encountered should also be mentioned by the system
automatically.

5.3 Business Rules

The business rules for the software are as follows:

 The Administrator has the authority to fix the rules and regulations and to set or update
the policies as and when required.
 The staff at the bank performs the following:
a. Making the entries in the system regarding all the details of the bank account of the user.
b. Keeping the bank account of the user updated as soon as changes are encountered so that
the data is in a consistent state.
c. Blocking or seizing the account of user on discovery of any illegal transaction.
d. Unblocking of ATM card that got blocked due to more than three unsuccessful login
attempts.
e. Blocking of a lost/stolen ATM card on complaint of the user, only if he presents his
verification and a FIR filed for that case.
f. Constantly monitor all the ATMs in the city to check whether any one of them is
encountering any fault.
g. Immediately correct any fault discovered in any of the ATM.
h. Maintain the backup of all the accounts for reliability purposes.
i. Rollback all the changes made in an account during whose transaction an ATM got abnormal
shutdown.
  In case of loss of the ATM card. The user has to lodge a First Investigation Report (FIR)
and present its one copy to bank officials for card blocking purposes.
 A log of the following annexures is generated by the system:
 User bank account details.
 Updations made in the user account along with date, time and the changes made.
 Schedule of fixed assets.

6. Other Requirements:
None

Appendix A: Glossary
AIMS - ATM Information Management System.
ATM - An unattended electronic machine in a public place, connected to a data system and
related equipment and activated by a bank customer to obtain cash withdrawals and other
banking services.
Braille- A system of writing and printing for blind or visually impaired people, in . varied
arrangements of raised dots representing letters and numerals are identified by touch.
CDMA - Code Division Multiple Access, a reliable data communication
protocol.
CMS - Card Management Software developed by KPM Bank.
Dial-Up - A message format for low-cost communications.
Internet - An interconnected system of networks that connects computers around the world via
the TCP/IP protocol.
Smart Card - Card without hardware which stores the user‘s private keys within a tamper proof
software guard.
Tactile Keyboard- Special keyboard designed to aid the visually impaired.
TCP/IP - Transmission Control Protocol/Internet Protocol.

1.5 Conclusion: The SRS was made successfully by following the steps described above.