4 : 1

1
4. Requirements Processes II

• Overview
• 4.1 Fundamentals
• 4.2 Elicitation
• 4.3 Specification
• 4.4 Verification
• 4.5 Validation

Software Requirements Specification
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

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
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(?)

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

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

7
Specification after Elicitation
8
Running Case Study Elevator

• Consider the development of an elevator control
  system for a 10-story residential building.

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

10
Specification after Allocation
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

12
Distributed Controller

• Additional internal interfaces have been
  identified
• The specification rules out a centralized
  implementation
• Architecture is constrained accordingly

Elevator controller
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

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.

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

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