IEEE Guide To Software Requirements Specifications Std 830 1984 SRS

User Manual: Pdf

Open the PDF directly: View PDF .
Page Count: 26

Download
Open PDF In Browser	View PDF

ANSI/IEEE Std 830-1984

IEEE Guide to Software
Requirements Specifications

SH08714

Authorized licensed use limited to: Indian Institute of Technology Indore. Downloaded on January 23,2018 at 03:24:05 UTC from IEEE Xplore. Restrictions apply.

THIS PAGE WAS
BLANK IN THE ORIGINAL

Authorized licensed use limited to: Indian Institute of Technology Indore. Downloaded on January 23,2018 at 03:24:05 UTC from IEEE Xplore. Restrictions apply.

ANSI/IEEE
Std 830-1984

A n American National Standard

IEEE Guide t o Software
Requirements Specifications

Sponsor
Software Engineering Technical Committee
of the
IEEE Computer Society
Approved September 30,1983
IEEE: Standards Board
Approved July 20, 1984
American National Standards Institute

@

Copyright 1984 by

The Institute of Electiiical and Electronics Engineers, Inc
345 East 47th Street, New York, NY 10017, USA
N o part of this publictrtion may be reproduced in any form,
in an electronic retrieval system or otherwise,
without the prior written permission of the publisher.

Authorized licensed use limited to: Indian Institute of Technology Indore. Downloaded on January 23,2018 at 03:24:05 UTC from IEEE Xplore. Restrictions apply.

IEEE Standards documents are developed within the Technical Committees of the IEEE Societiies and the Standards Coordinating Committees of the IEEE Standards Board. Members of the committees serve
voluntarily and without compensation. They are not necessarily members of the Institute. The standards developed within IEEE represent
a consensus of the broad expertise on the subject within the Institute
as well as those activities outside of IEEE which have expressed an interest in participating in the development of the standard.
Use of an IEEE Standard is wholly voluntary. The existence of an
IEEE Standard does not imply that there are no other ways to produce, test, measure, purchase, market, or provide other goods and services related to the scope of the IEEE Standard. Furthermore, the viewpoint expressed at the time a standard is approved and issued is subject
to change brought about through developments in the state of the art
and comments received from users of the standard. Every IEEE Standard is subjected to review at least once every five years for revision
or reaffirmation. When a document is more than five years old, and has
not been reaffirmed, it is reasonable t o conclude that its contents,
although still of some value, do not wholly reflect the present state of
the art. Users are cautioned to check to determine that they have the
latest edition of any IEEE Standard.
Comments for revision of IEEE Standards are welcome from any
interested party, regardless of membership affiliation with IEEE. Suggestions for changes in documents should be in the form of a proposed
change of text, together with appropriate supporting comments.
Interpretations: Occasionally questions may arise regarding the meaning of portions of standards ,as they relate to specific applications. When
the need for interpretations is brought to the attention of IEEE, the
Institute will initiate artion t o prepare appropriate responses. Since
IEEE Standards represent a consensus of ail concerned interests, it is
important to ensure that any interpretation has also received the concurrence of a balance of interests. For this reason IEEE and the members of its technical committees are not able to provide an instant response to interpretation requests except in those cases where the matter
has previously received formal consideration.
Comments on standards and requests for interpretations should be addressed to:
Secretary, IEEE Standards Board
345 East 47th Street
New York, NY 10017
USA

Authorized licensed use limited to: Indian Institute of Technology Indore. Downloaded on January 23,2018 at 03:24:05 UTC from IEEE Xplore. Restrictions apply.

