Establishing traceability between related items, and

" Change control.

5.7
Software Requirements Specifications (SRS)
Software
RequirementsSpecifications (SRS) is basically an organization's understanding in
So of a customer or potential client's system requirements and dependencies at a
particular point in time prior to any actual design or development takes place.
IHs atwo-way insurance policy that asures that both the client and the organization
understand the other's requirements from that perspective at a given point in time.
57.1 SRS Document

cument itself states in precise and explicit language those functions and capabilities
as states any required constraints by which the
asoftware system must provide, as well
system must abide.

The SRS also functions as a blueprint for completing a project with as little cost growth
[Link] SRS is often referred to as the "parent document" because all subsequent
ooiect management documents, such as design specifications, statements of work, software
rchitecture specifications, testing and validation plans, and documentation plans, are related
to it.

It's important to note that an SRS contains functional and non-functional requirements
only: it doesn't offer design suggestions, possible solutions to technology or business
issues, or any other information other than what the development team understands the
customer's system requirements to be.

5.7.2 Goals of SRS Document

[Link], well-written SRS document accomplishes the following four major goals:
Feedback to Customer
" SRS document provides a feedback to the customer.
" It 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.
 138 Software Engine
natural language, in an
Therefore, the SRS should be written in
that may also include charts, tables, dala
flow diagrams, decision unambitalblges,uous
and
Problem Decomposition
" SRS document decomposes the problem into component parts.
The simple act of writing down software requirements in a
organizes information, places borders around the problem, well-designed fur
solidifies
helps break down the problem into its component parts in an
orderly fashideoan.s,
Input to Design Specification
SRS document serves as an input to the design specification.
The SRS also serves as the parent document to subsequent documents,
software design specification and statement of work. Such as he
Therefore, the SRS must contain sufficient detail in the functional system
so that a design solution can be devised.
Production Validation Check
requirement
" SRS document serves as a product validation check.
The SRS also serves as the parent document for
testing and validation
will be applied to the requirements for verification. strategies tha
5.7.3 Qualities/Characteristics of a Good SRS
Document
The following are the quality characteristics of
a good SRS document:
Complete
" SRS should be cornplete.
" SRS defines precisely all
the live situations that will be
capability to successfully address them. encountered and the system's
Consistent
SRS should be consistent.
" SRS capability functions and performance levels are
quality features (security, reliability,
etc.) do
compatible, and the required
Accurate not negate those capability functions.
SRS precisely defines the
as how it system's capability in a real-world
interfaces and interacts with it. environment, as Wel
This aspect of requirements is
a significant problem
Modifiable area for many SRSS.
" The logical,
hierarchical
modifications and that to0 structure of the SRS should
with a greater ease. facilitate any necessa
 Engineering
and Specifications 139
Requirements

Ranked requircments of an SRS are hierarchically arranged according to stability.

Jndividual
perceived case/difficulty of implementation, or other parameter that helps
sccurity,
of that and subsequent documents.
in
the design

Tistable

SRS
must be stated in such a manner that unambiguous assessment criteria can be
. SRS itself
derived from the

Ihaceable

reguirement in SRS must be uniquely identified to a source (e.g. use case,

governmernt requirement, industry standard, etc.)
Unambiguous

SRS must contain requirements statements that can be interpreted in one way only
"
i.e., it
should be unambiguous.
is another area that creates significant problems for SRS development because
of the use of natural language.

Valid
Avalid SRS is one in which all parties and project participants can understand,

analyze, accept, or approve it.

This is one of the main reasons SRSs are written using natural language.
Verifiable
Averifiable SRS is consistent from one level of abstraction to another.
Most attributes of a specification are subjective and a conclusive assessment of
auality requires a technical review by domain experts.
Iising indicators of strength and weakness provide some evidence that preferred
attributes are or are not present.

5.74 Who Writes SRS Document?

Usually, systems architects and programmers write SRSs with little, if any, help from the
technical communications organization. And when that assistance is provided, it's often
limited to an edit of the final draft just prior to going out the door.
In short, a requirements-gathering team consisting solely of programmers, product
marketers, systems analysts/architects, and a project manager runs the risk of creating a SRS
document that may be too heavily loaded with technology-focused or marketing-focused
ISSues.

With the increased complexity of the SRS, it is better to involve the technical writers
ne process of writing SRS document. The presence of a technical writer on the team
helps place at the core of the project those user or customer requirements that provide more
al overall balance to the design of the SRS, product, and documentation.
 140

5.7.5 Benefits of Involving Technical Writers in SRS Writing

