1
REQUIREMENT ENGINEERING TECHNIQUES
AND RISK MANAGEMENT
CHAPTER-7
Prepared by: Berhanu S.
Methods for RE
2
A method is a degree more prescriptive than a modelling
approach – it tells us what to do to and in what order to do it.
Methods use various representations ranging from natural
language, through diagrammatic forms to formal mathematics.
The methods indicate when and where to use such
representations.
The methods that use diagrammatic representations are usually
referred to as “structural methods”; those that use object
orientation are referred to as “object-oriented methods” and
those that use mathematics are referred to as “formal
methods”.
Continued…
3
The purpose of the representations used in a method is to
capture information.
Requirements engineering is a distributed process involving
many participants with different interests
Methods based on rigid global schemes do not adequately
address the diversity of issues presented by RE problems.
Methods based on the notion of viewpoints evolved to
address the problem
Viewpoints, perspectives and views
4
Viewpoint is defined as a standing position used by an
individual when examining a universe of discourse.
A perspective is defined as a set of facts observed
and modelled according to a particular aspect of
reality
A view is defined as an integration of these
perspectives
A viewpoint language is used to represent the
viewpoints
Viewpoint-oriented Requirements Methods
5
A viewpoint is a way of organising the requirements for a software
system, based on some perspective such as an end-user perspective
or a manager's perspective
A viewpoint is a collection of information about a system or related
problem, environment or domain which is collective from a particular
perspective.
A viewpoint-based approach to requirements engineering
recognizes that requirements should not be considered from a single
perspective.
Viewpoint-oriented approaches to requirements engineering
organise both the elicitation process and the requirements
themselves using different viewpoints.
Continued…
6
A viewpoint method is seen here as a requirements engineering
process of identifying viewpoints, reasoning within a viewpoint,
reasoning between different viewpoints, and revising a viewpoint.
A key strength of viewpoint-oriented analysis is that it recognises the
existence of multiple perspectives and provides a framework for
discovering conflicts in the requirements proposed by different
stakeholders.
The requirement sources may be from stakeholders, other systems
that interface with the proposed system, or other entities in the
environment of the proposed system
Each requirement source is then considered to be a viewpoint
There are three generic types of viewpoint
1. Direct viewpoints that represent people or other systems that
interact directly with the system. E.g. Interactor viewpoints are the
bank’s customers and the bank’s account database.
2. Indirect viewpoints that represent stakeholders who do not use the
system themselves but who influence the requirements. E.g. the
management of the bank and the bank security staff.
3. Domain viewpoints that represent domain characteristics and
constraints that influence the system requirements. E.g. standards that
have been developed for inter-bank communications.
Viewpoint hierarchy
8
Fig 7.1 . Viewpoint hierarchy for library system
Requirement to viewpoint Mapping
9
Requirement to viewpoint interactions
10
Method based on viewpoint
11
The following sections consider three different methods
based on viewpoints
I. Controlled Requirements Expression (CORE)
II. Structured Analysis and Design Technique (SADT)
III. Viewpoint-oriented Requirements Definition (VORD)
I. Controlled Requirements Expression (CORE)
12
The Controlled requirements expression method is based on functional
decomposition approach.
Focus on defining the context of a solution to a problem, rather than
attempting to define the problem itself
The central concept of CORE is the viewpoint and the associated
representation known as the viewpoint hierarchy.
A viewpoint can be a person, role or organization that has a view about an
intended system.
When used for system requirements, the viewpoints can also represent the
intended system, its subsystems and systems that exist within the
environment.
The viewpoints are organized in a hierarchy to provide a scope and also to
guide the analysis process.
[Link] Analysis and Design Technique (SADT)
13
SADT is a method of structured analysis
It is graphically oriented and adopts a purely hierarchical approach to the
problem with a succession of blueprints both modularizing and refining it
until a solution is achieved.
The basic element of SADT is the box, which represents an activity (in
activity diagrams) or data (in data diagrams).
Input arrows enter the box from the left side, and represent data that is
available to the activity represented by the box.
Output arrows exit the box from the right side, and represent data that is
produced by the activity represented by the box
Control arrows enter the box from the top and govern the way in which the
transformation takes place.
Mechanism arrows enter the box from below and control the way in which
III. Viewpoint-oriented Requirements Definition (VORD)
14
VORD (Kotonya and Sommerville, 1996) is a method based on viewpoints.
A viewpoint is represented by a rectangle, which contains an identifier, label and
type.
The model used is a service-oriented one, where the viewpoints are considered to be
clients, if one was to think of it as a client–server system.
A viewpoint in VORD receives services from the system and in turn passes control
information to the system.
It specifically attempts to look at all the entities that will interact or otherwise use the
services of the system.
The service-oriented approach makes VORD suited for specifying interactive systems.
There are three main iterative steps in VORD:
viewpoint identification and structuring;
viewpoint documentation;
Advantages of viewpoint-oriented approaches
15
They explicitly recognise the diversity of sources of
requirements
They provide a mechanism for organising and
structuring the diverse information
They imparts a sense of completeness
They provide a means for requirements sources or
stakeholders to identify and check their contribution to
the requirements
Viewpoint Analysis Methods
16
The methods are analysed based on the following points:
The identification of a viewpoint.
The reasoning within individual viewpoints, e.g., to check the
internal consistency of a view.
The reasoning between different viewpoints, e.g., comparison of
disparate views, conflict analysis.
The revision of a viewpoint, e.g., the modification of a view to
restore consistency, fitting in new information, or the creation of
a new viewpoint.
Viewpoint-oriented requirements validation
17
Uses viewpoints to support early requirements validation
Objective of the approach is identify and classify problems related
to completeness and correctness
Viewpoint resolution is a validation method in the early stages of the
requirement elicitation phase.
Viewpoint resolution is about the disparities between two different
viewpoints and, the analysis and evaluation of these disparities and
also to integrate these different solutions to form a single
representation.
Viewpoint-oriented requirements validation
18
Two functions occur in viewpoint resolution.
Those functions are Viewpoint analysis and Viewpoint
reconciliation.
The viewpoint analysis deals with the fact validation of
requirements and reconciliation works in the communication part
of the requirement engineering process.
The viewpoint resolution is focused on the problems in identifying
the differences and evaluating these differences.
Risk Management in software requirement
19
Risk is defined as a combination of two factors: probability of
malfunctioning (failure) and the consequence of malfunctioning
(severity).
Risk = Probability of undesired event * Severity of undesired event
Risk Management is defined as the activity that identifies a risk
assesses the risk and defines the policies or strategies to lessen the
risk.
The risk management’s activities at requirement engineering level.
The purpose of these activities is to find risk associated to
functional requirements.
Continued…
20
Software requirement’s risk addresses the possibility of suffering a
loss of any functional or non-functional requirement of the software
system.
It is more feasible to make changes to the software system under
development in the early stages of the software development cycle
Functional requirements are converted in UML scenario. A model is
derived which calculate risk of these requirements. Calculated risk
determines how much attention is required to fulfil this requirement.
Functional requirements represent how product works. Confusion in
functional requirements will have an effect on product’s functionality
therefore inconsistency on functional requirements should be
removed at initial stage.
Risk Management in software requirement
21
Figure 2 risk management in requirement
Risk Management during Requirements Engineering Process
22
In software engineering, risk is usually considered and
analysed during, or even after, the system design
Countermeasures are elaborated and then accommodated
as a refinement of the design, when a limited number of
changes are still possible and they may introduce the
problem of revisiting the initial requirements
Most of the High Level Risks lie in the early phase of the
software development. i.e. Requirement Engineering and
Planning phase.
The extent of High Level Risk decreases with respect to
phases of software development.
Continued…
23
If the errors are not corrected in the requirement engineering phase,
the project can be cancelled due to time and budget overrun.
The improper requirement engineering management has often proved
to be the biggest cause of the software projects disasters.
The main purpose of risk analysis understands the risks in better ways
and to verify and correct the attributes.
A successful risk analysis includes important elements like problem
definition, problem formulation, data collection.
Some of the requirement risks are Poor definition of requirements,
Inadequate of requirements, Lack of testing, poor definition of
requirements etc.
The likelihood of the events which tends to the goal can be evaluated
from the evidence of Satisfaction and denial of the goal and it can be
achieved through Tropos goal model.
MODELS OF RISK ANALYSIS WITHIN RE CONTEXT
24
Goal- driven software development risk management
modelling (GSRM)
The Goal- driven software development risk management
modelling (GSRM) framework is established to assess, reason,
control, and trace software development risk.
This model consists of four layers of Goal layer, Risk obstacle
layer, Assessment layer and Mitigation layer.
The main focus is to integrate risk management activities within
RE phase so that risks are identified and controlled from the
early stage.
Continued…
25
Risk Tree Assessment
Risk tree possesses many events. The lowest level events are
called primary events. In the middle, intermediate events exist
and the highest level event is called the top event.
All the events are connected in a tree by gates that show the
relationship between successive levels of the tree.
Risk tree depicts the logical interrelationships of the basic events
that lead to the top events.
The risk tree is represented by three types of graphic symbols:
logic gates, events and transfer triangles. The most common
symbols and basic components used for risk tree construction and
Continued…
26
Figure 3 risk tree
Thank You!
Quiz
28
1. Write down the three generic types of viewpoint
with examples