Foreword
(This Foreword is not a part of IEEE Std 830-19(94,
IEEE Guide to Software Requirements Specifications.)

This guide describes alternate approaches to good practice in the specification of software requirements. The requirements may be explicitly stated by the user or they may be allocated to computer
software (that is, programs) by the system requirements analysis process. This guide does not suggest that a hierarchy of software requirements specifications exists, of which each, in turn, defines a
smaller subset of requirements.
As a guide, this document should help:
(1)Software customers to accurately describe what they wish t o obtain.
(2) Software suppliers to understand exactly what the customer wants.
(3) Individuals to accomplish the following goals:
(a) Develop standard software requirements specifications (SRS) outline for their own organizations.
(b) Define the form and content of their specific software requirements specifications.
(c) Develop additional local supporting items such as an SRS quality checklist, or an SRS writer’s
handbook.
To the customers, suppliers and other individuals, a good SRS provides several specific benefits. It
will accomplish the following goals:
(1)Establish the basis for agreement between the customers and the suppliers on what the software product is to do. The complete description of the functions t o be performed by the software
specified in the SRS will assist the potential user, to determine if the software specified meets their
needs or how the software must be modified to meet their needs.
(2) Reduce the development effort. The preparation of the SRS forces the various concerned
groups in the customer’s organization to consider rigorously all of the requirements before design
begins and reduces later redesign, recoding, and retesting. Careful review of the requirements in the
SRS can reveal omissions, misunderstandings, and inconsistencies early in the development cycle
when these problems are easier to correct.
(3) Provide a basis for estimating costs and schedules. The description of the product to be
developed as given in the SRS is a realistic basis for estimating project costs and can be used to
obtain approval for bids or price estimates. ‘The SRS also provides a clear description of the required
software and makes it easier to estimate and plan the necessary resources. The requirements which,
together with a development plan, can be used to measure progress.
(4)Provide a baseline for validation and verification. Organizations can develop their validation
and verification plans much more productively from a good SRS. As a part of the development contract, the SRS provides a baseline against -which compliance can be measured. (However, that the
converse is not true; a standard legal contract cannot be used as an SRS. Such documents rarely
contain the detail required and are often incomplete.)
(5) Facilitate transfer. The SRS makes it easier to transfer the software product to new users or
new machines. Customers thus find it easier t o transfer the software to other parts of their organization, and suppliers find it easier to transfer it to new customers.
(6) Serves as a basis for enhancement. Because the SRS discusses the product but not the project
that developed it, the SRS serves as a basis for later enhancement of the finished product. The SRS
may need to be altered, but it does provide a solid foundation for continued production evolution.
This guide is based on a model in which the result of the software requirements specification
process is an unambiguous and complete specification document. In principle, the SRS can be
mechanically translated into the specified software program directly. As such, the resulting SRS
document itself is the specified software, and the supplier’s only duty (after completing the SRS)
would be the mechanical compilation of the SRS into machine code for the target computer. The
present state of the art does not support such a compiler with an optimizer of such efficiency to
make it practical but this limitation need not, and should not, restrict the intermediate objective of
an unambiguous SRS.

Authorized licensed use limited to: Indian Institute of Technology Indore. Downloaded on January 23,2018 at 03:24:05 UTC from IEEE Xplore. Restrictions apply.

This guide is consistent with IEEE Std 729-1983,IEEE Standard Glossary of Software Engineering Terminology; ANSI/IEEE Std 730-1981,IEEE Standard for Software Quality Assurance Plans;
and IEEE Std 829-1983,IEEE Standard for Software Test Documentation. This guide may be used
in conjunction with those standards or separately.
This guide was prepared by the Software Requirements Working Group of the Software Engineering Standards Subcommittee of the Technical Committee on Software Engineering of the IEEE
Computer Society.
At the time the guide was approved, the Software Requirements Working Group had the following membership:

A. h5. Davis, Chairperson
M. Bariff
H. Berlack
F. Buckley
E. Byrne
F. Calm
K. Foster
S . Frankel
T. L. Hannan
P. W. Kendra
T. M. Kurinara

R. A. C. Lane
R. Lechner
E. Levinson
P. Lindemann
S.Mroczek
A. J. Neumann
W. Newson
D. Paster
B. Pope
P. B. Powell

G. R. Niedhart
J. Russell
A. Salwin
N. B. Schneidewind
D. Schultz
R. W. Szczech
A. Weigel
P. Willis
H. Willman
A. W. Yonda

At the time that it approved this guide, the Software Engineering Standards Subcommittee had
the following membership:

F. J. Buckley, Chairperson
R. J. Abbott
A. F. Ackerman
L. Beltracchi
D. W. Bragg
D. W.Burt
E. R. Byrne
H. Carney
J. W. Center
A. M. Cicu
G. G. Cooke
A. J. Cote, Jr
P. W.Daggett
G. Darling
B. Dasarathy
A. M. Davis
P. A. Denny
J. A. Dobbins
M. L. Eads
J. D. Earls
L. G. Egan, J r
D. W. Fife
J. Flournoy
J. J. Forman
F. K. Gardner
D. Gelperin
E. L. Gibbs
G. Gladden
S.A. GlossSoler
J. W. Grigsby
R. M. Gross
D. A. Gustafson
R. T. Gustin
T. L. Hannan
H. Hecht

IL. R. Heselton, I11

S. Horvitz
.’1 Howley
It. N. Hurwitz
S. Hwang
.J. H. Ingram
cJ. P. Kalasky
IX. Kessler
‘l’. M. Kurinara
ID. V. LaRosa
13. A. C. Lane
(7.R. Lewis
17. C. Lim
(3. S . Lindsay
IM. Lipow
W.M. Lively
IM. Lubofsky
13. Lindquist
,4. K. Manhindru
1’. C. Marriott
C. F. Martiny
IN. McCollough
13. Menkus
13. Meyer
13. F. Miller, Jr
(3. S . Morris
(3.T. Morun
W.G. Murch
*J. Nebb
(3. R. Niedhart
IM. A. Neighbors
*J. 0. Neilson
ID. J. Ostrom

D. J. Pfeiffer
R. M. Poston
P. B. Powell
J. W. Radatz
J. C. Rault
S. T. Redwine
L. K. Reed
W. E. Riddle
C. W. Rutter, I11
P. E. Schilling
N. F. Schniedewind
A. D. Schuman
L. W. Seagren
R. L. Skelton
W. Smith
H. M. Sneed
K. C. Tai
B. J. Taute
R. H. Thayer
G. D. Tice, J r
T. L. Tillmans
W. S . Turner, I11
E. A. Ulbrich, J r
D. Usechak
U. Voges
R. Wachter
J. P. Walter
D. Webdale
A. H. Weigel
N. P. Wilburn
W. M. Wong
T. Workman
A. W. Yonda
P. F. Zoll

Authorized licensed use limited to: Indian Institute of Technology Indore. Downloaded on January 23,2018 at 03:24:05 UTC from IEEE Xplore. Restrictions apply.

Special representatives to the software engineering standards subcommittee were:
J. Milandin:
ANSI 21
W. G. Perry:
Data Processing Manufa'cturers Association
R. Pritchett:
EDP Auditors Association
T. L. Regulinski: IEEE Reliability Society
N. C. Fan:
Nuclear Power Engineering Committee, IEEE Power Engineering Society
Suggestions for improvement of this guide are welcome. They should be provided to:
The Secretary
IEEE Standards Board
345 East 47th St
New York, New York 10017
At the time the IEEE Standards Board approved this standard on September 20,1983 it had the
following members:
Edward Chelotti, Vice Chairman

James H. Beall, Chairman
Sava I. Sherr, Secretary
J. J. Archambault
John T. Boettger
J. V. Bonucchi
Rene Castenschiold
Edward J. Cohen
Len S . Corey
Donald C. Fleckenstein
Jay Forster

Donald H. Heirman
Irvin N. Howell
Joseph L. Koepfinger*
Irving Kolodny
George Konomos
John E. May
Donald T. Michael*

John P. Riganati
Frank L. Rose
Robert W. Seelbach
Jay A. Stewart
Clifford 0. Swanson
Robert E. Weiler
W.B. Wilkens
Charles J. Wylie

*Member emeritus

Authorized licensed use limited to: Indian Institute of Technology Indore. Downloaded on January 23,2018 at 03:24:05 UTC from IEEE Xplore. Restrictions apply.

THIS PAGE WAS
BLANK IN THE ORIGINAL

Authorized licensed use limited to: Indian Institute of Technology Indore. Downloaded on January 23,2018 at 03:24:05 UTC from IEEE Xplore. Restrictions apply.

Contents
PAGE

SECTION

1. ScopeandOrganization .....................................................
1.1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Organization ..........................................................

9
9
9

2 . References

...............................................................
9
3 . Definitions ...............................................................
10
4 . Background Information for Writing a Good SRS ..................................
10
4.1 TheSRS .............................................................
10
10
4.2 Environment of the SRS .................................................
4.3 Characteristics of a Good SRS ............................................
11
4.3.1 Unambiguous . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
4.3.1.1 Natural Language Pitfalls ....................................
11
4.3.1.2 Formal Requiremlents Specifications Languages . . :. . . . . . . . . . . . . . . . 11
4.3.2 Complete .......................................................
11
4.3.3 Verifiable .......................................................
12
4.3.4 Consistent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
4.3.5 Modifiable ......................................................
12
4.3.6 Traceable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
4.3.7 Useable During The Operation and Maintenance Phase ....................
13
4.4 Joint Preparation of the SRS .............................................
13
4.5 SRSEvolution ........................................................
13
4.6 Tools for Developing an SRS .............................................
14
14
4.6.1 Formal Specification Methcodologies ..................................
4.6.2 Production Tools .................................................
14
14
4.6.3 Representation Tools ..............................................
14
5 . SoftwareRequirements ......................................................
5.1 Methods Used to Express Software Requirements .............................
14
14
5.1.1 Input/Output Specifications ........................................
5.1.1.1 Approaches ..............................................
15
5.1.1.2 Difficulties ...............................................
15
5.1.2 Representative Examples ...........................................
15
5.1.3 Models .........................................................
15
5.1.3.1 Mathematical Models .......................................
15
15
5.1.3.2 Functional Models .........................................
5.1.3.3 TimingModels ............................................
15
5.1.3.4 OtherModels .............................................
16
5.1.3.5 Cautions .................................................
16
16
5.2 Annotation of the Software Requirements ...................................
17
5.2.1 Stability ........................................................
17
5.2.2 Degree of Necessity ...............................................
5.2.3 Annotation Caution ...............................................
17
5.3 Common Pitfalls Encountered in Expressing Requirements ......................
17
5.3.1 Embedding Design in the SRS .......................................
5.3.2 Embedding Project Requirements in the SRS ...........................

6 . An SRS Prototype Outline ...................................................
6.1 Introduction (Section 1of the SRS) ........................................
6.1.1 Purpose (1.1of the SRS) ...........................................
6.1.2 Scope (1.2 of the SRS) ............................................
6.1.3 Definitions, Acronyms. and Abbreviations (1.3 of the SRS) . . . . . . . . . . . . . . . .

17
17

18
18

18
18
18

Authorized licensed use limited to: Indian Institute of Technology Indore. Downloaded on January 23,2018 at 03:24:05 UTC from IEEE Xplore. Restrictions apply.

SECTION

PAGE

6.1.4 References (1.4 of the SIES) .........................................
18
6.1.5 Overview (1.5 of the SRS) ..........................................
18
6.2 The General Description (Section 2 of the SRS) ...............................
18
6.2.1 Product Perspective (2.1 of the SRS) ..................................
19
6.2.2 Product Functions (2.2 o f the SRS) ...................................
19
6.2.3 User Characteristics (2.3 of the SRS) ..................................
19
6.2.4 General Constraints (2.4 of the SRS) ..................................
19
6.2.5 Assumptions and Dependencies (2.5 of the SRS) .........................
20
20
6.3 The Specific Requirements (Section 3 of the SRS) .............................
6.3.1 Information Required as Part of the Specific Requirements . . . . . . . . . . . . . . . . 20
20
6.3.1.1 Functional Requirements ....................................
21
6.3.1.2 Performance Requirements ..................................
6.3.1.3 Design Constraints .........................................
21
6.3.1.4 Attributes ...............................................
21
6.3.1.5 External Interface Requirements ..............................
22
6.3.1.6 Other Requirements ........................................
22
6.3.2 Organizing the Specific Requirements ..................................
23
24
6.4 Supporting Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
FIGURES

Fig 1 A Functional Model Specifying Any Sequence of Alternating 0’s and 1’s

.............

16

TABLES

Table 1
Table 2
Table 3
Table 4
Table 5

Prototype SRS Outline ..................................................
Prototype Outline 1for SRS Section 3 .....................................
Prototype Outline 2 for SRS Section 3 .....................................
Prototype Outline 3 for SRS Se’ction3 .....................................
Prototype Outline 4 for SRS Se’ction3 .....................................

18
23
23
24
24

Authorized licensed use limited to: Indian Institute of Technology Indore. Downloaded on January 23,2018 at 03:24:05 UTC from IEEE Xplore. Restrictions apply.

IEEE Guide to Software
Requirements Specifications

2. References

1. Scope and Organization

[l]ANSI/IEEE Std 100-1977, IEEE Standard
Dictionary of Electrical and Electronics Terms.

1.1 Scope. This is a guide for writing software
requirements specifications. I t describer; the
necessary content and qualities of a good Software Requirements Specification (SRS) and
presents a prototype SRS outline.
This guide does not specify industry,-wide
SRS standards nor state mandatory SRS requirements. This guide is written undeir the
premise that the current state of the art does
not warrant or support such a formal standards
document.
This guide is applicable t o in-house and commercial software products. Special care, however, should be used in its application beca.use:

[2] ANSI/IEEE Std 730-1981, IEEE Standard
for Software Quality Assurance Plans.
[3] ANSI/IEEE Std 729-1983, IEEE Standard
Glossary of Software Engineering Terminology.

[4] BRUSAW, C. T., ALRED, G. and OLIU, W.,
Handbook of Technical Writing, New York, St.
Martin's Press, 1976.
[5] DASARATNY, B., Timing Constraints of
Real-Time Systems: Constructs for Expressing
Them, IEEE Real-Time Systems Symposium,
Dec 1982.

(1) This guide is aimed at specifying requirements of software to be developed. Application
of this material t o alreadydeveloped software
is counter-productive.
(2) This guide does not cover the specification
of requirements for software being develloped
using the techniques of rapid prototyping.

[6] DAVIS, A., The Design of a Family of Applications-Oriented Requirements Languages,
ZEEE Computer, 1 5 , 5 May 1982, pp 21-28.

1.2 Organization. The remainder of this guide
is organized as follows:
(1) Section 2 provides the references used
throughout the guide.
(2) Section 3 provides definitions of specific
terms used throughout the guide.
(3) Section 4 provides background information for writing a good SRS.
(4)Section 5 provides specific guidance for
expressing software requirements.
( 5 ) Section 6 discusses each of the essential
parts of an SRS and provides alternate prototype outlines.

[8] KAIN, R., Automata Theory: Machines
and Languages, McGraw Hill, New York, 1972.

[ 7 ] FREEDMAN, D. and WEINBERG, G.,
Handbook of Walkthroughs, Inspections and
Technical Reviews, 3rd Ed, Little and Brown
Publishers, New York.

[9] KOHAVI, Z., Switching and Finite Automata Theory, McGraw Hill, New York, 1970.
[ 101 KRAMER, J., Editor, Application Oriented Specifications Glossary of Terms, European Workshop o n Industrial Computer Systems
(E WICS), Imperial College, London, England,
May 6,1981.'
'Copies of this document are available from EWICS,
c / o G. R. Koch, BIOMATIKGmbh, Carl-MezStr 81-83,
D-7800 Freiburg, Federal Republic of Germany.

9

Authorized licensed use limited to: Indian Institute of Technology Indore. Downloaded on January 23,2018 at 03:24:05 UTC from IEEE Xplore. Restrictions apply.

IEEE
Std 830-1984

IEEE GUIDE TO SOFTWARE

[ l l ]MILLS, G., and WALTER, J., Technical
Writing, New York, Holt, Rinehart and Winston, 4th Ed, 1978.

supplier. The person, or persons, who produce
a product for a customer. In the context of this
document, the customer and the supplier may
be members of the same organization.

[ 121 PETERSON, J., Petri Nets, ACM Computing Surveys, 9 , 4 , Dec 1977, pp 223-252.

user. The person, or persons, who operate or
interact directly with the system. The user(s)
and the customer(s) are often not the same
person( s) .

[13] RAMAMOORHY, C. and SO, H. H., S o f t ware Requirements and Specifications: Status
and Perspectives, Tutorial: Software Methodology, RAMAMOORTHY, C. and YEH, R. T.,
Editors. IEEE Catalog no E H 0 142-0,1978,
pp 43-164.

4. Background Information for
Writing a Good SRS

[14] TAGGART, W. M. Jr, and THARP, M.O.,
A Survey of Information Requirements Analysis
Techniques, ACM Computing Surveys, 9 , 4,
Dec 1977, pp 273-290.

This section provides background information
necessary for writing an SRS. This includes:
(1)Examination of the nature of the SRS
(2) Environmental considerations surrounding the SRS
(3) Characteristics required for a good SRS
(4) Recommendations for joint preparation
of an SRS
( 5 ) Evolutionary aspects of the SRS
(6) The use of automated tools to develop an
SRS

[ 151 TEICHROEW, D., A Survey o f Languages
for Stating Requirements for Computer-Based
Information Systems, 1972 Fall Joint Cornputer
Conference, 1972, pp 1203-1224.

3. Definitions
Except for the definitions listed below, the
definitions of all terms used in this guidle conform t o the definitions provided in IEEE Std
729-1983 [ 312, for example, the terms requirement, requirements specification. If EL term
used in this guide does not appear in that
Standard, then ANSI/IEEE Std 100-1977 [ 11,
applies.
The terms listed in this section have been
adopted from Section 2, [ 101.

4.1 The SRS. The SRS is a specification for a
particular software product, program, or set of
programs that does certain things. See ANSI/
IEEE Std 730-1981 [ 2 ] , 3.4.2.1.
The description places two basic requirements
on the SRS:
(1)I t must say certain things. For example,
software developed from an SRS that fails t o
specify that error messages will be provided,
will probably fail t o satisfy the customer.
(2) It must say those things in certain ways.
For example, software developed from an SRS
that fails t o specify the format and content of
error messages and instead is developed from a
vague and nonquantifiable requirement such as
All error messages will be helpful, will probably
be unsatisfactory. What is helpful for one person can be a severe aggravation t o another
person.
For recommended contents of an SRS see
Section 6.

contract. A legally binding document agreed
upon by the customer and supplier. This includes the technical, organizational, cost and
schedule requirements of a product.
customer. The person, or persons, who pay for
the product and usually (but not necessarily)
decides the requirements. In the context of this
document the customer and the supplier may
be members of the same organization.
language. A means of communication, with
syntax and semantics, consisting of a set of
representations, conventions and associated
rules used t o convey information.

4.2 Environment of the SRS. It is important t o
consider the part that the SRS plays in the
total software project. The provisions in ANSI/
IEEE Std 730-1981 [ 2 ] , define the minimum
required documents for a software project. See
[2], 3.4.2.
ANSI/IEEE Std 730-1981 [ 21 also identifies
the other useful documents. See [ 21 ,3.4.3.

partitioning. Decomposition; the separation of
the whole into its parts.
2Numbers in brackets correspond t o those of the
references in Section 2.

10

Authorized licensed use limited to: Indian Institute of Technology Indore. Downloaded on January 23,2018 at 03:24:05 UTC from IEEE Xplore. Restrictions apply.

IEEE
Std 830-1984

REQUIREMENTS SPECIFICATIONS

(2) The specification The control total is
taken from the last record, might be read as:
(a) The control total is taken from the
record at the end of the file
( b ) T h e control total is taken from the
latest record
(c) The control total is taken from the
previous record
(3) The specification All customers have the
same control field, might be read as:
(a) All customers have the same value in
their control field
(b) All customer control fields have the
same format
(c) One control field is issued for all
customers
(4)The specification All files are controlled
b y a file control block, might be read as:
(a) One control block controls the entire
set of files
(b) Each file has its own block
(c) Each file is controlled by a control
block, but one control block might control
more than one file
4.3.1.2 Formal Requirements Specifications
Languages. One way t o avoid the ambiguity inherent in natural language is t o write the SRS in
a formal requirements specification language?
(1)One major advantage in the use of such
languages is the reduction of ambiguity. This
occurs, in part, because the formal language
processors automatically detect many lexical,
syntactic, and semantic errors.
(2) One major disadvantage in the use of such
languages is the length of time required t o learn
them.
4.3.2 Complete. An SRS is complete if it
possesses the following qualities:
(1)Inclusion of all significant requirements,
whether relating to functionality, performance,
design constraints, attributes or external interfaces.
(2) Definition of the responses of the software t o all realizable classes of input data in all
realizable classes of situations. Note that it is
important to specify the responses t o valid and
invalid input values.
(3) Conformity t o any SRS standard that
applies t o it. If a particular section of the
standard is not applicable, the SRS should

Since the SRS has a definite role to play in this
documentation scheme, SRS writers shoulld be
careful not t o go beyond the bounds of that
role. This means the following requirements
should be met:
(1)The SRS must correctly define all of the
software requirements, but no more.
(2) The SRS should not describe any design,
verification, or project management details,
except for required design constraints.
Such a properly written SRS limits the range
of valid solutions but does not specify any
particular design and thus provides the supplier
with maximum flexibility.

4.3 Characteristics of A Good SRS. The previous sections describe the types of informat'ion
that should be contained in an SRS. The following concepts deal with particular characteristics.
A good SRS is:
(1)Unambiguous
(2) Complete
(3) Verifiable
(4)Consistent
( 5 ) Modifiable
(6) Traceable
(7) Usable during the Operation and Maintenance Phase
4.3.1 Unambiguous. An SRS is unambiguous
if - and only if - every requirement stated
therein has only one interpretation.
(1)As a minimum, this requires that each
characteristic of the final product be described
using a single unique term.
(2) In cases where a term used in a particular
context could have multiple meanings., the
term must be included in a glossary where its
meaning is made more specific.
4.3.1.1 Natural Language Pitfalls. Requirements are often written in a natural language
(for example, English). SRS writers who 'use a
natural language must be especially careful t o
review their requirements for ambiguity. The
following examples are taken from Section 2,
[71.
(1)The specification The data set will contain an end of file character, might be read as:
(a) There will be one and only one erid of
file character
(b) Some character will be designated as an
end of file character
(c) There will be a t least one end of file
character

3F0r detailed discussion on this topic, suggested readingsare [ 6 ] , [ 1 3 ] , [ 1 4 ] , a n d [ 1 5 ] .

11

Authorized licensed use limited to: Indian Institute of Technology Indore. Downloaded on January 23,2018 at 03:24:05 UTC from IEEE Xplore. Restrictions apply.

IEEE
Std 830-1984

IEEE GUIDE TO SOFTWARE

(4)If a requirement is not expressible in verifiable terms at the time the SRS is prepared,
then a point in the development cycle (review,
test plan issue, etc) should be identified at
which the requirement must be put into a
verifiable form.
4.3.4 Consistent. An SRS is consistent if and
only if no set of individual requirements
described in it conflict. There are three types
of likely conflicts in an SRS:
(1)Two or more requirements might describe
the same real world object but use different
terms for that object. For example, a program's
request for a user input might be called a
prompt in one requirement and a cue in
another.
( 2 ) The specified characteristics of real world
objects might conflict. For example:
(a) The format of an output report might
be described in one requirement as tabular but
in another as textual.
(b) One requirement might state that all
lights shall be green while another states that
all lights shall be blue.
(3) There might be a logical or temporal conflict between two specified actions. For example:
(a) One requirement might specify that the
program will add two inputs and another specify
that the program will multiply them.
(b) One requirement might state that A
must always follow B, while another requires
that A and B occur simultaneously.
4.3.5 Modifiable. An SRS is modifiable if its
structure and style are such that any necessary
changes to the requirements can be made easily,
completely , and consistently. Modifiability
generally requires an SRS to:
(1)Have a coherent and easy-to-use organization, with a table of contents, an index,, and
explicit cross-referencing.
( 2 ) N o t be redundant; that is, the same requirement should not appear in more than one
place in the SRS.
(a) Redundancy itself is not an error, but it
can easily lead t o errors. Redundancy can occasionally help to make an SRS more readable,
but a problem can arise when the redundant
document is updated. Assume, for instance,
that a certain requirement is stated in two
places. At some later time, it is determined that
the requirement should be altered, but the
change is made in only one of the two locations. The SRS then becomes inconsistent.

include the section number and an explanation
of why it is not applicable.
(4)Full labeling and referencing of all figures,
tables, and diagrams in the SRS and definition
of all terms and units of measure.
4.3.2.1 Use of TBDs. Any SRS tha.t uses
the phrase t o be determined (TBD) is not a
complete SRS.
(1)The TBD is, however, occasionally necessary and should be accompanied by:
(a) A description of the conditions causing
the TBD (for example, why an answer is not
known) so that the situation can be resolved.
(b) A description of what must be done to
eliminate the TBD.
(2) Any project documents that are based on
an SRS that contains TBDs, should:
(a) Identify the version or state the specific
release number of the SRS associated with that
particular document.
(b) Exclude any commitments dependent
upon the sections of the SRS that are still
identified as TBDs.
4.3.3 Verifiable. An SRS is verifiable if and
only if every requirement stated therein is verifiable. A requirement is verifiable if and only if
there exists some finite cost-effective process
with which a person or machine can check that
the software product meets the requirement.
(1)Examples of nonverifiable requirements
include statements such as:
(a) The product should work well, or The
product should have a good human interface.
These requirements cannot be verified bt,.cause
it is impossible to define the terms good or
well.
(b) The program shall never enter an infinite
loop. This requirement is non-verifiable bc>cause
the testing of this quality is theoretica1:ly impossible.
(c) The output o f the program shall usually
be given within 10 s. This requirement is nonverifiable because the term usually cannot be
measured.
(2) An example of a verifiable statement is
The output o f the program shall be given within 20 s of event X, 60% o f the time; ana' shall
be given within 30 s of event X, 100% o f the
time. This statement can be verified because it
uses concrete terms and measurable quant,ities.
(3) If a method cannot be devised to determine whether the software meets a part,icular
requirement, then that requirement should be
removed or revised.

12

Authorized licensed use limited to: Indian Institute of Technology Indore. Downloaded on January 23,2018 at 03:24:05 UTC from IEEE Xplore. Restrictions apply.

IEEE
Std 830-1984

REQUIREMENTS SPECIFICATIONS

(b) The SRS should contain a record of all
special provisions that apply t o individual components such as:
(i) Their criticality (for example, where
failure could impact safety or cause large financial or social losses).
(ii) Their relation t o only temporary
needs (for example, t o support a display that
may be retired soon).
(iii) Their origin (for example, function X
is t o be copied from an existing software
product in its entirety).
(2) Knowledge of this type is taken for
granted in the developing organization but is
frequently missing in the maintenance organization. If the reason for or origin of a function
is not understood, it is frequently impossible t o
perform adequate software maintenance on it.

(b) Whenever redundancy is necessary, the
SRS should include explicit cross-references to
make it modifiable.
4.3.6 Traceable. An SRS is traceable if the
origin of each of its requirements is clear and if
it facilitates the referencing of each :requirement in future development or enhancement
documentation. Two types of traceability are
recommended:
(1)Backward traceability (that is, t o previous
stages of development) depends upoln each
requirement explicitly referencing its source in
previous documents.
(2) Forward traceability (that is, to all documents spawned by the SRS) depends upon
each requirement in the SRS having a unique
name or reference number.
When a requirement in the SRS represents an
apportionment or a derivative of another requirement, both forward and backward traceability should be provided. Examples include:
4.3.6.1 The allocation of response time t o a
data base function from the overall user response time requirement.
4.3.6.2 The identification of a report format with certain functional and user interface
requirements.
4.3.6.3 A software product that supports
legislative or administrative needs (for example,
tax computations, reporting of an overhead
ratio). In this case, the exact legislative or administrative document that is being supported
should be identified.
The forward traceability of the SRS is especially important when the software product
enters the operation and maintenance phase.
As code and design documents are modlified, it
is essential t o be able t o ascertain the complete
set of requirements that may be affected by
those modifications.
4.3.7 Usable During the Operation and Maintenance Phase. The SRS must address thle needs
of the operation and maintenance phLase, including the eventual replacement of the software.
(1)Maintenance is frequently carried out by
personnel not associated with the original
development. Local changes (corrections) can
be implemented by means of a well-commented
code. For changes of wider scope, however, the
design and requirements documentation is essential. This implies two actions
(a) The SRS should be modifiable as indicated in 4.3.5.

4.4 Joint Preparation of the SRS. The software
development process begins with supplier and
customer agreement on what the completed
software must do. This agreement, in the form
of an SRS, should be jointly prepared. This is
important because usually neither the customer
nor the supplier is qualified t o write a good
SRS by himself.
(1)Customers usually do not understand the
software design and development process well
enough t o write a usable SRS.
(2) Suppliers usually do not understand the
customer’s problem and field of endeavor well
enough t o specify requirements for a satisfactory system.
The customer and the supplier need t o work
together t o produce a well written and completely understood SRS.4
4.5 SRS Evolution. The SRS may need t o evolve
as the development of the software product
progresses.
(1)It may be impossible t o specify some
details at the time the project is initiated. For
example, it may be impossible t o define during
the Requirements Phase, all of the screen formats for an interactive program in a manner
that guarantees that they will not be altered
later.
(2) Additional changes may ensue as deficien4This guide does not specifically discuss style, language usage, or techniques of good writing. It is quite
important, however, that an SRS be well written; for
guidance, please refer to general technical writing guides
such as [ l ] and [ l l ] .

13

Authorized licensed use limited to: Indian Institute of Technology Indore. Downloaded on January 23,2018 at 03:24:05 UTC from IEEE Xplore. Restrictions apply.

IEEE
Std 830-1984

IEEE GUIDE TO SOFTWARE

headings and subheadings, the compilation of
tables of contents and indexes, etc, all of which
help in the production of a more readable SRS.
4.6.3 Representation Tools. Some words in
the SRS, especially nouns and verbs, refer
specifically to entities and actions in the system. There are several advantages t o identifying them as such.
(1)It is possible t o verify that an entity or
action always has the same name everywhere in
the SRS. Thus calculate trajectory would not
co-exist with determine flight path,
( 2 ) It is possible t o identify every place in the
specification where a particular entity or action
is described.
In addition, it may be desirable t o formalize
the English structure in some way t o allow
automated processing of the content of the
SRS. With such constraints it becomes possible
to:
4.6.3.1 Display the requirements in some
tabular or graphical way.
4.6.3.2 Automatically check the SRS requirements in hierarchical layers of detail,
where each layer is complete in itself but may
also be expanded upon in a lower hierarchical
layer or be a constituent of an upper hierarchical layer.
4.6.3.3 Automatically check that the SRS
possesses some or all of the characteristics
described in 4.3.

cies, shortcomings, and inaccuracies are discovered in the SRS, as the product evolves.
Two major considerations in this process are:
4.5.1 The requirements should be specified as
completely and thoroughly as possible, even if
evolutionary revisions can be forseen as inevitable. For example, the desired screen formats
should be specified as well as possible in the
SRS as a basis for later design.
4.5.2 A formal change process should be
initiated to identify, control, track, and report
projected changes, as soon as they are initially
identified. Approved changes in requirements
should be incorporated in the SRS in such a
way as to:
(1)Provide an accurate and complete audit
trail of changes.
(2) Permit the review of current and superseded portions of the SRS.

4.6 Tools for Developing an SRS. The most
obvious way to create an SRS is t o write it in a
natural language (for example, English). But because natural languages are rich, although imprecise, a number of more formal methods
have been devised t o assist SRS writers.
4.6.1 Formal Specification Methodologies.
The degree t o which such formal methodologies
may be useful in preparing an SRS depends
upon a number of factors:
(1)The size and complexity of the program
(2) Whether a customer contract requires it
(3) Whether the SRS is a vehicle for contracts
or merely an internal document
(4)Whether the SRS document will become
the top level of the design document
( 5 ) What computer facilities are available to
support such a methodology
No attempt is made here t o describe or endorse any particular tool?
4.6.2 Production Tools. A computer-based
word processor is a most useful production aid.
Usually, an SRS will have several authors, will
undergo several revisions, and will have several
reorganizations. A word processor that manages
the text as a computer file facilitates this process.
Almost all computer systems have a word
processor and often a document preparation
package is associated with it. This automates
paragraphing and referencing, the printing of

5 . Software Requirements
Each software requirement in an SRS is a
statement of some essential capability of the
software t o be developed. The following subsections describe:
(1)Methods used t o express software requirements
(2) Annotation of the software requirements
(3) Common pitfalls encountered in the process

5.1 Methods Used To Express Software Requirements. Requirements can be expressed in
a number of ways:
(1)Through input/output specifications
(2) By use of a set of representative examples
(3) By the specification of models
5.1.1 Input/Output Specifications. I t is often
effective t o specify the required behavior of a
software product as a sequence of inputs and
outputs.

5For detailed discussion on this topic, see, for example, [ 6 ] , [ 1 3 ] , [ 1 4 ] , a n d [15].

14

Authorized licensed use limited to: Indian Institute of Technology Indore. Downloaded on January 23,2018 at 03:24:05 UTC from IEEE Xplore. Restrictions apply.

IEEE
Std 830-1984

REQUIREMENTS SPECIFICATIONS

5.1.1.1 Approaches. There are at least three
different approaches based on the nature of the
software being specified:
(1)Some software products (such a:; reporting systems) are best specified by focusing on
required outputs. In general, output -focused
systems operate primarily on data files. User input usually serves t o provide control information and trigger data file processing.
(2) Others are best specified by focusing on
input/output behavior. Input/output,-focused
systems operate primarily on the current input.
They are required t o generate the niatching
output (as with data conversion routines or a
package of mathematical functions).
(3) Some systems (such as process control
systems) are required t o remember their behavior so that they can respond t o a m input
based on that input and past inputs; that is,
behave like a finite state machine. In this case
the focus is on both input/output pairs and
sequences of such pairs.

required inputs and outputs but they do not
specify the system’s behavior completely.
5.1.3 Models. Another approach is t o express
the requirements in the form of a model? This
can be an accurate and efficient way t o express
complex requirements.
At least three generalized types of models are
in common usage:
(1)Mathematical
(2) Functional
(3) Timing
Care should be taken t o distinguish between
the model for the application; that is, a linear
programming model (with a set of linear inequalities and an objective function) and the
model for the software which is required to
implement the application model. See 5.1.3.5.
5.1.3.1 Mathematical Models. A mathematical model is a model that uses mathematical
relations t o describe the software’s behavior.
Mathematical models are especially useful for
particular application areas, including navigation, linear programming, econometrics, signal
processing and weather analysis.
A mathematical model might specify the
response discussed in 5.1.2 like this:
(01)*
where * means that the parenthesized character
string is repeated one or more times.
5.1.3.2 Functional Models. A functional
model is a model that provides a mapping from
inputs t o outputs. Functional models, for example, finite state machines or Petri nets can
help identify and define various features of the
software or can demonstrate the intended operation of the system.
A functional model might specify the response, i?reviously described by the rnathematical model, in the form of a finite state machine
as shown in Fig 1. In this figure, the incoming
arrow points t o the starting state. The double
lined box represents the accepting state. The
notation X/Y on the lines indicates that when
X is accepted as an input, Y is produced as an
output .
5.1.3.3 Timing Models. A timing model is a
model that has been augmented with timing
constraints. Timing models are quite useful for
specifying the form and details of the software’s
behavior, particularly for real-time systems or
for human factors of any system.

5.1.1.2 Difficulties. Most software products
can receive an infinite number of sequences as
input. Thus, t o completely specify the behavior
of the product through input/output sequences
would require that the SRS contain an infinitely
long set of sequences of inputs and required
outputs. With this approach, therefore, it may
be impossible to completely specify every conceivable behavior that is required of the software.
5.1.2 Representative Examples. One alternative is t o indicate what behavior is required by
using representative examples of that behavior.
Suppose, for example, that the system is required t o respond with a “1” every time it
receives a “ 0 ” . Clearly, a list of all possible
sequences of inputs and outputs would be
impossible. However, by using representative
sequences one might be able t o fully understand
the system’s behavior. This system’s behavior
might be described by using this representative
set of four dialogues:
0101
010101010101
01
010101
These dialogues provide a good idea of the
6Each of the four sample dialogues given :here (one
per line) represents a sequence of one-character user
inputs and one-character system outputs.

‘For details on using modeling techniques, see [ 51,

P I , [ g l , and [121.
15

Authorized licensed use limited to: Indian Institute of Technology Indore. Downloaded on January 23,2018 at 03:24:05 UTC from IEEE Xplore. Restrictions apply.

IEEE
Std 830-1984

IEEE GUIDE TO SOFTWARE

I
-”

Fig 1
A Functional Model Specifying Any Sequence of Alternating Os and I s
Whenever an SRS uses a model:
(a) It means that the model provided an
especially efficient and accurate way t o specify
the requirements
(b) I t does not mean that the implementation of the software product must be based on
that model.
A model that works effectively for explaining
requirements in a written document may not
be optimal for the actual software implementation.

A timing model might add these constraints
t o the model shown in Fig 1.
(1)The stimulus 0 will occur within 30 13 of
the arrival in state S1
(2) The response 1 will occur within 2 si of
the arrival in state S2
5.1.3.4 Other Models. In addition t o the
aforementioned, specific applications hiave
particularly helpful models. For example, a
compiler specification might employ attribute
grammars, or a payroll system might use tables.
I t is t o be noted that the use of a formal requirements language for an SRS usually implies
a need for the use of a particular model.
5.1.3.5 Cautions. Whatever type of model
is used:
(1)It must be rigorously defined, either in
the SRS or in a document referenced in the
SRS. This definition should specify
(a) The required ranges of the model’s
param eters
(b) The values of constraints it uses
(c) The required accuracy of results
(d) The load capacity
(e) The required execution time
(f) Default or failure response
(2) Care must be taken t o keep a model clefinition within the domain of requirements.

5.2 Annotation of the Software Requirements.
Typically, all of the requirements that relate t o
a software product are not equally important.
Some requirements may be essential, especially
for lifecritical applications, while others may
be just nice to have.
(1)Each requirement in the SRS should be
annotated t o make these differences in relative
importance clear and explicit.
(2) Annotating the requirements in this manner, helps:
(a) Customers t o give more careful consideration to each requirement, which often clarifies any hidden assumptions they may have.
(b) Developers to make correct design
decisions and devote appropriate levels of

16

Authorized licensed use limited to: Indian Institute of Technology Indore. Downloaded on January 23,2018 at 03:24:05 UTC from IEEE Xplore. Restrictions apply.

IEEE
Std 830-1984

REQUIREMENTS SPECIFICATIONS

5.3.1 Embedding Design in the SRS. Embedding design specifications in the SRS unduly
constrains the software designs and artificially
places potentially dangerous requirements in
the SRS.
(1)The SRS must specify what functions are
t o be performed on what data t o produce what
results at what location for whom. The SRS
should focus on the services to be performed.
The SRS should not normally specify design
items such as
(a) Partitioning the software into modules
(b) Allocating functions t o the modules
(c) Describing the flow of information or
control between modules
(d) Choosing data structures
(2) It is not always practical to consider the
design as being completely isolated from the
SRS. Security or safety considerations may
impose requirements that reflect directly into
design constraints; for example, the need t o
(a) Keep certain functions in separate
modules
(b) Permit only limited communication
between some areas of the program
(c) Compute check sums for critical quantities
In general, it must be considered that the selection of an appropriate high-level design for
the software may require vast amounts of resources (perhaps as much as 10%t o 20% of the
total product development cost). There are two
alternatives :
(1)Ignore the warning in this guide and
specify the design in the SRS. This will mean
that either a potentially inadequate design is
stated as a requirement (because insufficient
time was spent in arriving at it), or an exorbitant
amount of time is spent during the requirements
phase (because an entire design analysis is performed before SRS completion).
(2) Use the advice in 5.1.3 of this guide. State
the requirements using a model design used
solely to assist in the description of the requirements and not intended t o serve as the actual
design.

effort t o the different parts of the software
product.
5.2.1 Stability. One method of annotating requirements uses the dimension of stability. A
requirement may be considered stable when it
is thought that the needs which it addresses
will not change during the expected life of the
software, or it may be considered volatile and
subject t o change.
5.2.2 Degree of Necessity. Another way t o
annotate is t o distinguish classes of requirements as mandatory, desirable, and optional.
(1) Mandatory implies that the software will
not be acceptable unless these requirements are
provided in an agreed manner.
(2) Desirable implies that these are requirements that would enhance the software product,
but would not make it unacceptable if ithey are
absent.
( 3 ) Optional implies a class of functions that
may or may not be worthwhile, which gives the
supplier the opportunity t o propose soinething
which exceeds the SRS.
5.2.3 Annotation Caution. Prior to annotating
the requirements, a thorough understanding of
the contractual implications of such annotations, should be obtained.

5.3 Common Pitfalls Encountered in Expressing
Requirements. An essential point about the
SRS is that it should specify the results that
must be achieved by the software, not the
means of obtaining those results.
(1) The basic issues that the requirements
writer must address are these:
(a) Functionality - what the software is
supposed to do
(b) Performance - the speed, availability,
response time, recovery time of various software functions, etc
(c) Design Constraints Imposed o n an Implementation -any required standards in effect,
implementation language, policies for d
Source Exif Data: 
File Type                       : PDF
File Type Extension             : pdf
MIME Type                       : application/pdf
PDF Version                     : 1.3
Linearized                      : No
Page Count                      : 26
Subject                         : 
Modify Date                     : 2018:01:22 22:24:05-05:00
Author                          : IEEE
Title                           : IEEE guide to software requirements specifications - IEEE Std 830-1984
Producer                        : Adobe PDF Library 4.0; modified using iText® 5.5.10 ©2000-2015 iText Group NV (AGPL-version)
Creator                         : Acrobat Capture 3.0
Create Date                     : 2004:05:11 12:14:44+05:30
Style                           : Searchable Image (Exact)

EXIF Metadata provided by EXIF.tools