Institutt for datateknikk og
informasjonsvitenskap
Inah Omoronyia and Tor Stålhane
Requirements Specification and Testing
An introduction
TDT 4242
TDT 4242
Challenges in Requirements Engineering
What is a requirement?
• What a system must do (functional):
System requirements
• How well the system will perform its functions (non-functional):
System quality attributes
The RE process:
Ultimately:
defined
operational
capabilities
satisfy
business
needs
TDT 4242
Challenges in Requirements Engineering
TDT 4242
Challenges in Requirements Engineering
Importance of getting requirements right:
1/3 budget to correct errors originate from requirements
Source: Benoy R Nair (IBS software services)
TDT 4242
Challenges in Requirements Engineering
Factors that make a software project challenging:
Source: Benoy R Nair (IBS software services)
TDT 4242
Challenges in Requirements Engineering
Why projects are cancelled:
Source: Benoy R Nair (IBS software services)
TDT 4242
Requirements Development - 1
Requirements Elicitation:
The process of discovering the requirements for a system by
communication with customers, system users and others who have a
stake in the system development.
Requirements gathering techniques
•
•
Methodical extraction of concrete requirements from high
level goals
Requirements quality metrics
TDT 4242
Requirements Development – 2
Effects of Inadequate Requirements development – Ariane 5:
(An expendable launch system used to deliver payloads into
geostationary transfer orbit or low Earth orbit)
Ariane 5 succeeded Ariane 4. Wrong implicit assumptions about the
parameters, in particular the horizontal velocity that were safe for
Ariane 4 but not Ariane 5.
•
horizontal velocity exceeded the maximum value for a 16 bit unsigned integer
when it was converted from it's signed 64 bit representation.
•
Ariane 5: component (requirements) should have been designed for reuse –
but the context of reuse was not specified.
Cost of poor requirements in Ariane 5
• Data overflow on launch
• Self-destruction of the complete system
• Loss > 500 Million EUR
TDT 4242
Requirements Development – 3
Effects of Inadequate Requirements development – Airbus:
Requirement: Reverse thrust may only be used, when the airplane is
landed.
Translation: Reverse thrust may only be used while the wheels are
rotating.
Implementation: Reverse thrust may only be used while the wheels
are rotating fast enough.
Situation: Rainstorm – aquaplaning
Result: Crash due to overshooting the runway!
Problem: erroneous modeling in the requirement phase
TDT 4242
Problem world and machine solution
The problem to be solved is rooted in a complex organizational, technical or physical
world.
• The aim of a software project is to improve the world by building some machine
expected to solve the problem.
• Problem world and machine solution each have their own phenomena while sharing
others.
• The shared phenomena defines the interface through which the machine interacts
with the world.
E-commerce world
Requirements engineering is concerned with the machine’s effect on the
surrounding world and the assumption we make about that world.
TDT 4242
Formulation of requirements statements
Statement scope:
• Phenomenon of train physically moving is owned by environment. It
cannot be directly observed by software phenomenon
• The phenomenon of train measured speed being non-null is shared by
software and environment. It is measured by a speedometer in the
environment and observed by the software.
TDT 4242
Two types of requirements statements
• Descriptive statements: state properties about the system
that holds regardless of how the system behaves. E.g. If train
doors are open, they are not closed.
• Prescriptive statements: States desirable properties
about the system that may hold or not depending on how the
system behaves
• Need to be enforced by system components
• E.g. Train doors shall always remain closed when the
train is moving
TDT 4242
Formulation of system requirement
A prescriptive statement enforced by the software-to-be.
• Possibly in cooperation with other system components
• Formulated in terms of environment phenomena
Example:
All train doors shall always remain closed while the train is
moving
In addition to the software-to-be we also requires the
cooperation of other components:
• Train controller being responsible for the safe control
of doors.
• The passenger refraining from opening doors
unsafely
• Door actuators working properly
TDT 4242
Formulation of software requirement
A prescriptive statement enforced solely by the software-tobe. Formulated in terms of phenomena shared between the
software and environment.
The software “understand” or “sense” the environment
through input data
Example:
The doorState output variable shall always have the value
‘closed’ when the measuredSpeed input variable has a nonnull value
TDT 4242
Domain properties
A domain property:
• Is a descriptive statement about the problem world
• Should hold invariably regardless of how the system
behaves
• Usually corresponds to some physical laws
Example:
A train is moving if and only if its physical speed is non-null.
TDT 4242
Goal orientation in requirements engineering – 1
A goal is an objective that the system under
consideration shall achieve.
– Ranges from high-level strategic to low-level
technical concerns over a system
– System consist of both the software and its
environment. Interaction between active
components, i.e. devices, humans, software etc
also called Agents
TDT 4242
Goal orientation in requirements engineering – 2
Goals can be stated at different levels of granularity:
– High-level goal: A goal that requires the cooperation of
many agents. They are normally stating strategic
objective related to the business, e.g.
The system’s transportation capacity shall be increased
by 50%
– Requirement: A goal under the responsibility of a
single agent in the software-to-be.
– Assumption (expectation): A goal under the
responsibility of a single agent in the environment of
the software-to-be. Assumptions cannot be enforced by
the software-to-be
TDT 4242
Goal statement typology
TDT 4242
Goal types
TDT 4242
Behavioral goal specialization
TDT 4242
Goal categorization – 1
Goal categories are similar to requirements categories:
TDT 4242
Goal categorization – 2
Functional goal: States the intent underpinning a system
service
•
Satisfaction: Functional goals concerned with
satisfying agent request
•
Information: Functional goals concerned with keeping
agents informed about important system states
•
Stimulus-response: Functional goals concerned with
providing appropriate response to specific event
Example: The on-board controller shall update the train’s
acceleration to the commanded one immediately on
receipt of an acceleration command from the station
computer
TDT 4242
Goal categorization – 3
Non-functional goal: States a quality or constraint on
service provision or development.
Accuracy goal: Non-functional goals requiring the state of
variables controlled by the software to reflect the state of
corresponding quantities controlled by environment agent
E.g: The train’s physical speed and commanded speed
may never differ by more than X miles per hour
Soft goals are different from non-functional goals. Soft goals
are goals with no clear-cut criteria to determine their
satisfaction.
E.g: The ATM interface should be more user friendly
TDT 4242
Goal refinement
A mechanism for structuring complex specifications at different levels of
concern.
A goal can be refined in a set of sub-goals that jointly contribute to it.
Each sub-goal is refined into finer-grained goals until we reach a
requirement on the software and expectation (assumption) on the
environment.
NB: Requirements on software are associated with a single agent and
they are testable
TDT 4242
Goal refinement: Example
TDT 4242
Goal refinement tree – 1
Refinement links are two way links: One showing goal decomposition, the
other showing goal contribution
TDT 4242
Goal refinement tree – 2
Goal feature annotation
TDT 4242
Requirements quality metrics – 1
Qualitative Goal-Requirements tracing:
An approach to requirements
refinement/abstraction that makes it
less likely to generate trace links that
are ambiguous, inconsistent, opaque,
noisy, incomplete or with forward
referencing items
TDT 4242
Requirements quality metrics – 2
Ambiguity: Requirement with terms or statements that can
be interpreted in different ways. Sub-class concept
reasoning:
Inconsistency: Requirement items that are not compatible
with other requirement nodes. Predefined semantic
reasoning
– Cc
TDT 4242
Requirements quality metrics – 3
Forward Referencing: Requirement items that make
use of problem world domain features that are not yet
defined.
E, C and D need to be mapped to a requirement item
TDT 4242
Requirements quality metrics – 4
Opacity: Requirement items for which rational or
dependencies are invisible.
Multiple unrelated concept mapping. A is not related to B
TDT 4242
Requirements quality metrics – 5
Noise: Requirement items that yield no information on
problem world features. X refers to a concept undefined
in the domain
TDT 4242
Requirements quality metrics – 6
Completeness: The needs of a prescribed
system are fully covered by requirement
items without any undesirable outcome.
No requirement item mentions the goal
concept Z
TDT 4242
Requirements quality metrics
Quality metrics on a requirements set provides useful
understanding, tracking and control of requirements
improvement process.
Where do the goals come from?
We get goals from:
• Preliminary analysis of the current system.
• Systematically by searching intentional keywords
in documents provided, interview transcripts etc.
E.g. ‘objective’, ‘purpose’, ‘in order to’.
• Iterative refinement and abstraction of high-level
goals: By asking the how and why question. Results
in a goal refinement tree
• Approaches: KAOS – Goal driven requirements
acquisition.
TDT 4242
Summary
Goals can be defined at different levels of
abstraction
There are two types of goals: Behavioral or soft goal
There are several categories of goals, e.g.
• Functional and non-functional
• Goal refinement provides a natural mechanism
for structuring complex specifications at
different levels of concern:
• Goal refinement graph
TDT 4242