Illinois%20Institute%20of%20Technology

1
Illinois Institute of Technology

• CS487
• Software Engineering
• Instructor David Lash

2
Writing the Requirements Specification

• Start with a standard outline.
• See ANSI/IEEE Std 830-19xx IEEE Guide to Software
  Requirements Specifications
• Use consistent language to write specifications.
• Provide a method of testing and tracing
  specifications.

3
General Specification Outline
I) Introduction The goals overall objectives.
The context of the overall system.
Scope. A) System reference B) Overall
description C) Software project constraints
4
General Specification Outline
II) Information Description - - Problem that
the system solves, hardware, info/control flow,
software and human interfaces. A) Information
content representation B) Information flow
representation 1) Data flow 2) Control flow
5
General Specification Outline
III) Functional Description Detail on each
function required to solve A) Functional
partitioning - overall diagram of the structure
of functions B) Function description 1) Process
ing narrative for each function 2) Restrictions/
limitation 3) Performance requirements 4) Desi
gn constraints 5) Supporting diagrams
6
General Specification Outline
C) Control Description 1) Control
specification 2) Design constraints IV
Behavioral Description Operation of system in
respect to external events and actions 1) System
states 2) Events and actions
7
General Specification Outline
V) Validation and Criteria what is a successful
implementation? A) Performance
bounds B) Classes to tests C) Expected software
response D) Special consideration VI) Bibliograp
hy - references to documents related, vendor
literature, tech references VII) Appendix -
related data, algorithms, charts, graphs
8
Writing a Requirement

• Always write in an active voice.
• Active voice, the subject acts.
• The system processes 5 transactions per second.
• Passive voice, the subject is acted upon.
• The system is to process 5 transactions per
  second.

9
Writing requirements

• Specific and general requirements.
• Shall indicates the requirement must operate
  exactly as specified.
• On reception of a new messages, the software
  shall respond with an ACK, if the data is
  received without error or a NACK, if the data
  received contains an error.
• Should, will indicates the system generally
  operates this way.

10
Requirement Statement Example (Optional)
Section Reference
Specification Reference
O4-1 29The date representation used for a
character-oriented interface that interchanges
date-sensitive information between communicating
systems should conform to ISO 8601 calendar date
complete representation and basic format (without
separators).
11
Requirement Statement Example (Conditional)
CR4-5 33If a system that supports an internal
date representation with four digits for the
calendar year interfaces with an interface that
supports less than four digits for the calendar
year, then the systems message/protocol handler
shall convert the incoming message/APDU calendar
year representation to a four-digit format. It
should then perform the necessary date
operations. The reverse order is true for the
outgoing direction.
12
Requirement Statement Example (Mandatory)
R4-3 31The date/time representation used for
the protocol of an object oriented interface and
its associated information model shall conform to
ISO 8601 calendar date complete representation
and basic format. For example, in OIS/CMISE, the
ASN.1 type Generalized Time syntax conforms to
ISO 8601.