Aucun titre de diapositive

1
From conceptual modelling to requirements
engineering
 
Colette Rolland Université de Paris1 Sorbonne
2
From conceptual modelling to requirements
engineering
Capturing relevant aspects of some excerpt of
the world in a model
From Structure
 
Understanding the purpose of the system to-be
To Intention
3
From Conceptual Modelling to Requirements
Engineering
Outline

• Goal oriented RE for purposeful systems
  conceptualisation
• From mono-facetted to multi-facetted purpose
  systems
• Modelling MFP systems with maps
• Customizing MFP systems

4
The Requirements Problem

• Poor requirements are major (gt 50) source of
  failure
• (Standish 95) 8000 projects, 350 US companies
• Success 16 failure 33 so so 51

• Most perceived problems are related to
  requirements specification ( gt50) - (ESI96)
  3800 organisations in 17 European countries

• Poor requirements capture, specification and
• management explain more than 60 of failures
• (MEGA report 2002)

5
Requirements Engineering
Requirements definition must say.. - why a
system is needed, based on current or foreseen
conditions, - what system features will
satisfy this context, . (Ross77)

• The WHY question
• Why the system needs to be developed?

• The WHAT question
• What the system shall do?

IEEE Computer 85, IEEE SE 91-92, Bubenko94,
Mylopoulos92, Dardenne93, Loucopoulos95,
Rolland98, Lamsweerde 00 etc..
6
Requirements Engineering
High concentration on the software functionality
specification and not enough on its rationale
7
RE Framework
2 sources of requirements
8
RE Framework
2 sources of requirements
Representation relationship is essential to
understand Information semantics
The social perspective
SUBJECT
WORLD
System Environment
Representation relationship
USAGE
WORLD
SYSTEM
WORLD
9
RE Framework
2 sources of requirements
Understanding the Domain Genericity Relationship
helps eliciting generic requirements
The social perspective
SUBJECT
WORLD
System Environment
Domain Genericity relationship
USAGE
WORLD
SYSTEM
WORLD
10
RE Framework
2 sources of requirements
The social perspective
SUBJECT
WORLD
System Environment
USAGE
WORLD
SYSTEM
WORLD
11
Goal Driven RE
Mission statement, goals
WHY ?
The Requirements Engineering process
Goal operationalisation
Requirements Specification
WHAT ?
12
Goal Driven RE
Goals have useful characteristics
Goals are optative statements (as opposed to
descriptive), (Jackson95), expressions of
intents Ex Transport passengers safely Ensure
customer loyalty

13
Goal Driven RE
Goals cover different types of concerns

• functional goals what the system is expected
  to do
• non-functional goals quality of the system
  behaviour
• security, safety, accuracy,
• performance, cost, usability,
• adaptability,

Help eliciting functional and non functional
requirements
14
Goal Driven RE
Goals are expressed at different levels of
abstraction

• Increase the number of
• contracts by 20

Help aligning strategy, tactics and system
requirements
15
Goal Driven RE

• Goals provide rich structuring mechanism (AND/OR
  refinement)

Goals drive the RE process
16
Goal Driven RE
Goals are roots for conflict detection
resolution
Satisfy customer request
Satisfy book request
Provide long borrowing period
Satisfy bibliography request

Maintain regular availability
Maintain as many copies as needed
17
Goal Driven RE
Goals proved to play useful roles in RE

• requirements elicitation
• exploration of system choices
• requirements completeness
• requirements pre-traceability
• detection resolution of conflicts
• documentation
• negotiation
• evolution change

Contributing to the purposefulness of systems
18
Goal Driven RE
Goals are recognised to play an important role in
RE
But some difficulties in practice

• Relating goals to other concepts
• problem, opportunity, thread, (EKD,Bubenko94)
• objects, (Dardenne91, Mylopoulos92, Prat97,
  Rolland98)
• The golden triplet goal, scenario agent
• scenarios, (Fickas92, Potts95, Leite97,
  Sutcliffe 98, Haumer98, Rolland98, Anton98)
• agents (responsibility- Kaos,Leiter01), (goal
  dependency- I,Yu93)

19
Goal Driven RE
Room for research on intentionality and its
relationship with conceptual modelling !
20
Modelling the Multi-Facetted Purpose of Systems
Outline

