Software Requirements Specification

(SRS)
• What is an SRS?
• What is the purpose of an SRS?
– Who reads the SRS?
– Who writes the SRS?
• What information is put into an SRS?

• What do you need to do for phase 1?

 What is an SRS?
• It is a document that you prepare:
– after customer gives you their system
specifications
– before you design the system
 What is the purpose of an SRS?
• “The SRS precisely defines the software product that
will be built.”
[readyset.tigris.org/nonav/templates/srs.html]

• The SRS is your “response to the customer’s System

Specification ... and tells a potential customer how you
intend to solve their problem.”
[CSE442 project description]

• “The [SRS] specifies the requirements … and the

methods to be used to ensure that each requirement has
been met.”
[source?]
 Purpose (continued)
• “An SRS is basically an organization’s understanding (in
writing) or 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.”
[www.techwr-l.com/techwhirl/magazine/writing/softwarerequirementspecs.html]

• “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”
[www.techwr-l.com/techwhirl/magazine/writing/softwarerequirementspecs.html]
 Purpose (continued)
1. “It provides feedback to the customer.”
2. “It decomposes the problem into component
parts.”
3. “It serves as an input to the design specification.”
4. “It serves as a product validation check.”

[www.techwr-l.com/techwhirl/magazine/writing/softwarerequirementspecs.html]
 Who reads the SRS?
The purpose of an SRS is to communicate
with the customer:

– The SRS must make clear to the customer

whether you have understood their system
specification correctly and completely. SRS is
written in plain language (not a formal
language).
 Who reads (continued)
The purpose of an SRS is to communicate
with the designers:

– The SRS must be detailed enough that the

designers can construct a design for the system
from this document.
 Who writes the SRS?
• Developers
– Architects
– Programmers
• Technical writers
• Customer may be involved
 Basis for User Manual
• The SRS can serve as the basis for a User
Manual for the software:
– Use case descriptions in SRS describe required
functionality of the system, from the
perspective of a user.
– This can be extended to become a description
of how to carry out these required tasks with
the finished system.
What information is put into an SRS?
• Varies between
– organizations
– customers
– projects
 IEEE Std 830-1998
Characteristics of a good SRS
1. Correct 6. Verifiable
2. Unambiguous 7. Modifiable
3. Complete 8. Traceable
4. Consistent
5. Ranked for
importance and/or
stability
• Correct: every requirement given in SRS is
a requirement of the software
• Unambiguous: every requirement has
exactly one interpretation
• Complete: includes all functional,
performance, design, external interface
requirements; definition of the response of
the software to all inputs (valid and invalid)
• Consistent: internal consistency
• Ranked importance: essential vs. desirable
• Verifiable: for each requirement there must
be a “finite cost-effective” method to verify
process with which a person or machine can
check that the software product meets the
requirement.”
• Modifiable: SRS must be structured to
permit effective modifications (e.g. don’t be
redundant, keep requirements separate)
• Traceable: origin of each requirement is
clear.
IEEE Std 830-1998: Parts of an SRS
• Introduction
– Purpose
• deliniate purpose of SRS
• intended audience for SRS
– Scope
• identify software to be produced by name
• explain what sw will (not) do
• describe application of sw (benefits, objectives)
IEEE Std 830-1998: Parts of an SRS
• Introduction (continued)
– Definitions/acronyms/abbreviations
– References
• list documents referenced by name and source
– Overview
• brief description of rest of SRS
• organization of SRS
 IEEE Std 830-1998: Parts of an SRS
• Overall description
– Product perspective (related products?)
• block diagram
• contraints
– system interfaces
» identify functionality that fulfills each system requirement
– user interfaces
– hardware interfaces
– software interfaces
» how sw interacts with supporting software (purpose, message
content and format)
» required versions
 IEEE Std 830-1998: Parts of an SRS
• Overall description (continued)
– Product perspective
• contraints
– communications interfaces
» network protocols
– memory
» requirements/limits on primary and secondary memory
– operations
» modes of operation
» interactive vs. unattended operation
» backup & recovery
– site adaptation requirement
 IEEE Std 830-1998: Parts of an SRS
• Overall description (continued)
– Product functions
• summary of major functions sw will perform
– Intended user characteristics
• educational level
• experience
• technical expertise
 IEEE Std 830-1998: Parts of an SRS
• Overall description (continued)
– Constraints (limitations of developer options)
• regulatory policies
• hardware limitations (e.g. signal timing requirements)
• interfaces to other applications
• parallel operation
• audit functions
• control functions
• higher-order language requirements
• reliability requirements
• criticality of the application
• safety and security considertations
 IEEE Std 830-1998: Parts of an SRS
• Overall description (continued)
– Assumptions and dependencies
• e.g. specific OS available on HW
– Apportioning of requirements
• requirements that may be delayed to future versions
 IEEE Std 830-1998: Parts of an SRS
• Specific requirements
– External interfaces
– Functions
– Performance requirements
– Logical database requirements
– Design constraints
• Standards compliance
 IEEE Std 830-1998: Parts of an SRS
• Specific requirements (continued)
– Software system attributes
• Reliability
• Availability
• Security
• Maintainability
• Portability
 IEEE Std 830-1998: Parts of an SRS
• Specific requirements (continued)
– Organizing the specific requirements
• System mode
• User class
• Objects
• Feature
• Stimulus
• Response
• Functional hierarchy
– Additional comments
 IEEE Std 830-1998: Parts of an SRS
• Supporting Information
– Table of contents
– Index
– Appendixes