The Institute of Electrical and Electronics Engineers, Inc.

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 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
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
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.
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.
Copyright © 1998 IEEE. All rights reserved.
iii
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.
iv
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
The following persons were on the balloting committee:

Edward Byrne
Paul R. Croll
Perry DeWeese
Robin Fralick
Marilyn Ginsberg-Finner
John Harauz
Mark Henley
Dennis Lawrence
David Maibor
Ray Milovanovic
James Moore
Timothy Niesen
Dennis Rilling
Terry Rout
Richard Schmidt
Norman F. Schneidewind
David Schultz
Basil Sherlund
Peter Voldner
Ronald Wade
Syed Ali
Theodore K. Atchinson
Mikhail Auguston
Robert E. Barry
Leo Beltracchi
H. Ronald Berlack
Richard E. Biehl
Michael A. Blackledge
Sandro Bologna
Juris Borzovs
Kathleen L. Briggs
M. Scott Buck
Michael Caldwell

James E. Cardow
Enrico A. Carrara
Lawrence Catchpole
Keith Chan
Antonio M. Cicu
Theo Clarke
Sylvain Clermont
Rosemary Coleman
Virgil Lee Cooper
W. W. Geoff Cozens
Paul R. Croll
Gregory T. Daich
Geoffrey Darnton
Taz Daughtrey
Bostjan K. Derganc
Perry R. DeWeese
James Do
Evelyn S. Dow
Carl Einar Dragstedt
Sherman Eagles
Christof Ebert
Leo Egan
Richard E. Fairley
John W. Fendrich
Jay Forster
Kirby Fortenberry
Eva Freund
Richard C. Fries
Roger U. Fujii
Adel N. Ghannam
Marilyn Ginsberg-Finner
John Garth Glynn
Julio Gonzalez-Sanz
L. M. Gunther
David A. Gustafson

Jon D. Hagar
John Harauz
Robert T. Harley
Herbert Hecht
William Heßey
Manfred Hein
Mark Heinrich
Mark Henley
Debra Herrmann
John W. Horch
Jerry Huller
Peter L. Hung
George Jackelen
Frank V. Jorgensen
William S. Junk
George X. Kambic
Richard Karcich
Ron S. Kenett
Judith S. Kerner
Robert J. Kierzyk
Dwayne L. Knirk
Shaye Koenig
Thomas M. Kurihara
John B. Lane
J. Dennis Lawrence
Fang Ching Lim
William M. Lively
James J. Longbucco
Dieter Look
John Lord
Stan Magee
David Maibor
Harold Mains
Robert A. Martin
Tomoo Matsubara
Mike McAndrew

Patrick D. McCray
Christopher McMacken
Jerome W. Mersky
Bret Michael
Alan Miller
Celia H. Modell
James W. Moore
Pavol Navrat
Myrna L. Olson
Indradeb P. Pal
Alex Polack
Peter T. Poon
Lawrence S. Przybylski
Kenneth R. Ptack
Annette D. Reilly
Dennis Rilling
Andrew P. Sage
Helmut Sandmayr
Stephen R. Schach
Hans Schaefer
Norman Schneidewind
David J. Schultz
Lisa A. Selmon
Robert W. Shillato
David M. Siefert
Carl A. Singer
James M. Sivak
Richard S. Sky
Nancy M. Smith
Melford E. Smyre
Harry M. Sneed
Alfred R. Sorkowitz
Donald W. Sova
Luca Spotorno
Julia Stesney

Fred J. Strauss
Christine Brown Strysik
Toru Takeshita
Richard H. Thayer
Booker Thomas
Patricia Trellue
Theodore J. Urbanowicz
Glenn D. Venables
Udo Voges
David D. Walden
Dolores Wallace
William M. Walsh
John W. Walz
Camille SWhite-Partain
Scott A. Whitmire
P. A. Wolfgang
Paul R. Work
Natalie C. Yopconka
Janusz Zalewski
Geraldine Zimmerman
Peter F. Zoll
v
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
*Member Emeritus
Valerie E. Zelenty
IEEE Standards Project Editor
Satish K. Aggarwal
Clyde R. Camp
James T. Carlo
Gary R. Engmann
Harold E. Epstein
Jay Forster*
Thomas F. Garrity
Ruben D. Garzon

James H. Gurney
Jim D. Isaak
Lowell G. Johnson
Robert Kennelly
E. G. ÒAlÓ Kiener
Joseph L. KoepÞnger*
Stephen R. Lambert
Jim Logothetis
Donald C. Loughry
L. Bruce McClung
Louis-Fran�ois Pau
Ronald C. Petersen
Gerald H. Peterson
John B. Posey
Gary S. Robinson
Hans E. Weinrich
Donald W. Zipse
vi
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
1
IEEE Recommended Practice for

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.
IEEE
Std 830-1998 IEEE RECOMMENDED PRACTICE FOR
2
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.

1
IEEE Std 610.12-1990, IEEE Standard Glossary of Software
Engineering Terminology.
2
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 ConÞguration
Management Plans.
3
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
12207.1-1997.
4
IEEE Std 1016-1998, IEEE Recommended Practice for Software
Design Descriptions.
5
IEEE Std 1028-1997, IEEE Standard for Software Reviews.
IEEE Std 1042-1987 (Reaff 1993), IEEE Guide to Software
ConÞguration Management.
IEEE P1058/D2.1, Draft Standard for Software Project
Management Plans, dated 5 August 1998.
6
IEEE Std 1058a-1998, IEEE Standard for Software Project
Management Plans: Content Map to IEEE/EIA
12207.1-1997.
7

IEEE Std 1074-1997, IEEE Standard for Developing Software
Life Cycle Processes.
IEEE Std 1233, 1998 Edition, IEEE Guide for Developing
System Requirements SpeciÞcations.
8
1
ASTM publications are available from the American Society for
Testing and Materials, 100 Barr Harbor Drive, West
Conshohocken,
PA 19428-2959, USA.
2
IEEE publications are available from the Institute of Electrical
and Electronics Engineers, 445 Hoes Lane, P.O. Box 1331,
Piscataway,
NJ 08855-1331, USA.
3
As this standard goes to press, IEEE Std 828-1998; IEEE Std
1012a-1998; IEEE Std 1016-1998; and IEEE Std 1233, 1998

