ISEE software

IEEE Std 830-1998

Revision of IEEE Std 830-1993

IEEE Recommended Practice for Software Requirements Specifications

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 described 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 selection 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 Coordinating 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 interest in participating in the development of the standard.

Use of an IEEE Standard is wholly voluntary. The existence of an IEEE Standard does not imply that there are no other ways to produce, test, measure, purchase, market, or provide other goods and services related to the scope of the IEEE Standard. Furthermore, the viewpoint expressed at the time a standard is approved and issued is subject to change brought about through developments in the state of the art and comments received from users of the standard. Every IEEE Standard is subjected to review at least 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. Suggestions for changes in documents should be in the form of a proposed change of text, together with appropriate supporting comments.

Interpretations: Occasionally questions may arise regarding the meaning of portions of standards as they relate to specific applications. When the need for interpretations is brought to the attention of IEEE, the Institute will initiate action to prepare appropriate responses. Since IEEE Standards represent 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 classroom 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 Specifications.)

This recommended practice describes recommended approaches for the specification of software requirements. It is based on a model in which the result of the software requirements specification process is an unambiguous and complete specification document. It should help

• Software customers to accurately describe what they wish to obtain;
• Software suppliers to understand exactly what the customer wants;
• Individuals to accomplish the following goals:
  • Develop a standard software requirements specification (SRS) outline for their own organizations;
  • Define the format and content of their specific software requirements specifications;
  • 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 specific benefits, 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 specified in the SRS will assist the potential users to determine if the software specified meets their needs or how the software must be modified 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 verification. Organizations can develop their validation and verification plans much more productively from a good SRS. As a part of the development contract, the SRS provides a baseline against which compliance can be measured.
• 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 organization, and suppliers find 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 finished 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 Software Engineering Standards Committee of the IEEE Computer Society. At the time this recommended practice 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 S White-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 following 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. Koepfinger*
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 Specifications

1. Overview

This recommended practice describes recommended approaches for the specification of software requirements. It is divided into five clauses. Clause 1 explains the scope of this recommended practice. Clause 2 lists the references made to other standards. Clause 3 provides definitions of specific 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 specifications. It describes the content and qualities of a good software requirements specification (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 identified 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 specific standard.

This recommended practice does not identify any specific 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.¹

• ASTM E1340-96, Standard Guide for Rapid Prototyping of Computerized Systems.²
• 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.³
• IEEE Std 828-1998, IEEE Standard for Software Configuration 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 Reliable Software.
• IEEE Std 1002-1987 (Reaff 1992), IEEE Standard Taxonomy for Software Engineering Standards.
• IEEE Std 1012-1998, IEEE Standard for Software Verification and Validation.
• IEEE Std 1012a-1998, IEEE Standard for Software Verification and Validation: Content Map to IEEE/EIA 412207.1-1997.⁵
• 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 Configuration Management.⁶
• 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 712207.1-1997.
• IEEE Std 1074-1997, IEEE Standard for Developing Software Life Cycle Processes.⁸

¹ASTM publications are available fro