[ §4 : 1 ]
4. Requirements Processes II
Overview
4.1 Fundamentals 4.2 Elicitation 4.3 Specification 4.4 Verification 4.5 Validation
SoftwareRequirementsSpecification
[ §4 : 2 ]
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 : 3 ]
What Constitutes “Functional”?
Type as input, value as output E.g., towards constructors and initialization methods
Type as input and output E.g., towards allowed polymorphism and type conversions
Value as input and output E.g., towards functions and operators
Value as input, type as output E.g., towards classifiers and type identifiers
… and combinations of these domains/ranges
[ §4 : 4 ]
What about Time?
Superficially, time seems (and often may be) non-functional E.g., when running faster is “a good thing” but does not change
outcome 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 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 : 5 ]
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 : 6 ]
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
Software system
Interfaces
Environment
Constraints
• states • actions
[ §4 : 7 ]
Program design
application
Elicitation
Specification
Requirements Definition Document
Software Requirements Specification
Requirements definition
Specification after Elicitation
[ §4 : 8 ]
Running Case Study: Elevator
Consider the development of an elevator control system for a 10-story residential building.
arrival lights
call buttons
requestbuttons
fire alarm
[ §4 : 9 ]
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
Elevator controller
requests
motor door
[ §4 : 10 ]
Specification after Allocation
Software design
application
Allocation
Specification
System Architecture
Software Requirements Specification
System design (simplified)
ElicitationRequirements Definition Document
Requirements definition
[ §4 : 11 ]
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
key
buzzer
door assembly (fully automated)
[ §4 : 12 ]
Distributed Controller
Additional internal interfaces have been identified
The specification rules out a centralized implementation
Architecture is constrained accordingly
Scheduler
requests
Movement controller
motor door
Elevator controller
[ §4 : 13 ]
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 : 14 ]
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.
arrived
door open
door closed
departed
floor j
floor sensor input
request from this floor and none for other floors
timeout with no requests
request for some other floor
down movement
down movement
[ §4 : 15 ]
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 : 16 ]
Validation Example: Elevator Movement Policy
Consider an elevator movement policy which takes the elevator up and down, from top to bottom, and
services requests as it goes The policy satisfies the customer stated requirements
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