Edition are
approved but not yet published. The draft standards are,
however, available from the IEEE. Anticipated publication date
is Fall 1998.
Contact the IEEE Standards Department at 1 (732) 562-3800 for
status information.
4
See Footnote 3.
5
See Footnote 3.
6
Upon approval of IEEE P1058 by the IEEE-SA Standards
Board, this standard will be integrated with IEEE Std 1058a-
1998 and
published as IEEE Std 1058, 1998 Edition. Approval is expected
8 December 1998.
7
As this standard goes to press, IEEE Std 1058a-1998 is
approved but not yet published. The draft standard is, however,
available from

the IEEE. Anticipated publication date is December 1998.
Contact the IEEE Standards Department at 1 (732) 562-3800 for
status
information. See Footnote 6.
8
See Footnote 3.
IEEE
SOFTWARE REQUIREMENTS SPECIFICATIONS Std 830-
1998
3
3. DeÞnitions
In general the deÞnitions of terms used in this recommended
practice conform to the deÞnitions provided in
IEEE Std 610.12-1990. The deÞnitions below are key terms as
they are used in this recommended practice.
3.1 contract:

A legally binding document agreed upon by the customer and
supplier. This includes the tech-
nical and organizational requirements, cost, and schedule for a
product. A contract may also contain infor-
mal but useful information such as the commitments or
expectations of the parties involved.
3.2 customer:
The person, or persons, who pay for the product and usually
(but not necessarily) decide the
requirements. In the context of this recommended practice the
customer and the supplier may be members of
the same organization.
3.3 supplier:
The person, or persons, who produce a product for a customer.
In the context of this recom-
mended practice, the customer and the supplier may be members
of the same organization.
3.4 user:
The person, or persons, who operate or interact directly with
the product. The user(s) and the
customer(s) are often not the same person(s).
4. Considerations for producing a good SRS

This clause provides background information that should be
considered when writing an SRS. This includes
the following:
a) Nature of the SRS;
b) Environment of the SRS;
c) Characteristics of a good SRS;
d) Joint preparation of the SRS;
e) SRS evolution;
f) Prototyping;
g) Embedding design in the SRS;
h) Embedding project requirements in the SRS.
4.1 Nature of the SRS
The SRS is a speciÞcation for a particular software product,
program, or set of programs that performs
certain functions in a speciÞc environment. The SRS may be
written by one or more representatives of the
supplier, one or more representatives of the customer, or by
both. Subclause 4.4 recommends both.
The basic issues that the SRS writer(s) shall address are the
following:
a)
Functionality.
What is the software supposed to do?

b)
External interfaces.
How does the software interact with people, the systemÕs
hardware, other hard-
ware, and other software?
c)
Performance.
What is the speed, availability, response time, recovery time of
various software func-
tions, etc.?
d)
Attributes.
What are the portability, correctness, maintainability, security,
etc. considerations?
e)
Design constraints imposed on an implementation.

Are there any required standards in effect, imple-
mentation language, policies for database integrity, resource
limits, operating environment(s) etc.?
The SRS writer(s) should avoid placing either design or project
requirements in the SRS.
For recommended contents of an SRS see Clause 5.
IEEE
4
4.2 Environment of the SRS
It is important to consider the part that the SRS plays in the
total project plan, which is deÞned in IEEE Std
610.12-1990. The software may contain essentially all the
functionality of the project or it may be part of a
larger system. In the latter case typically there will be an SRS
that will state the interfaces between the
system and its software portion, and will place external
performance and functionality requirements upon
the software portion. Of course the SRS should then agree with
and expand upon these system requirements.

IEEE Std 1074-1997 describes the steps in the software life
cycle and the applicable inputs for each step.
Other standards, such as those listed in Clause 2, relate to other
parts of the software life cycle and so may
complement software requirements.
Since the SRS has a speciÞc role to play in the software
development process, the SRS writer(s) should be
careful not to go beyond the bounds of that role. This means the
SRS
a) Should correctly deÞne all of the software requirements. A
software requirement may exist because
of the nature of the task to be solved or because of a special
characteristic of the project.
b) Should not describe any design or implementation details.
These should be described in the design
stage of the project.
c) Should not impose additional constraints on the software.
These are properly speciÞed in other
documents such as a software quality assurance plan.
Therefore, a properly written SRS limits the range of valid
designs, but does not specify any particular
design.
4.3 Characteristics of a good SRS
An SRS should be
a) Correct;
b) Unambiguous;

c) Complete;
d) Consistent;
e) Ranked for importance and/or stability;
f) VeriÞable;
g) ModiÞable;
h) Traceable.
4.3.1 Correct
An SRS is correct if, and only if, every requirement stated
therein is one that the software shall meet.
There is no tool or procedure that ensures correctness. The SRS
should be compared with any applicable
superior speciÞcation, such as a system requirements
speciÞcation, with other project documentation, and
with other applicable standards, to ensure that it agrees.
Alternatively the customer or user can determine if
the SRS correctly reßects the actual needs. Traceability makes
this procedure easier and less prone to error
(see 4.3.8).
4.3.2 Unambiguous
An SRS is unambiguous if, and only if, every requirement stated
therein has only one interpretation. As a
minimum, this requires that each characteristic of the Þnal
product be described using a single unique term.

IEEE
SOFTWARE REQUIREMENTS SPECIFICATIONS Std 830-
1998
5
In cases where a term used in a particular context could have
multiple meanings, the term should be included
in a glossary where its meaning is made more speciÞc.
An SRS is an important part of the requirements process of the
software life cycle and is used in design,
implementation, project monitoring, veriÞcation and validation,
and in training as described in IEEE Std
1074-1997. The SRS should be unambiguous both to those who
create it and to those who use it. However,
these groups often do not have the same background and
therefore do not tend to describe software require-
ments the same way. Representations that improve the
requirements speciÞcation for the developer may be
counterproductive in that they diminish understanding to the
user and vice versa.
Subclauses 4.3.2.1 through 4.3.2.3 recommend how to avoid
ambiguity.
4.3.2.1 Natural language pitfalls
Requirements are often written in natural language (e.g.,
English). Natural language is inherently ambigu-
ous. A natural language SRS should be reviewed by an

