Payoff Analysis in GoalOriented Requirements Engineering

1
Payoff Analysis in Goal-OrientedRequirements
Engineering
1,2Emmanuel Papadacci 2Camille
Salinesi2Colette Rolland
2CRI, Université Paris I - Panthéon
Sorbonne1Information Systems and Technologies
Division, Renault
2
Context
User
RE engineer
Needs
Specification
3
Introduction

• Relevance of the requirement prioritisation at
  Renault to perform large scale IS study
• Need to elicit, manage large scale study at the
  requirements level
• Need to be guided by a methodology to take
  decisions between the future possible systems
• Requirements prioritisation can be defined as
  setting ranks to, or rating, a collection of
  requirements based on given criteria such as
  goals, risks, quality, or usefulness and
  according to the viewpoint of various
  stakeholders (Moisiadis F., The Fundamentals Of
  Prioritising Requirements, Systems Engineering,
  Test Evaluation Conference, Sydney, Australia,
  2002)

4
Summary of the state of the art

• Only a few requirements prioritisation approaches
  are available
• Two kind of prioritisation approaches
• Pair wise requirement comparisons based on a
  predefined ratio scale
• Absolute requirement comparisons on a predefined
  scale
• Three examples of main prioritisation approaches
  
• Karlssons cost/value approach
• Wiegers' approach
• The Distributed Collaborative Prioritisation
  (DCPT)

5
Disadvantages of these methods
The needed number of comparisons to have
consistency results is proportional to the square
of the number of requirements

• All these approaches gt consider the requirements
  of a requirements collection

It is impossible to achieve these methods in very
large scale requirements analysis as an urbanism
study at Renault
6
Managing requirements of large IS projects

• Decisions that stakeholders have to make are
  about a bundle of requirements against another
  bundle of requirements rather than about a
  requirement against another requirement
• Focus on Business Systems which design results
  could directly be modeled from needs expressed at
  the business level

• Our position is that requirements bundles are
  design options which directly relate to the
  business needs
• Be linked to strategies chosen to achieve
  business goals
• Be constrained by the different relationships
  between business goals and strategies
• Dispatching of requirements into several levels
  of abstraction could be exploited to
  significantly reduce the number of comparisons
  needed during prioritisation

7
Overview of our proposition

• Aims of the proposition
• Proposing a prioritisation approach that guides
  the ranking of design options with respect to
  Cost/Value decision criteria
• At a given level, the design options to
  prioritise are chosen according to a number of
  rules. These rules depend on constraints between
  requirements expressed with business goals and
  strategies
• Top-down approach all the results of a
  prioritisation achieved on a level are propagated
  to reduce the number of comparisons needed on a
  lower level

8
Outline

• The outline of this presentation is
• Identification and specification of design
  options
• Description of our approach for the
  prioritisation of design options
• Generalization of the approach and setting it
  into a larger methodological RE context
• Conclusion and future works

9
1. Identification and specification design option
10
Overview of the Map model

• Identification and specification design option
• Description prioritisation process
• Generalization
• Conclusion and future works

• The goal/strategy map formalism has been
  experimented several times in the RE context
• A goal/strategy map is a graph model composed of
  business goals and strategies gathered into map
  sections
• A goal is a business objective that the system
  shall support
• A strategy is an approach, a manner to achieve a
  goal
• A section is an aggregation of two kinds of
  goals, the source and target, together with a
  strategy. Each section can be refined into a
  submap.
• A map together with the sub-maps that refine its
  sections constitute a hierarchy of maps

11
Requirement in the Map model

• Identification and specification design option
• Description prioritisation process
• Generalization
• Conclusion and future works

We postulate that a section a requirement
12
Structural links between requirements

• Identification and specification design option
• Description prioritisation process
• Generalization
• Conclusion and future works

• A structural link between two requirements (A,B)
  expresses a constraint that the achievement of
  requirement A puts on requirement B
• Such links are used to avoid inconsistencies
  while defining design options
• Different kinds of structural links are defined
  in goal/strategy maps
• Exclusive link (the bundle link) Introducing the
  requirement A in a design option is forbidden if
  the requirement B is already introduced
• Complementary links (the thread and the path
  links) Introducing the requirement A in a
  design option is only possible if the requirement
  B is already introduced
• Refinement link The requirement A is refined by
  the requirement B

13
Defining design options

• Identification and specification design option
• Description prioritisation process
• Generalization
• Conclusion and future works

• Design options specify systems
• Each system meets a number of given requirements
  which are gathered under the form of a design
  option
• Each design option is thus a high level
  description of the requirements selected for the
  future system
• Design options are alternatives with each other,
  but the requirements fulfilled by a design option
  can also be fulfilled by another design option

14
2. Description of our approach for the
prioritisation of design options
15
Overview of the main concepts used in the process

• Identification and specification design option
• Description prioritisation process
• Generalization
• Conclusion and future works

Decision criteria

• Decision criteria assess the relevance of
  requirements
• We use two decision criteria, the cost and the
  value
