IEEE Guide To Software Requirements Specifications Std 830 1984 SRS

User Manual: Pdf

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

IEEE
Guide
to
Software
Requirements
Specifications
ANSI/IEEE
Std
830-1984
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
An American National Standard
IEEE
Guide to 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
No
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 Com-
mittees of the IEEE Societiies and the Standards Coordinating Commit-
tees of the IEEE Standards Board. Members
of
the committees serve
voluntarily and without compensation. They are not necessarily mem-
bers 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 in-
terest 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 pro-
duce, test, measure, purchase, market, or provide other goods and ser-
vices related to the scope of the IEEE Standard. Furthermore, the view-
point 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 Stan-
dard 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 to 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. Sug-
gestions 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 mean-
ing 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 to 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 con-
currence of a balance of interests. For this reason IEEE and the mem-
bers of its technical committees are not able to provide an instant re-
sponse to interpretation requests except in those cases where the matter
has previously received formal consideration.
Comments on standards and requests for interpretations should be ad-
dressed 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 require-
ments. 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 sug-
gest 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 to 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 organiza-
(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 soft-
ware product
is
to do. The complete description of the functions to 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 con-
tract, 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 to transfer the software to other parts of their organiza-
tion, 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.
tions.
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'c turers 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:
James
H.
Beall,
Chairman
Edward Chelotti,
Vice Chairman
J.
J.
Archambault
John
T.
Boettger
J.
V.
Bonucchi
Rene Castenschiold
Edward J. Cohen
Len
S.
Corey
Donald C. Fleckenstein
Jay Forster
Sava I. Sherr,
Secretary
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
SECTION
PAGE
.
.....................................................
1
ScopeandOrganization
9
1.1
Scope
...............................................................
9
1.2 Organization
..........................................................
9
2
.
References
...............................................................
9
3
.
Definitions
...............................................................
10
4
.
Background Information for Writing a Good SRS
..................................
10
4.1 TheSRS
.............................................................
10
4.2 Environment of the SRS
.................................................
10
4.3 Characteristics
of
a Good SRS
............................................
11
4.3.1 Unambiguous
....................................................
11
4.3.1.1 Natural Language Pitfalls
....................................
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
4.6.1 Formal Specification Methcodologies
..................................
14
4.6.2 Production Tools
.................................................
14
4.6.3 Representation Tools
..............................................
14
5
.
SoftwareRequirements
......................................................
14
5.1 Methods Used to Express Software Requirements
.............................
14
5.1.1 Input/Output Specifications
........................................
14
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
5.1.3.2 Functional Models
.........................................
15
5.1.3.3 TimingModels
............................................
15
5.1.3.4 OtherModels
.............................................
16
5.1.3.5 Cautions
.................................................
16
5.2 Annotation of the Software Requirements
...................................
16
5.2.1 Stability
........................................................
17
5.2.2 Degree of Necessity
...............................................
17
5.2.3 Annotation Caution
...............................................
17
5.3.1 Embedding Design
in
the SRS
.......................................
17
5.3.2 Embedding Project Requirements in the SRS
...........................
17
6
.
An SRS Prototype Outline
...................................................
18
6.1 Introduction (Section
1
of
the SRS)
........................................
18
6.1.1 Purpose
(1.1
of the SRS)
...........................................
18
6.1.2 Scope (1.2 of the SRS)
............................................
18
6.1.3 Definitions, Acronyms. and Abbreviations
(1.3
of the SRS)
................
18
4.3.1.2 Formal Requiremlents Specifications Languages
..
:
................
11
5.3 Common Pitfalls Encountered in Expressing Requirements
......................
17
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
of
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
6.3.1
6.3 The Specific Requirements (Section
3
of
the SRS)
.............................
20
Information Required as Part
of
the Specific Requirements
................
20
6.3.1.1 Functional Requirements
....................................
20
6.3.1.2 Performance Requirements
..................................
21
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
6.4 Supporting Information
.................................................
24
FIGURES
Fig
1
A Functional Model Specifying Any Sequence
of
Alternating
0’s
and 1’s
.............
16
TABLES
Table
1
Prototype SRS Outline
..................................................
18
Table 2 Prototype Outline
1
for SRS Section
3
.....................................
23
Table 3 Prototype Outline 2 for SRS Section
3
.....................................
23
Table 4 Prototype Outline
3
for SRS Se’ction
3
.....................................
24
Table
5
Prototype Outline 4 for SRS Se’ction
3
.....................................
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
1.
Scope and Organization
1.1
Scope. This is a guide for writing software
requirements specifications. It describer; the
necessary content and qualities of a good Soft-
ware Requirements Specification (SRS) and
presents a prototype SRS outline.
This guide does not specify industry,-wide
SRS standards nor state mandatory SRS re-
quirements. 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 to in-house and com-
mercial software products. Special care, how-
ever, should be used in its application beca.use:
(1)
This guide is aimed at specifying require-
ments
of
software to be developed. Application
of this material to 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.
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 informa-
tion 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 proto-
type outlines.
2.
References
[l]
ANSI/IEEE Std
100-1977,
IEEE Standard
Dictionary of Electrical and Electronics Terms.
[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.
[6]
DAVIS,
A.,
The Design of a Family of Ap-
plications-Oriented Requirements Languages,
ZEEE Computer,
15,5
May
1982,
pp
21-28.
[7]
FREEDMAN, D. and WEINBERG, G.,
Handbook of Walkthroughs,
Inspections and
Technical Reviews,
3rd Ed, Little and Brown
Publishers, New York.
[8]
KAIN,
R.,
Automata Theory: Machines
and Languages, McGraw Hill, New York,
1972.
[9]
KOHAVI,
Z.,
Switching and Finite Auto-
mata Theory, McGraw Hill, New York,
1970.
[
101
KRAMER,
J.,
Editor, Application Ori-
ented Specifications Glossary of Terms,
Euro-
pean Workshop on 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
[ll]
MILLS, G., and WALTER, J.,
Technical
Writing,
New York, Holt, Rinehart and Win-
ston, 4th Ed,
1978.
[
121
PETERSON,
J.,
Petri Nets,
ACM Comput-
ing Surveys,
9,4,
Dec
1977,
pp
223-252.
[13]
RAMAMOORHY, C. and
SO,
H. H.,
Soft-
ware Requirements and Specifications: Status
and
Perspectives,
Tutorial: Software Method-
ology, RAMAMOORTHY, C. and YEH, R. T.,
Editors. IEEE Catalog no EH0
142-0,
1978,
[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.
[
151
TEICHROEW,
D.,
A Survey of Languages
for Stating Requirements for Computer-Based
Information Systems,
1972
Fall Joint Cornputer
Conference,
1972,
pp
1203-1224.
pp
43-164.
3.
Definitions
Except for the definitions listed below, the
definitions of all terms used in this guidle con-
form to the definitions provided in IEEE Std
729-1983
[
312,
for example, the terms require-
ment, 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.
contract. A legally binding document agreed
upon by the customer and supplier. This in-
cludes 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 to convey information.
partitioning. Decomposition; the separation of
the whole into its parts.
2Numbers in brackets correspond to those of the
references
in
Section
2.
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.
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)
.
4.
Background Information for
Writing a Good
SRS
This section provides background information
necessary for writing an SRS. This includes:
(1)
Examination
of
the nature of the
SRS
(2)
Environmental considerations surround-
(3)
Characteristics required for a good SRS
(4)
Recommendations for joint preparation
(5)
Evolutionary aspects of the
SRS
(6)
The use of automated tools to develop an
SRS
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/
The description places two basic requirements
on the SRS:
(1)
It must say certain things. For example,
software developed from an SRS that fails to
specify that error messages will be provided,
will probably fail to satisfy the customer.
(2)
It must say those things in certain ways.
For example, software developed from an
SRS
that fails to 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 per-
son can be a severe aggravation to another
person.
For recommended contents of an SRS see
Section
6.
4.2
Environment of the
SRS.
It is important to
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.
ing the SRS
of an SRS
IEEE Std
730-1981 [2], 3.4.2.1.
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
IEEE GUIDE TO SOFTWARE
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
to be determined
(TBD) is not a
complete
SRS.
(1)
The TBD is, however, occasionally neces-
sary 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
veri-
fiable. 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 im-
possible.
(c)
The output
of
the program shall usually
be given within
10
s.
This requirement
is
non-
verifiable because the term
usually
cannot be
measured.
(2)
An
example of a verifiable statement is
The output
of
the program shall be given with-
in
20
s
of
event
X,
60%
of
the time; ana' shall
be given within
30
s
of
event
X,
100%
of
the
time.
This statement can be verified because it
uses concrete terms and measurable quant,ities.
(3)
If a method cannot be devised to deter-
mine whether the software meets a part,icular
requirement, then that requirement should be
removed or revised.
(4)
If a requirement is not expressible in veri-
fiable 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 con-
flict between two specified actions. For ex-
ample:
(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 organiza-
tion, with a table of contents, an index,, and
explicit cross-referencing.
(2)Not be redundant; that is, the same re-
quirement should not appear in more than one
place in the
SRS.
(a) Redundancy itself is not an error, but it
can easily lead to errors. Redundancy can occa-
sionally 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 loca-
tions. The SRS then becomes inconsistent.
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.
REQUIREMENTS SPECIFICATIONS IEEE
Std 830-1984
(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 :require-
ment in future development or enhancement
documentation. Two types of traceability are
recommended:
(1)
Backward traceability (that is, to previous
stages of development) depends upoln each
requirement explicitly referencing its source in
previous documents.
(2)
Forward traceability (that is, to all docu-
ments 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 re-
quirement, both forward and backward trace-
ability should be provided. Examples include:
4.3.6.1
The allocation of response time to
a
data base function from the overall user re-
sponse time requirement.
4.3.6.2
The identification of a report for-
mat 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 ad-
ministrative document that is being supported
should be identified.
The forward traceability of the
SRS
is espe-
cially important when the software product
enters the operation and maintenance phase.
As code and design documents are modlified, it
is essential to be able to ascertain the complete
set of requirements that may be affected by
those modifications.
4.3.7
Usable During the Operation and Main-
tenance Phase. The
SRS
must address thle needs
of the operation and maintenance phLase, in-
cluding the eventual replacement of the soft-
ware.
(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 es-
sential. This implies two actions
(a) The
SRS
should be modifiable as indi-
cated in
4.3.5.
(b) The
SRS
should contain a record of all
special provisions that apply to individual com-
ponents such as:
(i) Their criticality (for example, where
failure could impact safety or cause large finan-
cial or social losses).
(ii) Their relation to only temporary
needs (for example, to support a display that
may be retired soon).
(iii) Their origin (for example, function
X
is to 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 organi-
zation. If the reason for or origin of a function
is not understood, it is frequently impossible to
perform adequate software maintenance on it.
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 to write a good
SRS
by himself.
(1)
Customers usually do not understand the
software design and development process well
enough to write a usable SRS.
(2)
Suppliers usually do not understand the
customer’s problem and field
of
endeavor well
enough to specify requirements for a satisfac-
tory system.
The customer and the supplier need to work
together to produce a well written and com-
pletely understood
SRS.4
4.5
SRS
Evolution. The
SRS
may need to evolve
as the development of the software product
progresses.
(1)
It may be impossible to specify some
details at the time the project is initiated. For
example, it may be impossible to define during
the Requirements Phase, all of the screen for-
mats for an interactive program in a manner
that guarantees that they will not be altered
later.
(2)
Additional changes may ensue as deficien-
4This guide does not specifically discuss style, lan-
guage 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 [ll].
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
cies, shortcomings, and inaccuracies are dis-
covered 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 inevit-
able. 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 super-
seded portions of the SRS.
4.6
Tools for Developing
an
SRS.
The most
obvious way to create an
SRS
is to write it in a
natural language (for example, English). But be-
cause natural languages are rich, although
im-
precise, a number of more formal methods
have been devised to assist SRS writers.
4.6.1
Formal Specification Methodologies.
The degree to 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 to describe
or
en-
dorse 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 pro-
cess.
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
5For detailed discussion
on
this topic, see,
for
ex-
ample,
[6],[13],
[14],and
[15].
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 sys-
tem. There are several advantages to identify-
ing them as such.
(1)
It is possible to 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 to identify every place in the
specification where a particular entity or action
is described.
In addition, it may be desirable to formalize
the English structure in some way to 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 re-
quirements 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 hierar-
chical layer.
4.6.3.3
Automatically check that the SRS
possesses some or all of the characteristics
described in
4.3.
5.
Software Requirements
Each software requirement in an SRS is a
statement of some essential capability of the
software to be developed. The following sub-
sections describe:
(1)
Methods used to express software require-
ments
(2)
Annotation of the software requirements
(3)
Common pitfalls encountered in the pro-
cess
5.1
Methods Used
To
Express Software Re-
quirements. 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. It is often
effective to specify the required behavior of a
software product as a sequence of inputs and
outputs.
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.
REQUIREMENTS SPECIFICATIONS IEEE
Std
830-1984
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:; report-
ing systems) are best specified by focusing on
required outputs. In general, output -focused
systems operate primarily on data files. User in-
put usually serves to provide control informa-
tion 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 to 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 to remember their be-
havior
so
that they can respond to
am
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.
5.1.1.2
Difficulties. Most software products
can receive an infinite number of sequences as
input. Thus, to 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 con-
ceivable behavior that is required of the soft-
ware.
5.1.2
Representative Examples. One alterna-
tive is to indicate what behavior is required by
using representative examples of that behavior.
Suppose, for example, that the system is re-
quired to 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 to 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
required inputs and outputs but they do not
specify the system’s behavior completely.
5.1.3
Models. Another approach is to express
the requirements in the form of a model? This
can be an accurate and efficient way to express
complex requirements.
At least three generalized types of models are
in common usage:
(1)
Mathematical
(2)
Functional
(3)
Timing
Care should be taken to distinguish between
the model for the application; that is, a linear
programming model (with a set of linear in-
equalities 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
mathemat-
ical model is a model that uses mathematical
relations to describe the software’s behavior.
Mathematical models are especially useful for
particular application areas, including naviga-
tion, linear programming, econometrics, signal
processing and weather analysis.
A
mathematical model might specify the
response discussed
in
5.1.2
like this:
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 to outputs. Functional models, for ex-
ample, finite state machines or Petri nets can
help identify and define various features of the
software or can demonstrate the intended oper-
ation of the system.
A
functional model might specify the re-
sponse, i?reviously described by the rnathemat-
ical model,
in
the form of a finite state machine
as shown in Fig
1.
In this figure, the incoming
arrow points to 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.
(01)*
6Each of the four sample dialogues given :here (one
per line) represents a sequence
of
one-character user ‘For details on using modeling techniques, see
[
51,
inputs and one-character system outputs.
PI,
[gl, 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
Is
A timing model might add these constraints
to 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 to the
aforementioned, specific applications hiave
particularly helpful models. For example, a
compiler specification might employ
attribute
grammars, or a payroll system might use tables.
It is to be noted that the use of a formal re-
quirements 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 et ers
(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 to keep a model clefi-
nition within the domain of requirements.
Whenever an
SRS
uses a model:
(a) It means that the model provided an
especially efficient and accurate way to specify
the requirements
(b) It does not mean that the implementa-
tion 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 implementa-
tion.
5.2
Annotation of the Software Requirements.
Typically, all of the requirements that relate to
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 to make these differences
in
relative
importance clear and explicit.
(2)
Annotating the requirements
in
this man-
ner, helps:
(a) Customers to give more careful consid-
eration to each requirement, which often clari-
fies 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.
REQUIREMENTS SPECIFICATIONS IEEE
Std
830-1984
effort to the different parts of the software
product.
5.2.1
Stability. One method of annotating re-
quirements 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 to change.
5.2.2
Degree of Necessity. Another way to
annotate is to distinguish classes of require-
ments 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 require-
ments 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 to 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 annota-
tions, 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 soft-
ware functions, etc
(c)
Design Constraints Imposed on an Im-
plementation
-any required standards in effect,
implementation language, policies for d<ata base
integrity, resource limits, operating environ-
ment(s), etc
(d)
Attributes
-
considerations of portabil-
ity, correctness, maintainability, security, etc
(e)
External Interfaces
-
interactiolns with
people, hardware, other software and other
hardware
(2)
The requirements writer should avoid
placing either design or project requirements in
the
SRS.
The requirements writer should clearly
distinguish between identifying required design
constraints and projecting a design.
5.3.1
Embedding Design in the
SRS.
Embed-
ding 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
to be performed on what data to 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 to the modules
(c) Describing the flow of information or
(d) Choosing data structures
control between modules
(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 to
(a) Keep certain functions in separate
modules
(b) Permit only limited communication
between some areas of the program
(c) Compute check sums for critical quan-
tities
In general, it must be considered that the se-
lection of
an
appropriate high-level design for
the software may require vast amounts of re-
sources (perhaps as much as
10%
to
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 per-
formed 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 require-
ments and not intended to serve as the actual
design.
5.3.2
Embedding Project Requirements in
the
SRS.
The
SRS
should address the software
product, not the process of producing the soft-
ware product.
(1)
Project requirements represent an under-
standing between a customer and a supplier
about the contractual matters pertaining to the
production of software (and thus should not be
17
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
included in the SRS). These normally include
such items
as:
(a) Cost
(b) Delivery schedules
(c) Reporting procedures
(d) Software development methods
(e) Quality assurance
(f)
Validation and verification criteria
(g) Acceptance procedures
(2)
Project requirements are specified in other
documents, typically in a computer program
development plan or a statement
of
work. The
requirements for only the software product
itself are given in the SRS.
6.
An
SRS
Prototype Outline
This section discusses each
of
the essential
parts of the
SRS.
These parts are arranged in
Table
1
in an outline that can serve as a prloto-
type for any
SRS.
Software suppliers and customers should
tailor the content requirements of this guide
based on the particular package being speci-
fied, and individual companies might base their
own SRS standards upon it. Remember that
while an SRS does not have to follow this 'out-
line or use the names for its parts, any good
SRS must include all of the information dis-
cussed here.
6.1
Introduction (Section
1
of
the
SRS).
The
following subsections
of
the SRS should
pro-
vide an overview of the entire SRS.
Table
1
Prototype
SRS
Outline
Table of Contents
1.
Introduction
1.1 Purpose
1.2 Scope
1.3 Definitions, Acronyms, and Abbreviations
1.4 References
1.5 Overview
2. General Description
2.1 Product Perspective
2.2 Product Functions
2.3 User Characteristics
2.4 General Constraints
2.5 Assumptions and Dependencies
(See 6.3.2 of this guide for alternate organiza-
tions of this section of the SRS.)
3. Specific Requirements
Appendixes
Index
18
IEEE GUIDE TO SOFTWARE
6.1.1
Purpose
(1.1
of the
SRS).
This subsec-
tion should accomplish the following:
(1)
Delineate the purpose of the particular
SRS
(2)
Specify the intended audience for the
SRS
6.1.2
Scope
(1.2
of the
SRS).
This subsection
should:
(1)
Identify the software product(s) to be
produced by name; for example, Host DBMS,
Report Generator, etc
(2)
Explain what the software product(s) will,
and, if necessary, will not do
(3)
Describe the application of the software
being specified. As a portion of this, it should:
(a) Describe all relevant benefits, objectives,
and goals as precisely as possible. For example,
to say that one goal is to provide
effective
reporting capabilities
is not as good as saying
parameter-driven, user-definable reports with a
2
h turnaround and on-line entry
of
user
parameters.
(b) Be consistent with similar statements in
higher-level specifications (for example, the
System Requirement Specification)
,
if
they
exist.
6.1.3
Definitions, Acronyms,
and
Abbrevia-
tions
(1.3
of
the
SRS).
This subsection should
provide the definitions of all terms, acronyms,
and abbreviations required to properly interpret
the SRS. This information may be provided by
reference to one or more appendixes in the
SRS or by reference to other documents.
6.1.4
References
(1.4
of the
SRS).
This sub-
section should:
(1)
Provide a complete list of all documents
referenced elsewhere in the SRS, or in a separate,
specified document.
(2)
Identify each document by title, report
number
-
if
applicable
-
date, and publishing
organization.
(3)
Specify the sources from which the refer-
ences can be obtained.
This information may be provided by refer-
ence to an appendix
or
to another document.
6.1.5
Overview
(1.5
of
the
SRS).
This subsec-
tion should:
(1)
Describe what the rest of the SRS con-
tains
(2)
Explain how the SRS is organized
6.2
The General Description (Section
2
of
the
SRS).
This section of the SRS should describe
the general factors that affect 'the product and
its requirements.
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.
REQUIREMENTS SPECIFICATIONS IEEE
Std
830-1984
This section usually consists of five subsec-
(1)
Product Perspective
(2)
Product Functions
(3)
User Characteristics
(4)
General Constraints
(5)
Assumptions and Dependencies
It should be made clear that this section does
not state specific requirements; it only makes
those requirements easier to understand.
6.2.1
Product Perspective
(2.1
of the!
SRS).
This subsection of the
SRS
puts the product
into perspective with other related products or
projects.
(1)
If the product is independent and totally
self-contained, it should be stated here.
(2)
If the
SRS
defines a product that is a
component of a larger system or project
-
as
frequently occurs
-
then this subsection
should:
(a) Describe the functions of each compo-
nent of the larger system or project, and identify
interfaces
(b) Identify the principal external inter-
faces of this software product.
NOTE: This is not a detailed description
of
these inter-
faces;
the detailed description is provided elsewhere in
the SRS.
tions, as follows:
(c) Describe the computer hardware and
peripheral equipment to be used.
NOTE: This is an overview description only.
A block diagram showing the major compo-
nents of the larger system or project, intercon-
nections, and external interfaces can be very
helpful.
This subsection should not be used to impose
a specific design solution or specific design con-
straints on the solution. This subsection should
provide the reasons why certain design con-
straints are later specified as part of the Specific
Requirements Section of the SRS.
6.2.2
Product Functions
(2.2
of
the
SRS).
This subsection of the SRS should prolvide a
summary of the functions that the software
will perform. For example, an SRS for an
accounting program might use this part to ad-
dress
customer account maintenance, customer
statement and invoice preparation
without
mentioning the vast amount of detail thah each
of those functions requires.
Sometimes the function summary that is
necessary for this part can be taken directly
from the section of the higher-level specifica-
tion (if one exists) that allocates particular
functions to the software product. Note that,
for the sake of clarity:
(1)
The functions should be organized in a
way that makes the list of functions under-
standable to the customer or to anyone else
reading the document for the first time.
(2)
Block diagrams showing the different
functions and their relationships can be help-
ful. Remember, however, that such a diagram is
not a requirement on the design of a product
itself; it is simply an effective explanatory tool.
This subsection should not be used to state
specific requirements. This subsection should
provide the reasons why certain specific require-
ments are later specified as part of the Specific
Requirements Section(s) of the SRS.
6.2.3
User Characteristics
(2.3
of the
SRS).
This subsection of the SRS should describe
those general characteristics of the eventual
users of the product that will affect the specific
requirements.
Many people interact with a system during
the operation and maintenance phase of the
software life cycle. Some of these people are
users, operators, and maintenance and systems
personnel. Certain characteristics of these
people, such as educational level, experience,
and technical expertise impose important con-
straints on the system’s operating environment.
If most users of the system are occasional
users, a resulting specific requirement might be
that the system contains reminders of how to
perform essential functions rather than assuming
that the user will remember these details from
the last session or from reading the user’s guide.
This subsection should not be used to state
specific requirements
or
to impose specific
design constraints on the solution. This subsec-
tion should provide the reasons why certain
specific requirements or design constraints are
later specified as part of the Specific Require-
ments Section(s) of the SRS.
6.2.4
General Constraints
(2.4
of
the
SRS).
This subsection of the SRS should provide a
general description of any other items that will
limit the developer’s options for designing the
system. These can include:
(1)
Regulatory policies
(2)
Hardware limitations; for example,
signal timing requirements
(3)
Interfaces to other applications
(4)
Parallel operation
(5)
Audit functions
19
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
(6)
Control functions
(7)
Higherader language requirements
(8)
Signal handshake protocols; for example,
(9)
Criticality of the application
XON -XOFF, ACK
-
NACK.
(10)
Safety and security considerations
This subsection should not be used to impose
specific requirements or specific design con-
straints on the solution. This subsection should
provide the reasons why certain specific require-
ments or design constraints are later specified
as part of the Specific Requirements Section of
the SRS.
6.2.5
Assumptions and Dependencies
(2.!5
of
the SRS). This subsection of the SRS should
list each of the factors that affect the require-
ments stated in the SRS. These factors are not
design constraints on the software but are,
rather, any changes to them that can affect the
requirements in the SRS. For example, an. as-
sumption might be that a specific operating
system will be available on the hardware desig-
nated for the software product. If, in fact, the
operating system is not available, the SRS
would then have to change accordingly.
6.3
The Specific Requirements (Section
51
of
the
SRS).
This section of the SRS should con-
tain all the details the software developer needs
to create a design. This is typically the larlgest
and most important part
of
the SRS.
(1)
The details within it should be defineld as
individual specific requirements, following the
guidelines described in Section
3
of this guide
(verifiable, unambiguous, etc)
(2)
Background should be provided by cross-
referencing each specific requirement to any
related discussion in the Introduction, General
Description, and Appendixes portions of the
SRS, whenever possible.
(3)
One way to classify the specific require-
ments is as follows:
(a) Functional Requirements
(b) Performance Requirements
(c) Design Constraints
(d) Attributes
(e) External Interface Requirements
The important points to be recognized are
that:
(1)
Specific requirements should be organized
in a logical and readable fashion.
(2)
Each requirement should be stated such
that its achievement can be objectively verified
by a prescribed method.
6.3.1
Information Required as Part
of
the
Specific Requirements
6.3.1.1
Functional Requirements. This sub-
section of the SRS should specify how the
inputs to the software product should be trans-
formed into outputs. It describes the funda-
mental actions that must take place in the
software.
For each class of function or sometimes for
each individual function, it is necessary to
specify requirements on inputs, processing, and
outputs. These are usually organized with these
four subparagraphs:
(1)
Introduction. This subparagraph should
provide a description of the purpose of the
function and the approaches and techniques
employed. It should contain any introductory
or background material which might clarify the
intent of the function.
(2)
Inputs. This subparagraph should contain:
(a)
A
detailed description of all data input
to this function to include:
(i)
The sources
of
the inputs
(ii) Quantities
(iii) Units of measure
(iv) Timing
(v)
The ranges of the valid inputs to in-
clude accuracies and tolerances.
(b) The details of operator control require-
ments should include names and descriptions
of operator actions, and console or operator
positions. For example, this might include
required operator activities such as form align-
ment
-
when printing checks.
(c) References to interface specifications or
interface control documents where appropriate.
(3)
Processing. This subparagraph should de-
fine all of the operations to be performed on
the input data and intermediate parameters to
obtain the output.
It
includes specification of:
(a) Validity checks on the input data
(b)
The exact sequence of operations to in-
(c) Responses to
abnormal
situations, for
clude timing of events
example:
(i) Overflow
(ii) Communication failure
(iii) Error handling
(d) Parameters affected by the operations
(e) Requirements for degraded operation
(f)
Any
methods (for example, equations,
mathematical algorithms, and logical opera-
tions) which must be used to transform the sys-
tem inputs into corresponding outputs. For
20
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.
REQUIREMENTS SPECIFICATIONS IEEE
Std
830-1984
example, this might specify:
holding
tax
in a payroll package
for a plotting package
for a weather forecasting package
(i) The formula for computing the with-
(ii)
A
least squares curve fitting technique
(iii)
A
meteorological model to be used
(g)
Validity checks on the output data
(4)
Outputs. This subparagraph should con-
(a) A detailed description of all data out-
tain
:
put from this function to include:
(i) Destinations of the outputs
(ii) Quantities
(iii) Units of measure
(iv) Timing
(v) The range of the valid outputs is to
(vi) Disposition of illegal values
(vii) Error messages
include accuracies and tolerances
(b) References to interface specifications or
interface control documents where appropriate
In addition, for those systems whose require-
ments focus on input/output behavior, the SRS
should specify all of the significant input/out-
put pairs and sequences of pairs. Sequences will
be needed when a system is required to remem-
ber its behavior
so
that it can respond to an in-
put based on that input and past behavior; that
is, behave like a finite state machine.
6.3.1.2
Performance Requirement:;. This
subsection should specify both the static and
the dynamic numerical requirements placed on
the software or on human interaction with the
software, as a whole.
(1)
Static numerical requirements may in-
clude:
(a) The number of terminals to be supported
(b) The number of simultaneous users to be
(c) Number of files and records to be
(d) Sizes of tables and files
supported
handled
Static numerical requirements are sometimes
identified under a separate section entitled
capacity
.
(2)
Dynamic numerical requirements may in-
clude, for example, the numbers of transactions
and tasks and the amount of data to 'be pro-
cessed within certain time periods for both
normal and peak workload conditions.
All of these requirements should be dated in
measurable terms, for example,
95%
of
the
transactions shall be processed in
less
than
1
s,
rather than,
operator shall not have
to
wait
for
the transaction to complete.
NOTE: Numerical limits applied to one specific func-
tion are normally specified as part
of
the processing
subparagraph description
of
that function.
6.3.1.3
Design Constraints. Design con-
straints can be imposed by other standards,
hardware limitations, etc.
6.3.1.3.1
Standards Compliance. This
subsection should specify the requirements
derived from existing standards or regulations.
They might include:
(1)
Report format
(2)
Data naming
(3)
Accounting procedures
(4)
Audit Tracing. For example, this could
specify the requirement for software
to
trace
processing activity. Such traces are needed for
some applications to meet minimum govern-
ment or financial standards. An audit trace
requirement might, for example, state that all
changes to a payroll data base must be recorded
in a trace file with before and after values.
6.3.1.3.2
Hardware Limitations. This
subsection could include requirements for the
software to operate inside various hardware
constraints. For example, these could include:
(1)
Hardware configuration characteristics
(number of ports, instruction sets, etc)
(2)
Limits on primary and secondary memory
6.3.1.4
Attributes. There are a number of
attributes that can place specific requirements
on the software. Some of these are indicated
below. These should not be interpreted to be a
complete list.
6.3.1.4.1
Availability. This could specify
the factors required to guarantee a defined
availability level for the entire system such as
checkpoint, recovery and restart.
6.3.1.4.2
Security. This could specify the
factors that would protect the software from
accidental or malicious access, use, modifica-
tion, destruction, or disclosure. Specific require-
ments in this area could include the need to:
(1)
Utilize certain cryptographical techniques
(2)
Keep specific log or history data sets
(3)
Assign certain functions to different
(4)
Restrict communications between some
(5)
Compute checksums for critical quantities
6.3.1.4.3
Maintainability. This could
specify the requirements to ensure that the
modules
areas
of
a program
21
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
software could be maintained. For example, as
a part of this,
(1)
Specific coupling metrics for the software
modules could be required
(2)
Specific data/program partitioning re-
quirements could be specified for microdevices
6.3.1.4.4
Transferability/Conversion.
This
could specify the user procedures, user irker-
face compatibility constraints (if any) etc, re-
quired to transport the software from one
environment to another.
6.3.1.4.5
Caution. It is important that
required attributes be specified
so
that their
achievement can be objectively verified by a
prescribed method.
6.3.1.5
External Interface Requirements
6.3.1.5.1
User Interfaces. This should
specify:
(1)
The characteristics that the software must
support for each human interface to the soft-
ware product. For example, if the user of the
system operates through a display terminal, the
following should be specified:
(a) Required screen formats
(b) Page layout and content of any reports
(c) Relative timing of inputs and outputs
(d) Availability of some form of program-
mable function keys
(2)
All the aspects of optimizing the inter€ace
with the person who must use the system. This
may simply comprise a list of do’s and don’ts
on how the system will appear to the user. One
example might be a requirement for the option
of long or short error messages. Like all othlers,
these requirements should be verifiable and for
example,
a clerk typist grade
4
can
do
function
X in
2
min
after
1
h
of
training
rather than
a
typist
can
do function
X.
(This might also be
specified in the Attributes section under a
section titled
Ease
of
Use.)
6.3.1.5.2
Hardware 1nterfaces.Thi.s should
specify the logical characteristics of each inter-
face between the software product and the
hardware components of the system.
It
also
covers such matters as what devices are to be
supported, how they are to be supported, and
protocols. For example, terminal support
might specify full screen support as opposed to
line by line.
6.3.1.5.3
Software Interfaces. This should
specify the use of other required software
products (for example, a data management
system, an operating system, or a mathematical
package), and interfaces with other application
or menus
systems (for example, the linkage between an
accounts receivable system and a general ledger
system).
For each required software product, the fol-
lowing should be provided:
(1)
Name
(2)
Mnemonic
(3)
Specification number
(4)
Version number
(5)
Source
For each interface, this part should:
(1)
Discuss the purpose of the interfacing
software as related to this software product.
(2)
Define the interface in terms of message
content and format. It
is
not necessary to detail
any welldocumented interface, but a reference
to the document defining the interface is
required.
6.3.1.5.4
Communications Interfaces.
This should specify the various interfaces to
communications such as local network proto-
cols, etc.
6.3.1.6
Other Requirements. Certain re-
quirements may, due to the nature of the soft-
ware, the user organization, etc, be placed in
separate categories
as
indicated below.
6.3.1.6.1
Data Base. This could specify
the requirements for any data base that is to be
developed
as
part of the product. This might
include:
(1)
The types of information identified in
6.3.1.1
(2)
Frequency of use
(3)
Accessing capabilities
(4)
Data element and file descriptors
(5)
Relationship of data elements, records
(6)
Static and dynamic organization
(7)
Retention requirements for data
and files
NOTE: If an existing data base package is to be used,
this package should be named under
Interfaces to Soft-
ware
and details of using it specified there.
6.3.1.6.2
Operations. This could specify
the normal and special operations required by
the user such as:
(1)The various modes of operations in the
user organization; for example, user-initiated
operations
(2)
Periods of interactive operations and
periods of unattended operations
(3)
Data processing support functions
(4)
Backup and recovery operations
NOTE: This is sometimes specified as part of the User
Interfaces section.
22
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.
REQUIREMENTS SPECIFICATIONS IEEE
Std
830-1984
6.3.1.6.3
Site Adaptation Requirements.
This could:
(1)
Define the requirements for any data or
initialization sequences that are specific to a
given site, mission, or operational mode, for
example, grid values, safety limits, etc.
(2)
Specify the site or mission-related features
that should be modified to adapt the sclftware
to a particular installation.
6.3.2
Organizing The Specific Requirements.
This subsection
is
often the largest and most
complex of all the parts of the
SRS.
(1)
It may be necessary to organize this sec-
tion into subdivisions according to the primary
classes of functions to be performed by the
software. For example, consider a large inter-
active accounting system. This may be broken
down at the top level into operational software
(which supports near-real-time transactions),
support software (logging functions, disk back-
up, loading tapes, etc), and diagnostic software
(primarily hardware and communications sup-
port), and at the next level into accounts re-
ceivable, accounts payable, etc.
(2)
It
should be remembered, however, that
the purpose of this subdivided organization is
to improve the readability of the SRS, not to
define the high level design of the software
being specified.
The best organization for Section
3,
Specific
Requirements, in an SRS, depends on the
application area and the nature of the so€tware
product being specified. Tables
2
through
4
show four possible organizations.
(1)
In Prototype Outline
1
(Table
2),
a11 the
Functional Requirements are specified, then
the four types of interface requirements are
specified, and then the rest of the requirements
are specified.
(2)
Prototype Outline
2
(Table
3)
shows the
four classes of interface requirements alpplied
to each individual Functional Requirement.
This is followed by the specification of the
rest of the requirements.
(3)
In Prototype Outline
3
(Table
4),
all of
the issues addressed by the Functional Require-
ments are specified, then the other requirements
that apply to them are specified. This patitern is
then repeated for each of the External Inter-
face Requirement Classifications.
Table
2
Prototype Outline
1
for SRS Section
3
3.
Specific Requirements
3.1
Functional Requirements
3.1.1
Functional Requirement
1
3.1.1.1
Introduction
3.1.1.2
Inputs
3.1.1.3
Processing
3.1.1.4
Outputs
3.1.2
Functional Requirement
2
3.1.n
Functional Requirement
n
3.2
External Interface Requirements
3.2.1
User Interfaces
3.2.2
Hardware Interfaces
3.2.3
Software Interfaces
3.2.4
Communications Interfaces
3.3
Performance Requirements
3.4
Design Constraints
....
3.4.1
Standards Compliance
3.4.2
Hardware Limitations
....
3.5
Attributes
3.5.1
Security
3.5.2
Maintainability
....
3.6
Other Requirements
3.6.1
Data Base
3.6.2
Operations
3.6.3
Site Adaptation
....
Table
3
Prototype Outline
2
for
SRS
Section
3
3.1
Functional Requirements
3.
Specific Requirements
3.1.1
Functional Requirement
1
3.1.1.1
Specification
3.1.1.1.1
Introduction
3.1.1.1.2
Inputs
3.1.1.1.3
Processing
3.1.1.1.4
Outputs
3.1.1.2
External Interfaces
3.1.1.2.1
User Interfaces
3.1.1.2.2
Hardware
Interfaces
3.1.1.2.3
Software
Interfaces
3.1.1.2.4
Communication
Interfaces
3.1.2
Functional Requirement
2
3.l.n
Functional Requirement
n
3.2
Performance Requirements
3.3
Design Constraints
3.4
Attributes
3.4.1
Security
3.4.2
Maintainability
....
3.5
Other Requirements
3.5.1
Data Base
3.5.2
Operations
3.5.3
Site Adaption
....
23
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
Table
4
Prototype Outline
3
for
SRS
Section
3
-
3. Specific Requirements
3.1 Functional Requirements
3.1.1 Functional Requirement 1
3.1.1.1 Introduction
3.1.1.2 Inputs
3.1.1.3 Processing
3.1.1.4 Outputs
3.1.1.5 Performance Requirements
3.1.1.6 Design Constraints
3.1.1.4.1 Standards
3.1.1.4.2 Hardware
Compliance
Limitations
....
3.1.1.7 Attributes
3.1.1.7.1 Security
3.1.1.7.2 Maintainabi1it.y
....
3.1.1.8 Other Requirements
3.1.1.8.1 Data Base
3.1.1.8.2 Operations
3.1.1.8.3 Site Adaption
.
.. .
3.1.2 Functional Requirement 2
3.l.n Functional Requirement
n
3.2.1 User Interfaces
....
3.2 External Interface Requirements
3.2.1.1 Performance Requirements
3.2.1.2 Design Constraints
3.2.1.2.1 Standards
3.2.1.2.2 Hardware
Compliance
Limitations
....
3.2.1.3 Attributes
3.2.1.3.1 Security
3.2.1.3.2 Maintainability
. .. .
3.2.1.4 Other Requirements
3.2.1.4.1 Data Base
3.2.1.4.2 Operations
3.2.1.4.3 Site Adaption
....
3.2.2 Hardware Interfaces
3.2.3 Software Interfaces
3.2.4 Communications Interfaces ~
(4)
In Prototype Outline
4
(Table
5),
the
interface requirements and the rest of the re-
quirements are specified as they pertain to e,ach
Functional Requirement.
The organization of the Specific Require-
ments Section of the
SRS
should be chosen
with the goal of properly specifying the re-
quirements in the most readable manner.
6.4
Supporting Information. The support,ing
information; that is, the Table
of
Contents, the
Appendixes, and the Index, make the
SRS
Table
5
Prototype Outline
4
for
SRS
Section
3
3. Specific Requirements
3.1 Functional Requirement 1
3.1.1 Introduction
3.1.2 Inputs
3.1.3 Processing
3.1.4 Outputs
3.1.5 External Interfaces
3.1.5.1 User Interfaces
3.1.5.2 Hardware Interfaces
3.1.5.3 Software Interfaces
3.1.5.4 Communication Interfaces
3.1.6 Performance Requirements
3.1.7 Design Constraints
3.1.8 Attributes
3.1.8.1 Security
3.1.8.2 Maintainability
....
3.1.9 Other Requirements
3.1.9.1 Data Base
3.1.9.2 Operations
3.1.9.3 Site Adaption
....
3.2 Functional Requirement 2
3.n Functional Requirement
n
.
...
important and should follow the generally
accepted rules for good documentation prac-
tices.8
(2)
The Appendixes are not always consid-
ered part of the actual requirements specifica-
tion and are not always necessary. They might
include:
(a) Sample
1/0
formats, descriptions of
cost analysis studies, or results of user surveys.
(b) Supporting or background information
that can help the readers of the SRS.
(c)
A
description of the problems to be
solved by the software.
(d) The history, background, experience
and operational characteristics
of
the organiza-
tion to be supported.
(e)
A
cross-reference list, arranged by mile-
stone, of those incomplete software require-
ments that are to be completed by specified
milestones. (See
4.3.2
and
4.3.3 (4).)
(f)
Special packaging instructions for the
code and the media to meet security, export,
initial loading, or other requirements.
(3)
When Appendixes are included, the SRS
should explicitly state whether or not the
Appendixes are to be considered part of the
requirements.
easier to use.
(1)
The Table
of
Contents and Index are quite
*See, for example:
[
4
J
and
[
11
]
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.

Navigation menu