independent party to identify ambiguous use of
language so that it can be corrected.
4.3.2.2 Requirements speciÞcation languages
One way to avoid the ambiguity inherent in natural language is
to write the SRS in a particular requirements
speciÞcation language. Its language processors automatically
detect many lexical, syntactic, and semantic
errors.
One disadvantage in the use of such languages is the length of
time required to learn them. Also, many non-
technical users Þnd them unintelligible. Moreover, these
languages tend to be better at expressing certain
types of requirements and addressing certain types of systems.
Thus, they may inßuence the requirements in
subtle ways.
4.3.2.3 Representation tools
In general, requirements methods and languages and the tools
that support them fall into three general cate-
goriesÑobject, process, and behavioral. Object-oriented
approaches organize the requirements in terms of
real-world objects, their attributes, and the services performed
by those objects. Process-based approaches
organize the requirements into hierarchies of functions that
communicate via data ßows. Behavioral
approaches describe external behavior of the system in terms of
some abstract notion (such as predicate
calculus), mathematical functions, or state machines.

The degree to which such tools and methods may be useful in
preparing an SRS depends upon the size and
complexity of the program. No attempt is made here to describe
or endorse any particular tool.
When using any of these approaches it is best to retain the
natural language descriptions. That way, custom-
ers unfamiliar with the notations can still understand the SRS.
4.3.3 Complete
An SRS is complete if, and only if, it includes the followi ng
elements:
a) All signiÞcant requirements, whether relating to
functionality, performance, design constraints,
attributes, or external interfaces. In particular any external
requirements imposed by a system speci-
Þcation should be acknowledged and treated.
IEEE
6

b) DeÞnition of the responses of the software to all realizable
classes of input data in all realizable
classes of situations. Note that it is important to specify the
responses to both valid and invalid input
values.
c) Full labels and references to all Þgures, tables, and diagrams
in the SRS and deÞnition of all terms
and units of measure.
4.3.3.1 Use of TBDs
Any SRS that uses the phrase Òto be determinedÓ (TBD) is not
a complete SRS. The TBD is, however, occa-
sionally necessary and should be accompanied by
a) A description of the conditions causing the TBD (e.g., why
an answer is not known) so that the situ-
ation can be resolved;
b) A description of what must be done to eliminate the TBD,
who is responsible for its elimination, and
by when it must be eliminated.
4.3.4 Consistent
Consistency refers to internal consistency. If an SRS does not
agree with some …
Software Requirements and Design Specification for online
banking systemPage 15
Software Requirements SpecificationforOnline Banking System

Version 1.0
Prepared by Mohammed Allibalogun
The
Solution
Software Company
March 28th, 2020
Template only ©1999 by Karl E. Wiegers. Permission is granted
to use, modify, and distribute this document. (SRS sections);
©1994-1997 by Bradford D. Appleton. Permission is hereby
granted to make and distribute verbatim copies of this document
provided the copyright notice and this permission notice are
preserved on all copies (SDS sections); Further modified by
Drs. Renata Rand McFadden and Sheldon Linker.
Table of Contents
Table of Contentsii
Revision Historyii
1.Introduction1
1.1Purpose1
1.2Document Conventions1
1.3Intended Audience and Reading Suggestions1
1.4Product Scope2

1.5References2
2.Overall Description3
2.1Product Perspective3
2.2Product Features3
2.3User Classes and Characteristics3
2.4Operating Environment4
2.5.1Performance Constraints5
3.System Features5
3.1User can trasnfer funds:5
3.2View balance5
4.External Interface Requirements5
4.1User Interfaces Overview5
4.2Hardware Interfaces6
4.3Software Interfaces6
4.3.1Validate the User account6
4.3.2Account Balance7
4.3.3Funds Transfer8
5.System Features/Modules9
5.1Validate User Account:9
5.1.1Description and Priority10
5.2Able to add beneficiary for funds transfer10
5.3Validate Minimum balance for Doing the Transaction11
5.4Validate Funds Transfer12
6.Nonfunctional Requirements12

6.1Performance12
6.2Security12
6.3Adaptability13
Revision HistoryComment by Sheldon Linker: Generally, this
table should appear on one page if possible. So, put a page
break before this.
Name
Date
Reason for Changes
Version
Mohammed Allibalogun
March 29, 2020
Initial draft
1.0
April 3, 2020
Second draft
1.1
April 7, 2020
Third draft
1.2

April 10, 2020
Fourth draft
1.3
Software Requirements and Design Specification for
<Project>Page iii
to use, modify, and distribute this document.(SRS sections);
Introduction
Purpose
The main purpose of this document is to present the extensive
details about the online banking system. It will explain the
complete description of the system, how the system will work,
what will be the features of the system, how the interface of the
system would be, what constraints will the system have, and
most importantly how the system will deal with the external

affairs and stimuli. This document is valid and intended for both
the stakeholders and the developers of the system as well. The
approval or disapproval authority of this project will be liable
by the community of the bank.
Document Conventions
The detailed version of the online banking system is available
under the scope and vision document. The other section of the
report will include scope and release information of the system.
The document convention is as follows:
· Bold is used as the heading
Intended Audience and Reading Suggestions
The main objective is to prepare a software application which
will maintain the data online, provide a user-friendly interface
for its users, update and retrieve customer details with 100%
accuracy. As the system is a computerized process so it will not
consume more time like the traditional system does and helps to
cut down the cost for keeping the record.
Product Scope
The scope of the project is to build the online banking system,
to enhance the customer experience, the use of technology is

one of the most important parts to consider. it helps the
customers to manage the transactions online without visiting the
bank physically. The online system helps to keep the record of
the transactions. The traditional banking method is the old and
legacy, it needs to be replaced with the new system to ensure
the efficiency and accuracy of the system. The most important
thing to be considered is that the system should be quick and
reliable.
References
Carte, T. A., Jasperson, J., & Cornelius, M. E. (2006).
Integrating ERD and UML Concepts When Teaching Data
Modeling. Journal of Information Systems Education, 17(1), 55-
64. Retrieved from
https://jise.org/Volume17/n1/JISEv17n1p55.html
Coronel, C. (n.d.). Database Systems Design, Implementation
and Management. CENGAGE Learning.
M, A. (n.d.). Principles of Effective Visual Communication for
Graphical User Interface Design. Science Direct.
Martin Fowler, C. K. (n.d.). UML Distilled: A Brief Guide to
the Standard Object Modeling Language. Amazon.
Petrie, H. (n.d.). Tension, what tension? Website accessibility
and visual design. ACM.
Toby J. Teorey, D. Y. (n.d.). A logical design methodology for
relational databases using the extended entity-relationship

