[ §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