Transcript 4. Requirements Processes II Overview      4.1 Fundamentals 4.2 Elicitation 4.3 Specification 4.4 Verification 4.5 Validation Software Requirements Specification [ §4 : 1 ]

4. Requirements Processes II
Overview





4.1 Fundamentals
4.2 Elicitation
4.3 Specification
4.4 Verification
4.5 Validation
Software
Requirements
Specification
[ §4 : 1 ]
From Definition to Specification

Requirements first must be defined




Concrete, unambiguous, coherent statement of needs
Acts as initial contract among customers, developers, etc.
Allows customers, developers, etc. to plan ahead
Requirements must then be specified


Definitions are at too high a level to guide design
Requirements must be refined and classified



Separated into sub-requirements to pin down details
Functional and non-functional requirements distinguished
Requirements must be allocated to an architecture
[ §4 : 2 ]
What Constitutes “Functional”?

Type as input, value as output


Type as input and output


E.g., towards functions and operators
Value as input, type as output


E.g., towards allowed polymorphism and type conversions
Value as input and output


E.g., towards constructors and initialization methods
E.g., towards classifiers and type identifiers
… and combinations of these domains/ranges
[ §4 : 3 ]
What about Time?

Superficially, time seems (and often may be) non-functional


However, some systems are inherently time-dependent




E.g., human interaction, mechanical control, etc.
Making system run too much faster or slower may be harmful
In such cases, time must be treated as a functional element
One technique is to transform time into events



E.g., when running faster is “a good thing” but does not change outcome
A timer or other device has a specified setting (e.g., rate) : Τ
The device generates events at times governed by that setting : f(Τ)
Functional requirements can be written about Τ and f(Τ)

Per a model that represents the relationship between Τ and f(Τ)
[ §4 : 4 ]
4.3 Specification

The Software Requirements Specification (SRS) is a
description of the functionality and constraints that
must be delivered by the software






precise
detailed
technical
The SRS becomes the baseline for the entire
software development process
The boundary between the system and its
environment must be known at this time
The SRS assumes that the system functions have
been allocated over an architecture
[ §4 : 5 ]
Technical Contents


The proper content of the
SRS is determined by
fundamental technical
considerations having to do
with how we view computing
The specific form of an SRS
reflects the specific
computational model
underlying the specification
methodology being employed
Softw are s ys te m
• s tate s
• actions
Inte rface s
Environm e nt
Constra ints
[ §4 : 6 ]
Specification after Elicitation
application
Elicitation
Specif ication
Requirements
Definition
Document
Software
Requirements
Specification
Requirements
definition
Program
design
[ §4 : 7 ]
Running Case Study: Elevator

Consider the
development of an
elevator control system
for a 10-story residential
building.
arrival
lights
fire
alarm
request
buttons
call
buttons
[ §4 : 8 ]
Centralized Controller



All external interfaces
have been identified
The specification does
not rule out a distributed
implementation …
… but provides a
concrete high-level
architecture to allow
further specification and
refinement
requests
Ele vator
controlle r
motor
door
[ §4 : 9 ]
Specification after Allocation
appl icatio n
Elicit ation
Requirements
Definition
Document
Requi rements
defin itio n
Allocation
Specif ication
System
Architecture
Software
Requirements
Specification
System d esig n
(simplified )
Sof tware
design
[ §4 : 10 ]
Elevator Case Study, Continued

The full technical specification cannot
complete (and it may be expensive to start it)
until all interfaces (internal and external) are
well defined
light & fan
buzzer
key
door assembly
(fully automated)
[ §4 : 11 ]
Distributed Controller



Additional internal
interfaces have been
identified
The specification rules
out a centralized
implementation
Architecture is
constrained accordingly
requests
Elevator controller
Sche dule r
M ove m e nt
controlle r
motor
door
[ §4 : 12 ]
4.4 Verification


Requirements verification is an activity directed
towards the discovery of specification errors
The ultimate goal is to ensure that the specification
(when considered on its own) is





correct
consistent
complete
The verification must be carried out against a model
(formal or informal)
Formal and semi-formal specifications can be
checked out by tools
[ §4 : 13 ]
Verification Example:
Elevator Door Control Logic


Consider a deterministic finite
state representation of the
elevator movement logic
Some errors can be detected
simply by the nature of the model




invalid initial state
missing transitions
non-deterministic transitions
possible live-lock, etc.
down
mov ement
floor j
arrived
f loor sensor
input
door
open
request f rom
this f loor and
none f or other
f loors
timeout with no
requests
door
closed
request f or some
other f loor
departed
down
mov ement
[ §4 : 14 ]
4.5 Requirements Validation


Concerned with establishing
that specified requirements
represent the needs of the
customer and/or user
Needs are not reflected by
any model or document

Thus, validation cannot be
performed in a mechanical way

Good communication is
the key to a successful
validation





well-defined terminology
well-written and simple
specifications
formal reviews
rapid prototypes
simulations
[ §4 : 15 ]
Validation Example:
Elevator Movement Policy

Consider an elevator movement policy which


The policy satisfies the customer stated requirements



takes the elevator up and down, from top to bottom, and
services requests as it goes
every request is eventually serviced
there is a defined upper bound on the time it takes for a
request to be serviced
Nevertheless



the time it takes to service a request during low demand
periods may be unacceptable
unnecessary energy utilization emerges as a new issue
the need for a better policy (and ideas about it) may emerge
[ §4 : 16 ]