model. ACM.
Wang, M. (n.d.). USING UML FOR OBJECT-RELATIONAL
DATABASE SYSTEMS DEVELOPMENT: A FRAMEWORK.
Yu, E. (n.d.). Carte, T. A. (n.d.). Integrating ERD and UML
Concepts When Teaching Data Modeling. Journal of
Information Systems Education. IEEE Xplorer.
“IEEE 830 Template 2.” (n.d.). UMGC. Retrieved on March 29,
2020, from
https://learn.umgc.edu/d2l/le/content/444081/viewContent/1794
1543/View
“IEEE 830 Project Description (Project 2).” (n.d.). UMGC.
Retrieved on March 29, 2020, from
https://learn.umgc.edu/d2l/le/content/444081/viewContent/1794
1540/View
Overall Description
Product Perspective
A complete understanding between the traditional banking and
online banking system can be understood with the detailed
product perspective. The following diagram represents how
online banking conducts its daily business activities.
Product Features
The major features of the online banking system are as follows:
· View account Status

· View account Balance
· Transfer Funds
· Request for the account Statement
User Classes and Characteristics
Following are the users who intend to operate the system:
· Customer
· Call Center Staff
· Banking Staff
Customer:
Customer is the one who wants to enable their online banking
due to the number of reasons. The customer visits the bank to
get the e-banking login details.
Banking Staff:
Banking staff after the necessary verification provides the user
with the unique login username and password, the customer will
able to access the account using their account based on it. The
URL has been provided to the staff to access the system.
Call Center Staff:
The customer wants to get some information regarding the
transaction, or about the account, the call center staff has the
details of the user account, after the successful verification

overcall, the call canter staff will guide the customer about the
issue, or how to use the banking online facility.
Operating Environment
The system will be able to operate on the following browsers:
· Microsoft Internet Explorer 10
· Mozilla Firefox
· Google Chrome
· Safari
The system will be hosted over the Linux server, enabled with
the Apache webserver. All the firewalls need to be done
accordingly.
To access the online banking system, stable internet connection
with minimum 3Mbps speed required to access the application
and do the needed operation.
Design and Implementation ConstraintsPerformance constraints:
The system shall fulfill the following constraints:
1. Coding Standards
a. The implementation of predetermining guidelines, best
practices and programming style that developers will fol low
when building the application.

2. Naming Conventions
a. The purpose of implementing a naming convention when
coding is to allow any developer to comprehend and understand
the source code's scope.
3. Model-View-Controller Structure
a. The architectural pattern that separates an application into
three main logical components
4. The response of application within 10 seconds of Input.
a. This is an adequate amount of time to ensure user engagement
is persistent.
System Features
User can transfer Funds Comment by Sheldon Linker: This list
should parallel the list in §5.
User has the option to send funds to any other accounts by
sampling having the other account number.
View Balance
The user has the option to view his bank account balance.
Withdraw Funds
User has the option to withdraw money based on the available
balance.

Pay Bills
User has the option to pay bills that are linked to the online
bank software.
3.5 Appy for a Loan
Users may be able to instantly apply for a loan.
Login
The system has an interactive user interface that enables the
user to log in to the system.
Validate funds transfer
The user can affirm that the transaction being made are
authentic.
Report error issue
Add beneficiary feature
This enables the account owner to add beneficiaries of her/his
account in the event of his/her demise.
Report error issue
This feature enables the customer to quickly seek help in the
event of a fault while interacting with the system External
Interface Requirements

User Interfaces Overview
he system shall be graphical based, the number of the user
personas and culture has been kept in mind while designing the
user interface of the application. The buttons and clicks have
been used to access the interface of the application. The web
application will be responsive to number of the screens.
The image depicts that system will be responsive to a number of
the screens.
Hardware Interfaces
The ability of the required hardware is as follows:
1. Ability to create the connection
2. Continuous power supply
3. Continuous and stable internet connection
4. Ability to authenticate the users
Software InterfacesValidate the User Account
SI-1.1: The user will transmit the data along with credentials.
SI-1.2: System validates the user account.
SI-1.3: The customer has been login successful or an error has

been identified.
Account Balance
SI-2.1: The user account balance will be displayed after
authentication.
SI-2.2: System displays the option of funds Transfer.
SI-2.3: The bank options have been displayed.
Funds Transfer
SI-3.1: Enter the beneficiary account number.
SI-3.2: the system will display the name of the account holder.
SI-3.3: The user enters about the amount to be transferred.
SI-3.4: System will check the balance in the account
SI-3.5: System will transfer the amount of balance available.

System Features/Modules
The primary feature that will be implemented by the application
are:Comment by Sheldon Linker: These 3 lines are unneeded,
because all of this was handled in §3.
· User Module
· Account Summary Module Funds Transfer Module Validate
User Account:Comment by Sheldon Linker: This appears to be
"Validate User Account" and not "Funds Transfer Module".
5.1.1Description and PriorityComment by Sheldon Linker: You
left out the description and priority, showing only what might
be a requisite.
The user must have a valid banking account and credentials as
well.
5.1.2Stimulus/Response Sequences
Stimulus
User will need a valid URL address to open the online banking
systemComment by Sheldon Linker: "use" or "enter"Comment
by Sheldon Linker: Each sentence should get a period.
Response
The application will display the login page.
Stimulus
The user will enter valid credentials to log in.