• Goal driven RE for purposeful systems design
• From mono-facetted to multi-facetted purpose
  systems
• Modelling MFP systems with maps
• Customizing MFP systems

21
Mono-facetted purpose
Dealing with a mono-facetted purpose
One single set of requirements (green) shaping
one single implemented system functionality
22
Multi-facetted purpose
New context of IS product development
From meeting the purpose of a single organisation
and single set of customers IS products must be
conceived to meeting the purpose of different
organisations and be adaptable to different
usage situations customer sets
Capturing variability (to differentiate
commonalities and variants) in systems
conceptualisation
23
From goal satisfaction towards goal achievement
Dealing with a multi-facetted purpose
Several sets of alternative requirements shaping
multiple alternative system functionalities
24
Modelling the Multi-Facetted Purpose of Systems
Outline

• Goal driven RE for purposeful systems design
• From mono-facetted to multi-facetted purpose
  systems
• Modelling MFP systems with maps
• Customizing MFP systems

25
Modelling MFP with Maps
A map allows an intentional representation of an
IS product through a flexible ordering of
intentions and strategies
A goal aims at some situation that an
organisation wants to reach through one or
several business processes and using the IS
support
A strategy is a means or manner to achieve a goal
A map is a directed labelled graph with
intentions as nodes and strategies between them
26
Modelling MFP with Map
The SAP Material Management map MM map
Start
Inventory balance strategy
Quality inspection strategy
By planning
Reservation strategy
Monitor Stock
By Reminder
Manually
Purchase Material
Valuation strategy
Out-In strategy
Bill for expenses strategy
In-In strategy
Financial control strategy
Stop
27
Modelling Facets with Maps
A map represents the IS purpose in its
totality Each section ltIi, Ij, Sijgt ltIntention
Ii, Intention Ij, Strategy Sijgt of a map
represents a facet
ltSatisfy Material Need Efficiently gt is the MM
intention
28
Modelling MFP with Map
Map
Map meta-model
Path
Refined by
source
Section
Link
target
Target Intention
Strategy
Source Intention
Intention
Start
Stop
29
Modelling MFP with Maps
The multi-thread and multi-path topologies
serve to capture multi-faceting variability
with multithread and composite faceting with
multi-path
Multi-thread topology
Multi-path topology
30
Modelling MFP with Maps
Refinement allows to look to the multi-facetted
nature of a facet. It introduces levels in MFP
representation which is fully modelled as a
hierarchy of maps
Map refinement A section in a map might be
itself deployed as a map
Purchase material
C5
Monitor stock
By out-in strategy
31
Modelling the MFP through a hierarchy of maps

• The purpose of the artefact is captured in
• a hierarchy of maps
• At any given level of the hierarchy,
• the multi-facetted dimension is based on
• multi-thread and multi-path topologies
• Multi-thread introduces local faceting
• Multi-path introduces global faceting

32
Modelling variability supporting adaptability
A large research area for conceptual modelling
experts !

• ERP systems
• Adapted CRM
• Software Product lines and families
• Business process models lines families
• etc.

33
Modelling the Multi-Facetted Purpose of Artefacts
Outline

• Goal driven RE for purposeful systems design
• From mono-facetted to multi-facetted purpose
  systems
• Modelling MFP systems with maps
• Customizing MFP systems

34
Adaptation towards aligning functionality
purpose
ERP Installation
Avoiding the  conceptual mistmatch  
(Arsajanasi01)
35
Aligning functionality purpose
ERP Installation
36
Aligning functionality purpose
ERP Installation
ERP/ MIGHT BE Map
The Matched Map
As-Is As-Wished Maps
37
The alignment process
Aligning business requirements with ERP
functionality in SNCF
Aligning
38
The alignment process
Introducing similarity measures
As-Wished
Map
Map
Map
To-Be
Similarities Analysis
As-Is
Matching Process
Map
Map
Matched Map
Map
Map
Map
Might-Be
Map
Map
Map
39
Adaptation to meeting evolution requirements
Global deployment of IS

• Uniform installation of an information system to
  support financial activities of RENAULT worldwide

FUSE
40
The evolution process
Introducing Gaps
As-Wished
Map
To-Be
Gaps Analysis
As-Is
Gaps
Matching Process
Map
Matched Map
Might-Be
Map
41
Questions Comments
Thank You