ISEE software

IEEE Std 830-1998

(Revision of

IEEE Std 830-1993)

IEEE Recommended Practice for

Software Requirements

SpeciÞcations

Sponsor

Software Engineering Standards Committee

of the

IEEE Computer Society

Approved 25 June 1998

IEEE-SA Standards Board

Abstract: The content and qualities of a good software requirements specification (SRS) are de-

scribed and several sample SRS outlines are presented. This recommended practice is aimed at

specifying requirements of software to be developed but also can be applied to assist in the selec-

tion of in-house and commercial software products. Guidelines for compliance with IEEE/EIA

12207.1-1997 are also provided.

Keywords: contract, customer, prototyping, software requirements specification, supplier, system

requirements specifications

The Institute of Electrical and Electronics Engineers, Inc.

345 East 47th Street, New York, NY 10017-2394, USA

Copyright © 1998 by the Institute of Electrical and Electronics Engineers, Inc.

All rights reserved. Published 1998. Printed in the United States of America.

ISBN 0-7381-0332-2

No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior

written permission of the publisher.

IEEE Standards documents are developed within the IEEE Societies and the Standards Coordinat-

ing Committees of the IEEE Standards Association (IEEE-SA) 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 that have expressed an inter-

est 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 sub-

jected to review at least every Þve years for revision or reafÞrmation. When a document is more

than Þve years old and has not been reafÞrmed, it is reasonable to conclude that its contents,

although still of some value, do not wholly reßect 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 afÞliation 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 speciÞc applications. When the need for interpretations is brought to the attention of

IEEE, the Institute will initiate action to prepare appropriate responses. Since IEEE Standards rep-

resent a consensus of all 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

societies and Standards Coordinating 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-SA Standards Board

445 Hoes Lane

P.O. Box 1331

Piscataway, NJ 08855-1331

USA

Note: Attention is called to the possibility that implementation of this standard may

require use of subject matter covered by patent rights. By publication of this standard,

no position is taken with respect to the existence or validity of any patent rights in

connection therewith. The IEEE shall not be responsible for identifying patents for

which a license may be required by an IEEE standard or for conducting inquiries into

the legal validity or scope of those patents that are brought to its attention.

Authorization to photocopy portions of any individual standard for internal or personal use is

granted by the Institute of Electrical and Electronics Engineers, Inc., provided that the appropriate

fee is paid to Copyright Clearance Center. To arrange for payment of licensing fee, please contact

Copyright Clearance Center, Customer Service, 222 Rosewood Drive, Danvers, MA 01923 USA;

(978) 750-8400. Permission to photocopy portions of any individual standard for educational class-

room use can also be obtained through the Copyright Clearance Center.

Introduction

(This introduction is not a part of IEEE Std 830-1998, IEEE Recommended Practice for Software Requirements SpeciÞ-

cations.)

This recommended practice describes recommended approaches for the speciÞcation of software require-

ments. It is based on a model in which the result of the software requirements speciÞcation process is an

unambiguous and complete speciÞcation document. It should help

a) Software customers to accurately describe what they wish to obtain;

b) Software suppliers to understand exactly what the customer wants;

c) Individuals to accomplish the following goals:

1) Develop a standard software requirements speciÞcation (SRS) outline for their own organiza-

tions;

2) DeÞne the format and content of their speciÞc software requirements speciÞcations;

3) 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 should provide several speciÞc beneÞts, such

as the following:

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 to be performed by the software speciÞed

in the SRS will assist the potential users to determine if the software speciÞed meets their needs or

how the software must be modiÞed to meet their needs.

Ñ 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.

Ñ 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.

Ñ Provide a baseline for validation and veriÞcation. Organizations can develop their validation and

veriÞcation 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.

Ñ Facilitate transfer. The SRS makes it easier to transfer the software product to new users or new

machines. Customers thus Þnd it easier to transfer the software to other parts of their organization,

and suppliers Þnd it easier to transfer it to new customers.

Ñ Serve 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 Þnished product. The SRS may

need to be altered, but it does provide a foundation for continued production evaluation.

The readers of this document are referred to Annex B for guidelines for using this recommended practice to

meet the requirements of IEEE/EIA 12207.1-1997, IEEE/EIA GuideÑIndustry Implementation of ISO/IEC

12207: 1995, Standard for Information TechnologyÑSoftware life cycle processesÑLife cycle data. iii

Copyright © 1998 IEEE. All rights reserved.

Participants

This recommended practice was prepared by the Life Cycle Data Harmonization Working Group of the Soft-

ware Engineering Standards Committee of the IEEE Computer Society. At the time this recommended prac-

tice was approved, the working group consisted of the following members:

Leonard L. Tripp, Chair

Dennis Lawrence Terry Rout

Edward Byrne David Maibor Richard Schmidt

Paul R. Croll Ray Milovanovic Norman F. Schneidewind

Perry DeWeese James Moore David Schultz

Robin Fralick Timothy Niesen Basil Sherlund

Marilyn Ginsberg-Finner Dennis Rilling Peter Voldner

John Harauz Ronald Wade

Mark Henley

The following persons were on the balloting committee:

David A. Gustafson Indradeb P. Pal

Syed Ali Jon D. Hagar Alex Polack

Theodore K. Atchinson John Harauz Peter T. Poon

Mikhail Auguston Robert T. Harley Lawrence S. Przybylski

Robert E. Barry Herbert Hecht Kenneth R. Ptack

Leo Beltracchi William Heßey Annette D. Reilly

H. Ronald Berlack Manfred Hein Dennis Rilling

Richard E. Biehl Mark Heinrich Andrew P. Sage

Michael A. Blackledge Mark Henley Helmut Sandmayr

Sandro Bologna Debra Herrmann Stephen R. Schach

Juris Borzovs John W. Horch Hans Schaefer

Kathleen L. Briggs Jerry Huller Norman Schneidewind

M. Scott Buck Peter L. Hung David J. Schultz

Michael Caldwell George Jackelen Lisa A. Selmon

James E. Cardow Frank V. Jorgensen Robert W. Shillato

Enrico A. Carrara William S. Junk David M. Siefert

Lawrence Catchpole George X. Kambic Carl A. Singer

Keith Chan Richard Karcich James M. Sivak

Antonio M. Cicu Ron S. Kenett Richard S. Sky

Theo Clarke Judith S. Kerner Nancy M. Smith

Sylvain Clermont Robert J. Kierzyk Melford E. Smyre

Rosemary Coleman Dwayne L. Knirk Harry M. Sneed

Virgil Lee Cooper Shaye Koenig Alfred R. Sorkowitz

W. W. Geoff Cozens Thomas M. Kurihara Donald W. Sova

Paul R. Croll John B. Lane Luca Spotorno

Gregory T. Daich J. Dennis Lawrence Julia Stesney

Geoffrey Darnton Fang Ching Lim Fred J. Strauss

Taz Daughtrey William M. Lively Christine Brown Strysik

Bostjan K. Derganc James J. Longbucco Toru Takeshita

Perry R. DeWeese Dieter Look Richard H. Thayer

James Do John Lord Booker Thomas

Evelyn S. Dow Stan Magee Patricia Trellue

Carl Einar Dragstedt David Maibor Theodore J. Urbanowicz

Sherman Eagles Harold Mains Glenn D. Venables

Christof Ebert Robert A. Martin Udo Voges

Leo Egan Tomoo Matsubara David D. Walden

Richard E. Fairley Mike McAndrew Dolores Wallace

John W. Fendrich Patrick D. McCray William M. Walsh

Jay Forster Christopher McMacken John W. Walz

Kirby Fortenberry Jerome W. Mersky Camille SWhite-Partain

Eva Freund Bret Michael Scott A. Whitmire

Richard C. Fries Alan Miller P. A. Wolfgang

Roger U. Fujii Celia H. Modell Paul R. Work

Adel N. Ghannam James W. Moore Natalie C. Yopconka

Marilyn Ginsberg-Finner Pavol Navrat Janusz Zalewski

John Garth Glynn Myrna L. Olson Geraldine Zimmerman

Julio Gonzalez-Sanz Peter F. Zoll

L. M. Gunther

iv Copyright © 1998 IEEE. All rights reserved.

When the IEEE-SA Standards Board approved this recommended practice on 25 June 1998, it had the fol-

lowing membership:

Richard J. Holleman, Chair Donald N. Heirman, Vice Chair

Judith Gorman, Secretary L. Bruce McClung

James H. Gurney

Satish K. Aggarwal Louis-Fran•ois Pau

Jim D. Isaak

Clyde R. Camp Ronald C. Petersen

Lowell G. Johnson

James T. Carlo Gerald H. Peterson

Robert Kennelly

Gary R. Engmann John B. Posey

E. G. ÒAlÓ Kiener

Harold E. Epstein Gary S. Robinson

Joseph L. KoepÞnger*

Jay Forster* Hans E. Weinrich

Stephen R. Lambert

Thomas F. Garrity Donald W. Zipse

Jim Logothetis

Ruben D. Garzon Donald C. Loughry

*Member Emeritus Valerie E. Zelenty

IEEE Standards Project Editor v

Copyright © 1998 IEEE. All rights reserved.