software Enginea,.
Having technical writers involved throughout the entire SRS development
sCveral bencfits: process
Can
" Technical writers are skilled information gatherers, ideal
for eliciting
Customer requirements. The presence of a technical writer on theand
gathering team helps balance the type and amount of
customers, which can help improve the SRS. information arequirtriecmeng,
ulatiny
Technical writers can better assess and plan
extracted
fro
customer document needs. Working on documentation projects an
SRSS provides technical
opportunity for learning about customer needs better me
writersee
development process. firsthand-early in the
Technical writers know how to prodC,
user or customer regarding ease determine the questions that are of
that knowledge and of use and usability. Concern to
apply it not only to the Technical writers can the
development, but also to user interface specification and
Technical writers involved early
and often
development.
in the process, can
documentation
resource throughout the process, become an informatie
the process. rather than an information
gatherer at the end ot
5.7.6 Uses of SRS
Document
The following are few
major uses of SRS
Project managers base documents:
On it. their plans and estimates of
schedule, effort and resources
Development team needs it to
The testing group develop product.
needs it to generate test
behaviour. plans based on the
" The
maintenance and product described external
product is supposed to do. support staff need it to
The publications understand what the software
group writes
Customers rely on it to know documentation, manuals, etc.
Training personnel can use what product they from it.
it to help develop can expect.
5.7.7 Components of educational material for software
SRS development SRS Document product.
will be a
into a SRS
Document. collaborative effort for a particular
Several
following nine components standards organizations project and ultimately
1. Interfaces
that must be including
addressed when designing IEEE have identifiedresults
3. Performance Levels and writing SRS: the
2. Functional Capabilities
5. Safety 4. Data Structures/Elements
7. Security/Privacy 6. Reliability
9. Constraints and 8. Quality
Limitations
 141
Engineerng
and Specifications
Aoquirements
Document
Structure
SRS docunent is shown in Table 5.1. This example is an adaptation
S R S

578
of a
Standard 830-1998.
structure

IEEE
The
basic

extension of the
and TABLE 5.1: Sample of aBaslc SRS Outline
1. Introduction

1.1 Purpose

1 2D o c u m e n t conventions

1.3 Intended audience

1 4Additional information

Contact
information/SRS team members
1.5
1 . 6 R e f e r e n c e s

2. Overall Description

2.1 Product perspective

2.2 Product functions

characteristics
and
93 User classes
2.4 Operating environment

2.5 User environment

26 Design/implemnentation constraints
dependencies
Assumptions and
2.7
Requirements

3. Externai Interface
3.1 U s e r i n t e r f a c e s

3.2 Hardware interfaces

3.3 Software interfaces

protocols and interfaces

3.4 Communication
4. System Features

feature A
4.1 System priority
4.1.1 Description and
4.1.2 Action/resut

4.1.3 Functional requirements

feature B
4.2 System
Requirements
5. Other Non-functional
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
Terminology/Glossary/Definitions list
Appendix A:
Appendix B: To be determined
 Software Engjitay
142

The casicst Template

way of writing an SRS document is to use SRS template. Most of the siltN
5.7.9 SRS Docurent
devclopmcnt organisations develop their own SRS templates, which can serve ihe pur
development.
software projects undertaken for
for all thc Table s
Template structure is described in
One such SRS Document
Document Template
TABLE 5.2: SRS

Document Title
Author(s)
Affiliation
Address
Date
Document Version Control Information

1. INTRODUCTION
1.1 Purpose of this document
Describes the purpose of the document, and the intended audience.
1.2 Scope of this document
Describes the scope of this requirerments definition effort. Introduces the requirements elicito.
team, including users, customers, system engineers, and developers.
This section also derails any constraints that were placed upon
the requirements elicital:.
process, such as schedules, costs, or the software
requirements. engineering environment used to develon
1.3 Overview
Provides a brief overview of the product defined as a
1.4 Business Context
result of the requirements elicitation process
Provides an overview of the
This overview should include business organization
the business's missionsponsoring the development of this product.
or goals. statement and its organizational objectives
2. GENERAL DESCRIPTION
2.1 Product Functions
Describes the general functionality of
2.2 Similar System
the product, which will be
Information discussed in more detail below.
Describes the relationship of this
intended to be stand-alone, or product with any other products.
section discusses the else used as a
relationship of this
component of a largerSpecifies
product.
if this product is
If the latter, this
2.3 User Characteristics product to ihe larger
product.
Describes the
systems and thefeatures of the user
application community, including their
2.4 User Problem domain. expected expertise with softwale
Statement
This section describes
the essential
problem(s) currently confronted
by the user communily.
 Engineering and Specifications 143

25 User Objectives

describes the set of objectives and requirements for the system from the user s
perspective. It may include a "wish list" of desirable characteristics, along with more feasible
This
s e c t i o n

in line with the business objectives.

solutions
that are
2.6 General Constraints

constraints
Lists general co placed upon the design team, including speed requirements, industry
platforms,
hardware
and so forth.
protocols,

s FUNCTIONAL REQUIREMENTS

requirements in ranked order. Functional requirements describe the

lists the functional
T h i ss e c t i o n

effects of a software system, in other words, what the system must accomplish. Other kinds
possible
requirements (such as interface requirements, performance requirements, or reliability requirements)
system accomplishes its functional requirements. Each functional requirement
of how the
specified in
d e s c r i b e