Response
The application will check for the user credential and the
following response can occur:Comment by Sheldon Linker:
Each paragraph in this column should have similar formatting.
a. The credential provided by the users is verified by the
software, which will grant him access.
b. The credential does not match and the software will prompt
the user to re-enter the right credential.
The user will get 3 attempts. If the software can’t validate the
user’s information to be correct, it will lock the user out.
Functional Requirements
REQ-1.1: User runs the URL in the browser, upon doing this the
system prompts the user to enter credentials. This includes the
name and password. Comment by Sheldon Linker: To make
these all line up right, use a tab after the colon instead of
spaces. Each requirement should match a stimulus and a
response in an S/R pair. If your pairs have alternate paths, that
will typically mean alternate requirements. Typically each is in
this form: "Upon «some event or user action», the «some
component or the system» shall «some responsive action».".
DO THIS HERE AND THROUGHOUT.
REQ-1.2: The user then enters both the name and the password
and prompts the system to run once again.
REQ-1.3 The system upon the credentials matching the ones in

the database, gives users access to the system.
REQ-1.4 If the credentials provided by the user do not match
those in the system’s database. The user is prompted once more
to try again. This record is logged and store in the database, if
the user enters incorrect credentials thrice s/he will be required
to provide more details for the system to work.
Able to add beneficiary for funds transfer Comment by Sheldon
Linker: This, and much of what follows, seems to be Part I of a
monetary transfer. The entire monetary transfer should all be
one function.
5.2.1Description and Priority
To add the beneficiary, it is necessary to have the beneficiary
account number
Stimulus
The user should enter a Valid Account number Comment by
Sheldon Linker: This is not where this flow starts. Somehow,
the user needs to indicate that we're doing a transfer. This
needs to not just be entering a beneficiary, but doing an entire
funds transfer sequence. Don't just cover what the user sees,
but also what has to happen behind the scenes, such as actually
transferring the money. Note that transferring the money will
follow one sequence if the other user has an account at the same

bank, and a different sequence if the recipient has an account at
another bank. Hint: Look up "NACHA". Make this pure
stimulus and response. One stimulus should elicit one response.
DO THIS HERE AND THROUGHOUT.
Each Stimulus needs a Response.
Response
A) The system will acknowledge the account holder's name.
B) the system will prompt the user to enter a valid account
number if this first trial did not work. This attempt is only
three.
Stimulus
The user enters invalid account number three times
Response
The user is requested to provide more details about the account.
Stimulus
Upon validating the account number, the user is prompted to
certify the transfer of money into the beneficiaries account
responseComment by Sheldon Linker: Response
The user authenticates the transfer of money into the
beneficiary’s account.
Stimulus
The system gives back a message for a successful transfer of
funds.
b) the system returns an error message with a help feature

advising on what step the user should take.
5.2.3Functional Requirements
A valid account number is required.
REQ-2.1:Valid Account#.
Validate Minimum balance for Doing the Transaction
The customer needs to maintain the minimum balance limit for
doing the transaction.
After the successful login, the user needs to do the same
transaction or check the balance only, as soon as the welcome
page displayed, the balance has been there as a dashboard. If the
user wants to do the transaction, he or she needs the balance in
their account to do the successful transaction.

Stimulus:Welcome to Dashboard
Response:The account balance has been displayed
Stimulus:the user selects the beneficial to do the transaction of
the utility bills
Response:The bill amount has been displayed
Stimulus:the button with the option pay bill has been displayed
if the minimum balance requirement of the user has been met
Response:The bill has been paid.
Stimulus
Welcome to Dashboard
Response
The user account balance has been displayed
Stimulus
The user selects the benefits to do the transaction for the utility
bills.
Response
The bill amount has been displayed
Stimulus
The button with the caption Pay bill has been displayed
Response
The bill paid if and only if the minimum balance requirement is
completed.

5.3.3Functional Requirements
The major functional requirement is to do the transaction, for
doing the transaction it is necessary that the minimum balance
requirement.
REQ-3.1:The user must be log in and the dashboard has been
displayed
REQ-3.2:The user must have a minimum balance
REQ-3.3: The user will confirm the payment
Validate Funds Transfer
After the successful verification of the account holder name,
and balance requirement, the system will initiate the process of
fund transfer if required.
Stimulus
Welcome to Dashboard
Response
The user account balance has been displayed
Stimulus
Select the Beneficiary
Response
The bill amount has been displayed
Stimulus

Enter the amount to transfer
Response
Funds have been transferred successfully.
5.4.3Functional RequirementsComment by Sheldon Linker:
There's something wrong with the formatting here.
The major functional requirement is to do the transaction, for
doing the transaction it is necessary that the minimum balance
requirement.
REQ-3.1:The user must be log in and the dashboard has been
displayed
REQ-3.2:The user must have a minimum balance
REQ-3.3: The user will confirm the payment
6.Nonfunctional Requirements
6.1Performance
NF-1.2:The system shall response to any event within 10
seconds.
6.2Security
NF-2.1:The system shall not be accessed without authentication
6.3Adaptability

NF-3.1:The system shall be accessible on chrome and Firefox
browser, smart cellular device enabled with the internet
NF-3.2:The system shall check the compatibility before the
welcome page displayed.Comment by Sheldon Linker: So what
you're talking about is programming errors? Programming
errors are not allowed to go into production. You can just drop
this requirement.
In the case of incompati bility, this could happen due to
designing so much with the styling languages such as CSS
leading to incompatibility, major incompatibilities are caused
by incorrect scripting. In case of incompatibility, the system
needs to be troubleshooted the entire system
to use, modify, and distribute this document. (SRS sections);

to use, modify, and distribute this
document.(SRS sections); ©1994-1997 by Bradford D.
Appleton. Permission is hereby granted to make and
distribute verbatim copies of this document provided the
copyright notice and this permission notice are preserved
on all copies (SDS sections); Further modified by Drs. Renata
Rand McFadden and Sheldon Linker.
©2002 by Karl E. Wiegers, all rights reserved; additions &
changes by Sheldon Linker, no additional rights
Specification
for
Cafeteria Ordering System

Version 1.1
Prepared by Karl Wiegers & Sheldon Linker
The Process Impact Company
December 19, 2018
Software Requirements and Design Specification for Cafeteria
Ordering System Page ii
Table of Contents
Table of Contents
...............................................................................................
........................... ii
Revision History
...............................................................................................
............................. ii
1.
Introduction............................................................................
..................................................1