Contents

1. Overview.............................................................................................................................................. 1

1.1 Scope............................................................................................................................................ 1

2. References............................................................................................................................................ 2

3. Definitions............................................................................................................................................ 2

4. Considerations for producing a good SRS........................................................................................... 3

4.1 Nature of the SRS ........................................................................................................................ 3

4.2 Environment of the SRS .............................................................................................................. 3

4.3 Characteristics of a good SRS...................................................................................................... 4

4.4 Joint preparation of the SRS ........................................................................................................ 8

4.5 SRS evolution .............................................................................................................................. 8

4.6 Prototyping................................................................................................................................... 9

4.7 Embedding design in the SRS...................................................................................................... 9

4.8 Embedding project requirements in the SRS ............................................................................. 10

5. The parts of an SRS ........................................................................................................................... 10

5.1 Introduction (Section 1 of the SRS)........................................................................................... 11

5.2 Overall description (Section 2 of the SRS)................................................................................ 12

5.3 Specific requirements (Section 3 of the SRS)............................................................................ 15

5.4 Supporting information.............................................................................................................. 19

Annex A (informative) SRS templates........................................................................................................ 21

Annex B (informative) Guidelines for compliance with IEEE/EIA 12207.1-1997.................................... 27

vi Copyright © 1998 IEEE. All rights reserved.

IEEE Recommended Practice for

Software Requirements

SpeciÞcations

1. Overview

This recommended practice describes recommended approaches for the speciÞcation of software require-

ments. It is divided into Þve clauses. Clause 1 explains the scope of this recommended practice. Clause 2

lists the references made to other standards. Clause 3 provides deÞnitions of speciÞc terms used. Clause 4

provides background information for writing a good SRS. Clause 5 discusses each of the essential parts of

an SRS. This recommended practice also has two annexes, one which provides alternate format templates,

and one which provides guidelines for compliance with IEEE/EIA 12207.1-1997.

1.1 Scope

This is a recommended practice for writing software requirements speciÞcations. It describes the content

and qualities of a good software requirements speciÞcation (SRS) and presents several sample SRS outlines.

This recommended practice is aimed at specifying requirements of software to be developed but also can be

applied to assist in the selection of in-house and commercial software products. However, application to

already-developed software could be counterproductive.

When software is embedded in some larger system, such as medical equipment, then issues beyond those

identiÞed in this recommended practice may have to be addressed.

This recommended practice describes the process of creating a product and the content of the product. The

product is an SRS. This recommended practice can be used to create such an SRS directly or can be used as

a model for a more speciÞc standard.

This recommended practice does not identify any speciÞc method, nomenclature, or tool for preparing an

SRS. 1

Copyright © 1998 IEEE. All rights reserved.

IEEE

Std 830-1998 IEEE RECOMMENDED PRACTICE FOR

2. References

This recommended practice shall be used in conjunction with the following publications.

1

ASTM E1340-96, Standard Guide for Rapid Prototyping of Computerized Systems. 2

IEEE Std 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology.

IEEE Std 730-1998, IEEE Standard for Software Quality Assurance Plans.

IEEE Std 730.1-1995, IEEE Guide for Software Quality Assurance Planning. 3

IEEE Std 828-1998, IEEE Standard for Software ConÞguration Management Plans.

IEEE Std 982.1-1988, IEEE Standard Dictionary of Measures to Produce Reliable Software.

IEEE Std 982.2-1988, IEEE Guide for the Use of IEEE Standard Dictionary of Measures to Produce Reli-

able Software.

IEEE Std 1002-1987 (Reaff 1992), IEEE Standard Taxonomy for Software Engineering Standards.

IEEE Std 1012-1998, IEEE Standard for Software VeriÞcation and Validation.

IEEE Std 1012a-1998, IEEE Standard for Software VeriÞcation and Validation: Content Map to IEEE/EIA

4

12207.1-1997. 5

IEEE Std 1016-1998, IEEE Recommended Practice for Software Design Descriptions.

IEEE Std 1028-1997, IEEE Standard for Software Reviews.

IEEE Std 1042-1987 (Reaff 1993), IEEE Guide to Software ConÞguration Management. 6

IEEE P1058/D2.1, Draft Standard for Software Project Management Plans, dated 5 August 1998.

IEEE Std 1058a-1998, IEEE Standard for Software Project Management Plans: Content Map to IEEE/EIA

7

12207.1-1997.

IEEE Std 1074-1997, IEEE Standard for Developing Software Life Cycle Processes. 8

IEEE Std 1233, 1998 Edition, IEEE Guide for Developing System Requirements SpeciÞcations.

1

ASTM publications are available fro