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 ]
Download
Report
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 ]