• Real-world concerns of decisional stakeholders
• Adequate to evaluate or compare the Return On
  Investment (ROI) of design option

Priority

• A priority is a rank of importance of an element
  in a collection of comparable elements according
  to a decision criteria
• Priorities are defined as a decimal values
  comprised between 0 and 1 such that the sum of
  priorities of a collection of elements is equal
  to 1
• Two kinds of priority
• Requirement priority
• Design option priority

16
Prioritisation process

• Identification and specification design option
• Description prioritisation process
• Generalization
• Conclusion and future works

• Instead of directly comparing design options, our
  process suggests to
• Step 1 Analyze the priority of each individual
  requirements R with respect to the multiple
  design option model Ri to which they belong,
• Step 2 Propagate the priority of individual
  requirements on the priority of other
  requirements that belong to the same design
  options, and
• Step 3 Compute the priority of design options
  based on the priority of the requirements that
  compose them.

17
Step 1 Analyzing the priority of individual
requirements

• Identification and specification design option
• Description prioritisation process
• Generalization
• Conclusion and future works

• We use AHP to prioritise individual requirements
  in the context of the multiple design option
  model they belong to
• The main principle of the AHP is to compare
  alternatives and measures their contribution to
  some objectives
• We use it to compare pairs of requirements with
  respect to a decisional criteria, and using a
  predefined ratio scale table
• Our adaptation of the AHP is as follows
• Requirements are identified by sections in a
  goal/strategy map
• Requirements are only compared to other
  requirements identified by other sections in the
  same multiple design option map model
• The approach is applied twice once with respect
  to cost, and the second time with respect to
  value.

18
Step 2 propagating the priority of individual
requirements

• Identification and specification design option
• Description prioritisation process
• Generalization
• Conclusion and future works

• A synergy link specifies the effect of selecting
  a requirement on the priorities of another
  requirement.
• To each synergy link is associated a factor that
  indicates how the priority of the target
  requirement decreases or increases with respect
  to a decision criteria when the source
  requirement is introduced into the same design
  option.
• Synergy factors can be positive or negative
• A positive synergy factor multiplies the priority
  of the target requirement
• a negative synergy factor divides it

19
Step 3 computing the priority of design options

• Identification and specification design option
• Description prioritisation process
• Generalization
• Conclusion and future works

• Priority of a design option as the sum of the
  requirements priorities that compose it weighed
  by the related synergy factors
• Priorities of design options are normalized so
  that the sum of all priorities is equal to 1

20
Graphical presentation of the priorities

• Identification and specification design option
• Description prioritisation process
• Generalization
• Conclusion and future works

21
3. Generalization the approach and setting it
into a larger methodological RE context
22
Integrating our approach in the larger context of
SE and RE

• Identification and specification design option
• Description prioritisation process
• Generalization
• Conclusion and future works

• The approach is integrated in the SE context as
  follows
• Context Meant to be used at the stage of early
  requirements elicitation when initial decisions
  on the architecture design have to be made
• Pre-condition a complete requirements
  collection should have already been elicited
• Preparation phase Sort out requirements
  depending on there level of abstraction, and
  model them in the Map formalism
• Beginning phase The different possible futures
  are considered in respect of constraints using
  the structural links
• End phase A unique design option, expressed as
  a subset of the initial requirements collection
  is identified as proprietary
• An iterative process
• The requirements belonging to the selected design
  options can be represented under the form of
  goal/strategy maps organized into a hierarchy
  through refinement links
• Refinement allows to explore the selected design
  option. If some sub design options appear, we
  perform again the prioritisation process

23
Using the approach in other methodological
contexts

• Identification and specification design option
• Description prioritisation process
• Generalization
• Conclusion and future works

• Our approach assumes the use of the goal/strategy
  map formalism to identify requirements
• If none of these requirements modeling techniques
  are used, and the requirements are only expressed
  as natural language sentences, then an
  abstraction work should be undertaken to abstract
  them under the form of goal/strategy maps
• A side effect of the resulting goal models is
  that they tend to improve the understanding of
  the requirements, to provide a larger view on its
  intended context of use, and to allow a better
  organization of the requirements documentation
• Other requirements modeling techniques had to
  support
• The refinement mechanism and
• The modeling of alternative design options

24
4. Conclusion and future works
25
Originality of the approach

• Identification and specification design option
• Description prioritisation process
• Generalization
• Conclusion and future works

• The originality of our requirement priority
  techniques stands in the fact that
• It aims at prioritizing design options rather
  than just individual requirements
• It is based on the analysis of hierarchically
  organized requirements collections rather than
  flat collections of requirements
• It uses synergy links to propagate the influence
  of requirements priorities on each other
• It exploits the refinement mechanisms to support
  the analysis of priorities on different levels of
  abstractions in a top down fashion

26
Future works

• Identification and specification design option
• Description prioritisation process
• Generalization
• Conclusion and future works

• We want to apply our approach to a case study
  drawn from real world project at Renault to
  evaluate its efficiency and its scalability
• Then, we want to adapt the method to support
  payoff analysis of scenario evolution