You are on page 1of 3

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:  Correct in that all stated requirements represent a need a
A complete yet concise description of the entire stakeholder has (customer, user, analyst or designer,…)
external interface of the system with its environment;  Unambiguous in that every stated requirement has a
Functional (or behavioural) requirements specify unique interpretation.
what the system does by relating inputs to outputs;  Complete in that it possesses the following four qualities:
Non-Functional (quality) requirements prescribe Describes everything the software is supposed to do;
global attributes of the system. The response to input combinations is stated explicitly;
 What not to include in a RSD: Pages and figures are numbered;
Project requirements -- they are development- There are no “to-be-determined” sections.
specific, and irrelevant as soon as the project is over.  Verifiable in that every requirement can be established
Designs -- design is irrelevant to customers. through a finite-cost, effective process.
Quality assurance plans -- e.g., plans for  Consistent in that it avoids (i) conflicting behaviour, (ii)
configuration management, verification and validation, conflicting terms, (iii) conflicting attributes (iv) temporal
testing, etc. inconsistencies
2004 John Mylopoulos Software Requirements Specification 3 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