Information Systems Analysis and Design csc340 Information Systems Analysis and Design csc340

XV. The Requirements The Requirements Specification

Specification Document (RSD) Document (RSD)

Produced by the requirements engineering
What to include/not include in a RSD? process; describes all requirements for the system
Attributes of a Well-Written RSD under design and is intended for several purposes:
An Example
Communication among customers, users and
designers;

Support for system testing, verification and
validation activities;

Control of system evolution -- maintenance,
extensions and enhancements to system should be
consistent with requirements.

2004 John Mylopoulos Software Requirements Specification 1 2004 John Mylopoulos Software Requirements Specification 2

Information Systems Analysis and Design csc340 Information Systems Analysis and Design csc340

Contents of a RSD Content Qualities

What to include in a RSD:
A complete yet concise description of the entire
external interface of the system with its environment;
Functional (or behavioural) requirements specify
what the system does by relating inputs to outputs;
Non-Functional (quality) requirements prescribe
global attributes of the system.

What not to include in a RSD:
Project requirements -- they are development-
specific, and irrelevant as soon as the project is over.
Designs -- design is irrelevant to customers.
Quality assurance plans -- e.g., plans for
configuration management, verification and validation,
testing, etc.
2004 John Mylopoulos Software Requirements Specification 3

Correct in that all stated requirements represent a need a
stakeholder has (customer, user, analyst or designer,…)

Unambiguous in that every stated requirement has a
unique interpretation.

Complete in that it possesses the following four qualities:
Describes everything the software is supposed to do;
The response to input combinations is stated explicitly;
Pages and figures are numbered;
There are no “to-be-determined” sections.

Verifiable in that every requirement can be established
through a finite-cost, effective process.

Consistent in that it avoids (i) conflicting behaviour, (ii)
conflicting terms, (iii) conflicting attributes (iv) temporal
inconsistencies
2004 John Mylopoulos Software Requirements Specification 4

Information Systems Analysis and Design csc340 Information Systems Analysis and Design csc340

Qualities of a Well-Written RSD

RSD Traceable vs Traced

Understandable by customers, so formal notations can
only be used as backup, while the RSD document itself is System-level
System-levelReqs
Reqs
expressed in natural language or perhaps UML. drafts,
drafts,memos,...
memos,...

Modifiable in that it can be easily changed without
affecting completeness, consistency; a table of contents traced
(TOC) helps, so does an index and cross references
where appropriate. Software
SoftwareRequirements
Requirements

Traced in that the origin of every requirement is clear; Specification
Specification
this can be achieved by referencing earlier documents.

Traceable in that attributes of the design can be traced traceable traceable
back to requirements and vice versa; to enhance
traceability (i) number every requirement, (ii) number Software
Software
Design
Design
every part of the RSD hierarchically, all the way down to
paragraphs
2004 John Mylopoulos Software Requirements Specification 5 2004 John Mylopoulos Software Requirements Specification 6
Information Systems Analysis and Design csc340 Information Systems Analysis and Design csc340

There is no Perfect RSD!

Style Qualities
ambiguous
ambiguous
lengthen it! shorten it!

Design-independent in the sense that it does not
shorten it! lengthen it!
imply a particular software architecture or algorithm

Annotated in that it provides guidance to the
developers; two useful types of annotations are (i) redundant
redundant inconsistent
inconsistent
relative necessity, i.e., how necessary is a
particular requirement from a stakeholder shorten it! shorten it!
lengthen it!
perspective, (ii) relative stability, i.e., how likely is it
lengthen it!
that a requirement will change. not
notunderstandable
understandable

Concise -- the shorter the better!

Organized in the sense that it is easy to locate any shorten it!
lengthen it!
one requirement.
incomplete
incomplete

2004 John Mylopoulos Software Requirements Specification 7 2004 John Mylopoulos Software Requirements Specification 8

Information Systems Analysis and Design csc340 Information Systems Analysis and Design csc340

How to Organize a RSD Example System Decomposition

There are many RSD standards, including: US DoD An Automated Money Machine (AMM) might be
DI-MCCR-80025A, IEEE ANSI 830-1984, etc. decomposed as follows:

Organization may be based on different criteria:
External stimulus or external situation, e.g., for an AMM
aircraft landing system, wind gusts, no fuel,...;
System feature, e.g., call forward,...;
System response, e.g., generate pay-cheques; System Banking Network
Control Applications Manager
External object, e.g., by book type for a library;
User type/use case.

It is useful to define a hierarchy among these criteria,
use it throughout the RSD document, e.g., sections Banking Applications handles banking transactions.
are defined with respect to (wrt) external stimulus, Network Manager communicates with central system.
subsections wrt system feature etc. System Control is responsible for startup/shutdown control
of the AMM system and error handling.
2004 John Mylopoulos Software Requirements Specification 9 2004 John Mylopoulos Software Requirements Specification 10

Information Systems Analysis and Design csc340 Information Systems Analysis and Design csc340

Interfaces, I/O Software Requirements

card box notification
banking
Card Box display Customer Define I/O for each use case for the Banking Applications

banking commands enter deposit cash

invalid pin select banking request cash box notification
cash box pin display
display transaction
Cash Box notification Banking display
Applications Printer Process
transaction Cash update account balance
pin Deposit
statement
control and commands Process transaction statement
pin validation request
information account updates card number PIN
Process withdraw cash request
pin validation
response Cash
System Network Withdrawal cash box
notification
Control Manager request account Process transaction
control and commands balance Account statement account request account
information Balance balance balance

account account
operational transaction balance update
information account
status account statement query balance
balance
System boundary
Bank’s
Computer

2004 John Mylopoulos Software Requirements Specification 11 2004 John Mylopoulos Software Requirements Specification 12
Information Systems Analysis and Design csc340

References

[Davis93] Davis, A., Software Requirements, Prentice-Hall,
1993, (chapter 3)

[Thayer90] Dorfman, M. and Thayer, R. Standards, Guidelines
and Examples on System and Software Requirements
Engineering, IEEE Computer Society Press, 1990.

2004 John Mylopoulos Software Requirements Specification 13