1.1 Purpose
...............................................................................................
..........................................1
1.2 Document Conventions
...............................................................................................
.................1
1.3 Intended Audience and Reading Suggestions
..............................................................................1
1.4 Product Scope
............................................................................. Error!
Bookmark not defined.
1.5 References
...............................................................................................
.....................................1
2. Overall Description
...............................................................................................
...................1
2.1 Product Perspective
...............................................................................................
.......................1
2.2 Product Features
...............................................................................................
............................2

2.3 User Classes and Characteristics
...............................................................................................
...3
2.4 Operating Environment
...............................................................................................
.................3
2.5 Design and Implementation Constraints
......................................................................................4
2.6 User Documentation
...............................................................................................
......................4
2.7 Assumptions and Dependencies
...............................................................................................
....4
3. System Features
...............................................................................................
........................4
3.1 Feature 1
..................................................................................... Error!
4. External Interface Requirements
...........................................................................................4
4.1 User Interfaces Overview

...............................................................................................
..............5
4.2 Hardware
Interfaces................................. ...............................................
......................................5
4.3 Software Interfaces
...............................................................................................
........................5
5. System
Features/Modules.....................................................................
...................................5
5.1 System Feature 1
........................................................................ Error!
5.2 System Feature 2
........................................................................ Error!
5.3 System Feature 3 (and so on)
...............................................................................................
........8
Revision History

Name Date Reason For Changes Version
Karl Wiegers 10/21/2002 Initial draft 1.0 draft 1
Karl Wiegers 11/4/2002 Baseline following changes after
inspection 1.0 approved
Sheldon Linker 12/19/2018 Modernized 1.1
Usage is correct here, but a common mistake is to start your
document with multiple lines in this table.
There should be 1 line in this table for each version submitted.
In real life, that's 1 line per version
distributed.
Ordering System Page 1
1. Introduction
1.1 Purpose
This SRS describes the software functional and nonfunctional

requirements for release 1.0 of the
Cafeteria Ordering System (COS). This document is intended to
be used by the members of the
project team that will implement and verify the correct
functioning of the system. Unless otherwise
noted, all requirements specified here are high priority and
committed for release 1.0.
1.2 Document Conventions
The Cafeteria Ordering System will permit Process Impact
employees to order meals from the
company cafeteria on-line to be delivered to specified campus
locations. A detailed project description
is available in the Cafeteria Ordering System Vision and Scope
Document [1]. The section in that
document titled "Scope of Initial and Subsequent Releases" lists
the features that are scheduled for full
or partial implementation in this release.
1.3 Intended Audience and Reading Suggestions
This document is for the entire product team, especiall y the
project manager, developers, and QA
personnel.

1.4 References
1. Wiegers, Karl. Cafeteria Ordering System Vision and Scope
Document,
www.processimpact.com/projects/COS/COS_vision_and_scope.
doc
2. Wiegers, Karl. Process Impact Intranet Development
Standard, Version 1.3,
www.processimpact.com/corporate/standards/PI_intranet_dev_st
d.doc
3. Zambito, Christine. Process Impact Business Rules Catalog,
www.processimpact.com/corporate/policies/PI_business_rules.d
oc
4. Zambito, Christine. Process Impact Internet Application User
Interface Standard, Version 2.0,
www.processimpact.com/corporate/standards/PI_internet_ui_std
.doc
Note that when you reference documents, I am going to check
them. All of your references should be
real, related, and accessible. There should be a reference to the

initiating document. For our purposes,
that's the class assignment link. In real life, that would be a PO
or internal memorandum.
2. Overall Description
2.1 Product Perspective
The Cafeteria Ordering System is a new system that replaces the
current manual and telephone
processes for ordering and picking up lunches in the Process
Impact cafeteria. The context diagram in
Figure 1 illustrates the external entities and system interfaces
for release 1.0. The system is expected to
evolve over several releases, ultimately connecting to the
internet ordering services for several local
restaurants and to credit and debit card authorization services.
Note that the capitalization here is

exactly correct. The first words of sentences, proper names,
and explicitly defined terms are
capitalized, and nothing else.
2.2 Product Features
The following shows the product features in list form, and how
they fit together.
• Order Meals
• Create, View, Modify, and Delete Meal Subscriptions
• Register for Meal Payment Options
• Request Meal Delivery
• Create, View, Modify, and Delete Cafeteria Menus
• Create, View, Modify, and Delete Inventory Values
Figure 1
Here, the picture would have been a bit better if items
representing people, functions, and external systems
each had different shapes.

2.3 User Classes and Characteristics
Patron (favored) A Patron is a Process Impact employee at the
corporate campus in Clackamas,
Oregon, who wishes to order meals to be delivered from the
company cafeteria.
There are about 600 potential Patrons, of which an estimated
400 are expected to use
the Cafeteria Ordering System an average of 4 times per week
each (source: current
cafeteria usage data). Patrons will sometimes order multiple
meals for group events
or guests. An estimated 90 percent of orders will be placed
using the corporate
Intranet, with 10 percent of orders being placed from home. All
Patrons have
Intranet access from their offices. Some Patrons will wish to set
up meal
subscriptions, either to have the same meal to be delivered
every day or to have the

day’s meal special delivered automatically. A Patron must be
able to override a
subscription for a specific day.
Cafeteria Staff The Process Impact cafeteria currently employs
about 20 Cafeteria Staff, who will
receive orders from the Cafeteria Ordering System, prepare
meals, package them for
delivery, print delivery instructions, and request delivery. Most
of the Cafeteria Staff
will need to be trained in the use of the computer, the Web
browser, and the
Cafeteria Ordering System.
Menu Manager The Menu Manager is a cafeteria employee,
perhaps the cafeteria manager, who is
responsible for establishing and maintaining daily menus of the
food items available
from the cafeteria and the times of day that each item is
available. Some menu items
may not be available for delivery. The Menu Manager will also

define the cafeteria’s
daily specials. The Menu Manager will need to edit the menus
periodically to reflect
planned food items that are not available or price changes.
Meal Deliverer As the Cafeteria Staff prepare orders for
delivery, they will print delivery
instructions and issue delivery requests to the Meal Deliverer,
who is either another
cafeteria employee or a contractor. The Meal Deliverer will
pick up the food and
delivery instructions for each meal and deliver it to the Patron.
The Meal Deliverers’
primary interactions with the system will be to reprint the
delivery instructions on
occasion and to confirm that a meal was (or was not) delivered.
2.4 Operating Environment
OE-1: The Cafeteria Ordering System shall operate with the
following Web browsers: Microsoft
Internet Explorer versions 5.0 and 6.0, Netscape Communicator
version 4.7, and Netscape