a format similar to the following:

be
should

imperative
sentence
stating highest ranked functional requirement.
Short,

1. 1 . D e s c r i p t i o n

requirement.
Afull description of the
2. C r i t i c a l i t y

Describes
how essential this requirement is to the overall system.
9 Technical issues
Describes any design or implemerntation issues involved in satisfying this requirement.
schedule
and
4. Cost absolute costs associated with this issue.
Describes the relative or

5. Risks
which this requirement might not able to be satisfied, and
Describes the circumstances under
taken to reduce the probability of this occurrence.
what actions can be
requirements
6. Dependencies with other requirements.
Describes interactions with other
appropriate
7....others as
ranked requirement
<Name of second highest
And so forth.
4 INTERFACE REQUIREMENTS

other software products or users for input or

This section describes how the software interfaces with
routines, token streams, shared memory, data
output, Examples of such interfaces include library
streams, and so forth.
4.1 User Interfaces
Describes how this product interfaces with the user.
4.1.1 GUI set of
present. This section should include a
Describes the graphical user interface if
interface features.
Screen dumps or mock-ups to illustrate user should be
menu-driven, a description of all menus and their components
ie system is
provided.
 144

4.1.2 CLI software Engin

Describes the command-line interface (or command-user
each command, a description of all arguments and example interface,
values CUI,
be provided. and
4.1.3 API
Describes the application programming interface, if present.
invocafioprnesesr
function, the name, arguments, return values, examples of For each
other functions should be provided. invocation, and public
4.1.4 Diagnostics or ROM
Desciibes how to obtain debugging information or
4.2 Hardware Interfaces other diagnostic data
Describes interfaces to hardware devices.
4.3 Communications Interfaces
Describes network interfaces.
4.4 Software Interfaces
Describes any renmaining software interfaces
5. PERFORMANCE REQUIREMENTS not included above..
Specifies speed and memory
6. DESIGN CONSTRAINTS requirements.
Specifies any constraints for the
6.1 Standards Compliance design team using this document.
6.2 Hardware Limitations
Others as appropriate
. OTHER
NON-FUNCTIONAL
Specifies any other particular ATTRIBUTES
below. non-functional attributes required by the
7.1 Security system. Examples are provided
7.2 Binary Compatibility
7.3 Reliability
7.4 Maintainability
.5 Portability
6 Extensibility
7Reusability
Application Affinity/Compatibility
Resource Utilization
Serviceability
Others as appropriate
LIMINARY OBJECT-ORIENTED
section presents a list of the DOMAIN ANALYSIS
its requirements. The fundamental objects that must be
purpose modelled within the system to
above and how they might be is to provide an alternative, "structural"
satisfied in the system. view on the requirements
 Engineerlng and Specifications
145
81 Inheritance Relationships
should contain a set of graphs that illustrate the
For example: primary inheritance hierarchy
T h i s s e c t i o n

kind-of)
for the system. (S

Vehicle

Car
Truck

Toyota Honda GMC Volvo

8 2 C l a s s d e s c r i p t i o n s

section presents
a more detailed description of each class identified during the 00 Domain
This
Analysis.

description should conform to the following structure:

Each class
8.2.1 <Class name>

Concrete
[Link] Abstract or
Indicates whether this class is abstract or concrete.
Superclasses
[Link] List of
Names all immediate superclasses.
Subclasses
[Link] List of
Names all immediate subclasses.
[Link] Purpose
States the basic purpose of
the class.
[Link] Collaborations
accomplish its
with which this class must interact in order to
Names each class
purpose, and how.

class,and
with each instance of this
[Link] Attributes
associated
(state variable)
Lists each attribute (or a range).
possible values
indicates examples of
each
[Link] Operations of this class. For
instances
invoked upon any
each operation that can
be
return value (and its type), and
Lists type), the
thearguments (and their
operation,
operation should be specified.
side effects of the
of instances of this
behaviour
general state or
[Link] Constraints
restrictions upon the
LIStS any
class.
 146 Software Engineering

9. OPERATIONAL SCENARIOS
This section should describe of scenarios that illustrate, from the user's perspective, what
what .wil
be experienced when utilizing the system under various situations.
10. PRELIMINARY SCHEDULE

This section provides an initial versionof the project plan, including the major tasks to be accomplished
their interdependencies, and their tentative start/stop dates. The plan also includes information o
hardware, software, and wetware resource requirements.
Ihe project plan should be accompanied by one or more PERT or GANTT charts.
11. PRELIMINARY BUDGET
This section provides an initial budget for the project, itemized by cost factor.
12. APPENDICES
Specifies other useful informatior for understanding the requirements. All SRS documents should
include at least the following two appendices:
12.1 Definitions, Acronyms, Abbreviations
Provides definitions of unfamiliar definitions, terms, and acronyms.
12.2 References
Provides complete citations to ail documents and meetings referenced or used in the preparat1on
of this document.

.8 Specification Techniques