versions 6 and 7. Note that this document was done in 2002.
This list, and a lot of what's
presented in §2, is obsolete. I've left it this way as an example
of things to be careful about
when doing your research. A modern list would replace
Netscape with Firefox, include
Chrome and Safari, and update the version numbers. Similar
obsolescence is true of some
other items in §2. Check your facts and best practices before I
do. Don't blindly copy.
OE-2: The Cafeteria Ordering System shall operate on a server
running the current corporate
approved versions of Red Hat Linux and Apache Web Server.
Note that this is specific to the
Process Impact company. If you include any OS or language
criteria, I expect it to be specific
to the company you're talking about, or have a reason stated as
to why you're making such a
restriction. The same is true for some of the other items in §2.
Don't blindly copy.
OE-3: The Cafeteria Ordering System shall permit user access
from the corporate Intranet and, if a
user is authorized for outside access through the corporate

firewall, from an Internet
connection at the user’s home. Again, note that OE-3 is
specific to the Process Impact
company. If you have something like this, it should be specific
to your customer or company.
The same is true for some of the other items in §2. Don't
blindly copy.
2.5 Design and Implementation Constraints
CO-1: The system’s design, code, and maintenance
documentation shall conform to the Process
Impact Intranet Development Standard, Version 1.3 [2]. (Real
reference warning applies)
CO-2: The system shall use the current corporate standard
Oracle database engine. (Company
specific and need-to-state warnings apply)

CO-3: All HTML code shall conform to the HTML 4.0 standard.
(Obsolescence warning applies)
CO-4: All scripts shall be written in Perl. (Company specific
and need-to-state warnings apply)
2.6 User Documentation
UD-1: The system shall provide an online hierarchical and
cross-linked help system in HTML that
describes and illustrates all system functions.
UD-2: The first time a new user accesses the system and on user
demand thereafter, the system shall
provide an online tutorial to allow users to practice ordering
meals using a static tutorial menu.
The system shall not store meals ordered using this template in
the database or place orders for
such meals with the cafeteria.
2.7 Assumptions and Dependencies
AS-1: The cafeteria is open for breakfast, lunch, and dinner
every company business day in which
employees are expected to be on site.

DE-1: The operation of the COS depends on changes being
made in the Payroll System to accept
payment requests for meals ordered with the COS.
DE-2: The operation of the COS depends on changes being
made in the Cafeteria Inventory System
to update the availability of food items as COS orders are
accepted.
3. System Features
3.1 Order Meals
Given that a user is already registered (see below) and menus
are created (see below), this function
allows a registered user to order from a menu, either for dine-in
or delivery (see below).
3.2 Create, View, Modify, and Delete Meal Subscriptions
Details not provided in this example
3.3 Register for Meal Payment Options

3.4 Request Meal Delivery
3.5 Create, View, Modify, and Delete Cafeteria Menus
3.6 Create, View, Modify, and Delete Inventory Values
4. External Interface Requirements
4.1 User Interfaces Overview
UI-1: The Cafeteria Ordering System screen displays shall

conform to the Process Impact Internet
Application User Interface Standard, Version 2.0 [4].
(Reference warning applies)
UI-2: The system shall provide a help link from each displayed
HTML page to explain how to use
that page.
4.2 Hardware Interfaces
No hardware interfaces have been identified. When you have a
section that doesn't really apply, you
have choices: (a) do it like this, (b) use "N/A", or (c) just leave
the section out entirely, but make sure
that you don't mess up your numbering.
4.3 Software Interfaces
4.3.1 Interface between the COS and the Cafeteria Inventory
System
SI-1.1: The COS shall transmit the quantities of food items
ordered to the Cafeteria Inventory
System through a programmatic interface.

SI-1.2: The COS shall poll the Cafeteria Inventory System to
determine whether a requested
food item is available.
SI-1.3: When the Cafeteria Inventory System notifies the COS
that a specific food item is no
longer available, the COS shall remove that food item from the
menu for the current
date.
4.3.2 Interface between the COS and the Payroll System
The COS shall communicate with the Payroll System through a
programmatic interface for the
following operations:
SI-2.1: To allow a Patron to register for payroll deduction.

SI-2.2: To allow a Patron to unregister for payroll deduction.
SI-2.3: To check whether a patron is registered for payroll
deduction.
SI-2.4: To submit a payment request for a purchased meal.
SI-2.5: To reverse all or part of a previous charge because a
patron rejected a meal or wasn’t
satisfied with it, or because the meal was not delivered per the
confirmed delivery
instructions.
4.4 Communications Interfaces
CI-1: The Cafeteria Ordering System shall send an eMail
message to the Patron to confirm
acceptance of an order, price, and delivery instructions.
CI-2: The Cafeteria Ordering System shall send an eMail
message to the Patron to report any
problems with the meal order or delivery after the order is
accepted.

5. System Features/Modules
5.1 Order Meals
5.1.1 Description and Priority
A cafeteria Patron whose identity has been verified may order
meals either to be delivered to a
specified company location or to be picked up in the cafeteria.
A Patron may cancel or change
a meal order if preparation has not started on it. Priority = High.
5.1.2 Stimulus/Response Sequences
Stimulus: A logged-on patron clicks on "Place an Order".
Response: The system displays the current menu (see menu set-
up section below), with fields
for meal details, payment, and delivery options.
Stimulus: The user enters valid field data.
Response: The web page enables the "Order" button.
Stimulus: The user clicks on "Order".
Response: The system notifies a food preparer of the order, and
notifies the patron that the

order has been placed, and enables order cancellation and edit.
Stimulus: The food preparer accepts the order.
Response: The system shows the order on the to-be-prepared
list, visible to the food
preparers.
Stimulus: The food preparer rejects the order, including a
rejection reason.
Response: The system notifies the patron, and disables the
"Cancel" and "Edit" buttons.
Stimulus: The user clicks on "Cancel".
Response: The system notifies a food preparer of the
cancellation, and notifies the patron that
the order has been canceled, and disables order cancellation.
Stimulus: The user clicks on "Edit".
Response: The system performs the "cancellation" function as
described above, and returns
the user to the ordering screen, with the previous data in place.

Stimulus: The food preparer clicks on "Started".
Response: The system disables the patron's "Cancel" and "Edit"
buttons.
Stimulus: The food preparer clicks on "Complete".
Response: The system notifies patron of the completion, and
notifies server or deliverer that
the order is ready, depending on delivery instructions.
Charging and inventory
actions happen as specified in those modules as described
below.
5.1.3 Functional Requirements
First, we show requirements that directly mimic the
stimulus/response pairs:
REQ-1.1: Upon a logged-in patron clicking on "Place and
Order", the system shall display the

current menu (see menu set-up functions below), with fields for
meal details,
payment, and delivery options.
REQ-1.2: As the user enters data and transitions from missing
or invalid data to valid data,
the web page, under script control, shall enable the "Order"
button when data is
ready to transmit, and disable when not.
REQ-1.3 When the user clicks "Order", the system shall (a)
notify a food preparer of the
order, (b) notify the patron that the order has been placed, and
(c) enable order
cancellation and edit.
REQ-1.4 If and when the food preparer accepts the order, the
system shall show the order on
the to-be-prepared list visible to the food preparers.
REQ-1.5 If and when the food preparer rejects the order
(including a rejection reason), the
system shall notify the patron and disable the "Cancel" and
"Edit" buttons.

REQ-1.6 If and when the patron clicks "Cancel", the system
shall (a) notify a food preparer
of the cancellation, (b) remove the item from the to-be-prepared
list, and (c) disable
the "Cancel" and "Edit" buttons.
REQ-1.7 If and when the patron clicks "Edit", the system shall
(a) perform cancellation as
described in REQ-1.6, and (b) return the patron to the ordering
page, with the
previous order data in place.
REQ-1.8 When the food preparer clicks on "Started", the system
shall disable the patron's
"Cancel" and "Edit" buttons.
REQ-1.9 When the food preparer clicks on "Complete", the
system shall (a) notify the patron
and server or deliverer (as appropriate to the order) that the
order is complete and
ready for delivery, and (b) initiate charging and delivery as
appropriate, and as
described in §5.3 and 5.5, respectively.
Next, any additional requirements needed, if any, which are not

directly indicated by
stimulus/response pairs, are added here:
===============================================
=======
REQ-1.10 As a part of order placement, the system shall present
date and time options to the
patron. The default date shall be listed as "Today", and the
default time shall be
listed as "Now".
REQ-1.11 When an order is placed and accepted, if the date and
time are in the future (as
opposed to the default, present), then moving the order to the
to-be-prepared list
shall be delayed until the appropriate time, as calculated by the
later of the current
time and the delivery time advanced by the preparation time.

REQ-1.12 The system shall not accept orders for times outside
of operating hours.
REQ-1.13 The system shall verify that the delivery location, if
specified, is within the service
area, and reject the order if not.
REQ-1.14 The system shall verify that sufficient delivery
resources are available, and if not,
shall not present the delivery option.
REQ-1.15 The system shall present the menu or menus which
are marked as being for the
appropriate date and time of day.
REQ-1.16 In presenting the menu items, the system shall grey
out and disable items which are
out of stock.
REQ-1.17 For each orderable item, the system shall present a
Quantity field, defaulted to 0.
REQ-1.18 The Quantity field shall maintain a limit check, with
a general maximum a patron is
allowed to order of an item, limited to the quantity on hand.

REQ-1.19 When an order is accepted, the system shall
communicate the change in inventory
levels to the inventory system, as described in §5.6.
5.2 Create, View, Modify, and Delete Meal Subscriptions
5.3 Register for Meal Payment Options
5.4 Request Meal Delivery
5.5 Create, View, Modify, and Delete Cafeteria Menus
5.6 Create, View, Modify, and Delete Inventory Values

6. Nonfunctional Requirements
6.1 Performance
NF-1.1 The system shall accommodate 400 users during the
peak usage time window of 8am to
10am local time, with an estimated average session duration of
8 minutes. If you're doing a
system for which the concept of local time applies, then
something like this would be
appropriate. If not, think about what is appropriate.
NF-1.2 All web pages generated by the system shall be
generated and displayable within 5s, using
picture placeholders until pictures are available. ("IMG" image
tags shall use the "ALT"
field.)
6.2 Safety

No safety requirements have been identified.
6.3 Security
NF-3.1: All network transactions between the patron and the
system shall use HTTPS protocol.
NF-3.2: All service-to-service interfaces that carry financial or
log-in information shall be
encrypted, using the highest encryption standard available for
that service. Any new
service shall use at least 128-bit encryption.
NF-3.3 The system shall require users to log into the COS for
all operations except viewing a
menu. Note that this says "The system shall require users to".
That places the requirement
on the system. We don't use "Users shall" on its own, because
we can't drop a "shall" on
users.
NF-3.4 The system shall permit only cafeteria staff members on
the list of authorized menu
managers to create or edit menus.

NF-3.5 Only users who have been authorized for home access to
corporate internet may use the
COS from outside locations. Be careful here. Before you
include something like this, be
sure it's appropriate to what you're doing.
NF-3.6 The system shall permit patrons to view only their own
previously placed orders, not orders
placed by other patrons.
6.4 Quality
NF-4.1: The COS shall be available to users on the corporate
internet and to external users 99.9% of
the time between 5am and midnight, local time, and 95% of the
time between midnight and
5am local time. A number of the gotchas I previously
mentioned appear in this
requirement.
NF-4.2: If the connection between the patron and the system is
broken prior to an order being either
accepted or cancelled, the COS shall enable the patron to

The Institute of Electrical and Electronics Engineers, Inc.

Recommended

Recommended

More Related Content

Similar to The Institute of Electrical and Electronics Engineers, Inc.

Similar to The Institute of Electrical and Electronics Engineers, Inc. (20)

More from carmanl5wisc

More from carmanl5wisc (20)

Recently uploaded

Recently uploaded (20)

The Institute of Electrical and Electronics Engineers, Inc.