Towards Goal-oriented Analysis and Redesign of BPMN Models

Christophe Ponsard

and Robert Darimont

CETIC Research Centre, Gosselies, Belgium

Respect-IT SA, Louvain-la-Neuve, Belgium

Keywords:

Business Process Modelling, Goal-oriented Requirements Engineering, Model-Driven System Development,

Model Analysis, Model Improvement.

Abstract:

The Business Process Management lifecycle involves identifying, analysing and evolving the design of an

organisation’s tasks. Modelling plays a key role in those activities to capture the processes but also the related

goals representing the rationale behind them. While some mappings have been deﬁned between such models,

they lack guidelines to support analysis or (re)design activities in order to improve processes in an evolving

organisation. The purpose of this paper is to propose a two-staged guidance: (1) a lightweight approach

leaving the goal model implicit but using goal reasoning techniques; and (2) an heavier approach where an

explicit goal model is explicitly built and mapped to support the redesign process. Our work is experimented

on a running case study inspired from a logistics system. Although still in progress, we were able to uncover

interesting problems and to suggest relevant redesigns.

1 INTRODUCTION

A business process consists of a set of activities that

are performed in coordination in an organisational

and technical environment. These activities jointly

realise a business goal (Weske, 2012). Organisations

need to make sure that their business processes are

correctly deﬁned and kept aligned with their strate-

gic goals. This is achieved through Business pro-

cess Management (BPM), a disciplined approach to

identify, design, execute, document, measure, mon-

itor, and control both automated and non-automated

business processes to achieve consistent, targeted re-

sults (ABPMP, 2011).

A typical BPM lifecycle is depicted in Figure 1.

The focus of this paper is on ﬁrst two steps: the pro-

cess analysis and process redesign. In those steps, ex-

isting processes are ﬁrst analysed and then modiﬁed

in order to address a number of weaknesses resulting

from possible evolutions of the organisation’s goals,

internal capabilities or changes in the environment.

Standard notations to capture business processes

are known to be widely available and adopted by com-

panies, especially the Business Process Modelling

Notation (BPMN) (OMG, 2011) is known by 64% of

companies and 40% are using model-oriented tooling

according a recent survey (Harmon, 2016). However,

the same survey also reveals that companies have not

yet reached a high level of BPM maturity given one

third of the companies seeing it as a rather static top-

down process. There is also little update in the doc-

umentation nor monitoring in more that half of the

companies.

Figure 1: Business process management lifecycle.

The beneﬁts of capturing goals along with busi-

ness processes are well known: it helps focusing

on the relevant activities, exploring alternatives, as-

sessing how well a process operates and understand-

ing its impact on the whole organisation (Kueng and

Ponsard, C. and Darimont, R.

Towards Goal-oriented Analysis and Redesign of BPMN Models.

DOI: 10.5220/0007687405270533

In Proceedings of the 7th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2019), pages 527-533

ISBN: 978-989-758-358-2

 2019 by SCITEPRESS – Science and Technology Publications, Lda. All r ights reserved

527

Kawalek, 1997). However popular notations like

BPMN provide little explicit support for goals and are

rather focusing on the operational side.

For strategic goal modelling, different architec-

ture enterprise frameworks are available. While the

Zachman framework (Zachman, 2003) only provides

the ability to list goals and to work with tables, TO-

GAF (The Open Group, 2009) can reference them in

composite diagrams enabling some graphical mod-

elling of business alignment. Archimate (The Open

Group, 2017) provides a more elaborated modelling

where goals can be organised hierarchically with

positive and negative contributions from more spe-

ciﬁc (e.g. IT) goals w.r.t. higher level (strategic)

goals. More elaborated goal models are also pro-

posed in the ﬁeld of requirements engineering, e.g.

i* (Yu and Mylopoulos, 1997), KAOS (van Lam-

sweerde, 2009) or URN (International Telecommuni-

cation Union, 2012). Those can be used for dealing

with business process alignment. However generally

companies mostly focus on generic types of goals like

cost reduction, customer satisfaction, responsiveness

or speciﬁc risk management (e.g. governmental or ﬁ-

nancial regulations). As a result, BPM must still ad-

dress many challenges related to the management of

the misalignment between business and IT, the deriva-

tion of IT goals from business goals, the reengineer-

ing processes and the adaptation to rapidly evolving

business processes (Alotaibi and Liu, 2017).

The aim of this position paper is to propose some

improvement over the current state of practice. Start-

ing from the assumption that a BPMN model is avail-

able, we propose to drive the improvement by a goal-

oriented process. We explore two non exclusive ap-

proaches: a lightweight approach based on generic

goals that can be inferred implicitly and a more in-

depth approach based on the construction of an ex-

plicit goal model and enabling more powerful goal-

based redesign tactics. Those approaches are dis-

cussed based on a running example which is a logis-

tics system operating between UK and Europe.

This paper is structured as follows. Section 2

will remind some background on modelling with pro-

cesses (using BPMN as widely adopted method) and

goals (using KAOS as a representative variant). Sec-

tion 3 details the redesign approach based on an im-

plicit goal model while Section 4 explores the ap-

proach based on the construction of an explicit goal

model. Section 5 discusses our work in the light of

some related work. Finally, Section 6 concludes by

identifying our roadmap to further expand this work.

2 BACKGROUND

This section reminds about the structure of a BPMN

and of goal models by presenting their speciﬁc meta-

models and illustrating them on our case study which

is ﬁrst introduce in textual form.

2.1 Case Study in Logistics

We consider a use case from the logistic domain, de-

scribing the process of shipping goods from the UK to

continental Europe. In this process, a truck needs to

cross the Strait of Dover, usually using an Euro Tun-

nel shuttle but in case of too high delay the ferry can

be considered as an alternative.

In the shipment process, a transport plan is ﬁrst

prepared and is sent to the truck driver. The driver

then heads toward the check-in point at the Euro Tun-

nel. A monitoring can detect some delay and decide

to divert the truck route to take a ferry. Once arrived

at destination a local dispatch is organised.

2.2 Process Modelling

This paper will rely on the widely used BPMN no-

tation to model processes. BPMN is a speciﬁcation

(currently in version 2) for the high-level represen-

tation of business processes (OMG, 2011). It pro-

vides a notation that can easily be understood both

by business analysts and technical developers. Figure

2 shows a simpliﬁed view of the BPMN meta-model.

Figure 2: Simpliﬁed BPMN meta-model.

The main concepts to deﬁne the behaviour of a

business process are Flow objects. There are three

types of Flow objects: Events, Activities and Gate-

ways. They can be connected to each other with Se-

quence Flows, Message Flows or Associations. Those

elements can also be grouped inside Pools and Lanes.

Finally a more abstract view can be given by group-

ing inter-pool messages using Conversations inside a

MODELSWARD 2019 - 7th International Conference on Model-Driven Engineering and Software Development

528

dedicated diagram. Figure 3 illustrates a possible de-

livery process for our case study.

Figure 3: Ideal transport process.

2.3 Goal Modelling

Goal modelling was elaborated in the ﬁeld of require-

ments engineering with different method variants dis-

cussed in the introduction. In the scope of this pa-

per, we will use KAOS as support. The developed

approach can however be transposed to other variants

because all notations share many common features

around the concepts of goal, reﬁnement, agent and

responsibility for achieving the goal and operations/-

tasks that directly relate to the process dimension.

Figure 4: Goal meta-model (KAOS variant).

Although the goal part is central, a KAOS model is

actually structured on the following four sub-models

depicted in Figure 4.

• The goal model structures functional and non-

functional goals of the considered system. It also

helps identify potential conﬂicts and obstacles re-

lated to goals and reason about their resolution. It

is graphically represented as a goal tree.

• The object model captures all the concepts in-

volved in goal speciﬁcations. Its representation

is aligned with UML class diagrams and allows

structuring entities, relations, events and agents.

• The agent model identiﬁes the agents of both the

system and the environment as well as their inter-

faces and responsibilities. They can be shown as

part of goal trees or in more speciﬁc diagrams.

• The operations model describes how agents

functionally cooperate to ensure the fulﬁlment of

the requirements assigned to them and hence the

system goals. A simpliﬁed form of business pro-

cess model is proposed by default but more elab-

orated notations like BPMN can come into play.

In KAOS, different abstraction levels to ex-

press goals can range from high-level strategic

goals like “Achieve[Timely Dispatch of Orders from

UK to EU]” down to operational goals such as

“Achieve[Transport through Eurotunnel]” depicted as

blue parallelograms in Figure 5. High-level goals

can be progressively reﬁned into more concrete and

operational ones through relationships linking a par-

ent goal to several sub-goals, with different fulﬁl-

ment conditions using either ”AND-reﬁnement” (all

sub-goals need to be satisﬁed) or ”OR-reﬁnement” (a

single sub-goal is enough, i.e. possible alternatives

like Achieve[Transport through Ferry] as alternative

to Eurotunnel). The “WHY” and “HOW” questions

can be used to conveniently navigate to parent and

sub-goals, respectively. This results in a goal tree

structure. The goal decomposition stops when reach-

ing a goal controllable by an agent (i.e. a yellow

hexagon), i.e. answering the “WHO” question about

responsibility assignment. These goals are either re-

quirements on the software or expectations on agent

behaviours and are respectively depicted as blue and

yellow parallelograms with thick borders. Domain

properties or regulation can also be taken into account

to justify a reﬁnement, like the maximal speed on a

road or the minimal time to cross the Eurotunnel.

Figure 5: Ideal transport process (with KAOS syntax).

Towards Goal-oriented Analysis and Redesign of BPMN Models

529

3 IMPLICIT GOAL ANALYSIS

Although processes typically aim at achieving some

functional goal, standard BPMN models do not in-

clude explicit information about this rationale. The

situation is even worse for non-functional goal-

s/requirements (NFR). In this ﬁrst and deliberately

lightweight approach, we choose not to build an ex-

plicit goal model but try to guess existing goals, chal-

lenge about missing goals and perform redesign di-

rectly in the BPMN model. The meta-process is illus-

trated in Figure 6 and is currently fully manual.

Figure 6: Redesign approach using implicit goal model.

3.1 Eliciting Goals from BPMN

We identiﬁed a number of clues that may reﬂect

some design rationale through different means such

as analysing the intent behind speciﬁc constructs (e.g.

the use of parallel tasks, or timers), identifying some

BPMN patterns (e.g. feedback loop until a condition

is met) and more generally our experience in decoding

BPMN diagrams. Table 1 gives a (non-exhaustive) list

of such clues. Of course, explicit requirements may

also have been documented using notes or in-diagram

descriptions.

3.2 Challenging Goals

Once goals have been identiﬁed, they can be con-

ﬁrmed and challenged using the questions proposed in

the last columns of Table 1. More systematic check-

lists, like SQuaRE (ISO, 2011), can also be applied

to avoid missing important NFR. Business processes

generally focus only on a few of them like perfor-

mance, reliability while others are less important (e.g.

usability is only relevant for ”manual” tasks).

3.3 Improving Business Processes

The use of the above check-lists should trigger a de-

sign thinking about the purpose of a speciﬁc design

and either conﬁrm it or lead to some evolution. Such

reasoning even informal will typically uncover some

missing goals. At this point, modelling skills come

into play but the same table can also provide support

to guide enforcing those goals by using it in the re-

verse way.

Figure 7: Improved transport process for timing efﬁciency.

Considering our case, the conditional rule ”delay

at Eutotunnel” can be analysed as related to a goal

to avoid too much delay. However, in the proposed

design, this requirement is placed under the respon-

sibility of the driver and the company will only be

informed after the cross of the Strait of Dover. Figure

7 shows a more efﬁcient design where the company is

responsible of monitoring Eurotunnel delays and no-

tifying the truck in advance. This design also gives

more control to the company.

Table 1: Non-exhaustive list of BPMN rationale indicators.

BPMN Possibly underlying goal Challenging question

Single end state Achievement goal What is the state reached ?

Final error state Non-critical requirement Where/How is the error managed ?

Conditional Business rule Does this condition reﬂects some business property that should be main-

tained ? How is it maintained more widely ?

Parallel tasks/loops Scalability requirement What is the load ? How dynamic is it ? Are enough processing resources

available ?

Conditional loop

on activity

Reliability requirement Does the condition reﬂect some milestone to reach or some key property that

should be kept enforced ?

Transaction ACID property What are related atomicity, consistency, isolation and durability require-

ments ?

Timer event Time-critical requirement Is the deadline hard ? How is it related to other deadlines ? Why is the

activity interrupted or not (if border event)?

Escalation event Transfer of responsibility What is the normal operation condition ? Who takes care outside those

conditions ?

MODELSWARD 2019 - 7th International Conference on Model-Driven Engineering and Software Development

530

4 EXPLICIT GOAL ANALYSIS

An explicit goal-based analysis proceeds according to

the more complex meta-process described in Figure

8, currently fully manual. It is detailed in the rest of

the section and may or not rely on a preexisting goal

model, In the later case, the goal model is built.

Figure 8: Redesign approach using explicit goal model.

4.1 Build/Enrich Goal Model

The clues detailed in Table 1 remains applicable,

especially to identify non-functional goals. How-

ever they can be reﬁned in order to provide ﬁner

grained rules for the model-to-model translation be-

tween business process and goal models. Such map-

pings have already been studied and taken into con-

sideration to build the consolidated Table 2 which

gives our current progress on this task.

In our case study, the three requirements of Fig-

ure 5 are directly derived from the process activities

of Figure 3. The goal structure can also be derived,

e.g. the main milestone (AND reﬁnement) prepare-

transport-local dispatch as well as the transportation

alternative (OR-reﬁnement) which is actually not to-

tally coherent with the BPMN: this should be a case

based AND-reﬁnement as depicted in Figure 9.

4.2 Goal Analysis and Redesign

Goal analysis and redesign are considered to-

gether. They are performed using standard tech-

niques from goal-oriented requirements engineering

(GORE). Some useful techniques are:

• analysis techniques for identifying incomplete

goal reﬁnements that could result from the pre-

vious goal elicitation phase.

• different goal reﬁnement tactics and patterns to

produce correct reﬁnements.

• analysis techniques to identify correct agent as-

signment w.r.t. their monitor and control capabil-

ities to fulﬁl their responsibilities.

• obstacle analysis to make sure goals are not over-

idealistic with respect to adverse events. This can

also be identiﬁed by analysing process KPIs, i.e.

level of goal satisfaction.

• obstacle resolution techniques such as avoidance,

mitigation, goal deidealisation.

Those techniques are fully detailed in GORE liter-

ature with can be explored through (van Lamsweerde,

2009). Considering our case study, an example of

problem revealed by the BPMN model at the goal

level is that the shipment tracker is in charge of moni-

toring the status of the Eurotunnel. This design is not

very efﬁcient because monitoring is best performed

by a dedicated software agent such as a CEP (Com-

plex Event Processing) software agent. In the goal

Table 2: Model-to-model mapping between business process model (BPMN) and goal model (KAOS).

BPMN KAOS Comment Source

Process/Subprocess goal/sub-goal to be stated as achieve goal (de la Vara et al., 2013)

(Rebeca Alves, 2013)

Sequence AND milestone parent is enclosing business process (Horita et al., 2014)

XOR split AND case-based parent is enclosing business process (de la Vara et al., 2013)

(Horita et al., 2014)

Incoming ﬂow from

user/env.

Expectation Process expects some input otherwise it could

block (e.g. on message wait)

(Horita et al., 2014)

Loop with guard AND reﬁnement with until pattern in guarded sub-process (Horita et al., 2014)

Control ﬂow agent-driven reﬁnement inside the system (if across corridors)

between system and env. (if across pools)

authors’ contribution

Escalation case-based responsibility see the escalation condition authors’ contribution

Message/timer/

signal/condition

(as interrupt event)

OR or case-based AND check the condition, could also result from obsta-

cle resolution

authors’ contribution

Transaction/

compensation

Transaction pattern Complete ﬁnal state enforced or initial state

should be restored

authors’ contribution

Error/Cancellation

(as start event)

Obstacle resolution See obstacle management strategies (e.g. restore

state/mitigation)

authors’ contribution

Error/Cancellation

(as border event)

Obstacle resolution See obstacle management strategies (e.g. weak-

ening/mitigation)

authors’ contribution

Towards Goal-oriented Analysis and Redesign of BPMN Models

531

model of Figure 9, a new software agent is introduced

to detect Eurotunnel delays (but possibly other im-

pacting conditions) and inform the shipment tracker

who will can then focus on notifying and tracking the

trucks. Other strategic evolution could also be intro-

duced such as the need for an extra activity to prepare

border control due to the Brexit (see obstacle in red).

Figure 9: Ideal transport process (with KAOS syntax).

4.3 Process Level Redesign

The BPMN model should then be revised with this

goal perspective to reﬂect the changes in the goal

model. This is partly supported by the mapping given

in Table 2. More generally this step is following the

usual design ﬂow and does not pose much problems.

Figure 10: Revised transport process after goal analysis.

Note there is some room left for implementation

level decisions as long as the goal is enforced. For ex-

ample, the new requirement to produce a border form

can be enforced as a new activity either parallel or

sequential with the existing preparation of the trans-

portation plan. In our case, we selected the former as

it is more general. The ﬁnal revised process is shown

in Figure 10. The new lane at the bottom corresponds

to the new CEP agent which monitors possible de-

lays and arrival events. The shipment tracker is now

in charge of monitoring and reacting to such events

through an event-based gateway. The truck driver lane

is unchanged except the delay notiﬁcation is now gen-

erated by the CEP and send by the shipment tracker.

5 DISCUSSION AND RELATED

WORK

The problem of relating business processes and

goals has received quite some attention with sev-

eral proposed mappings (Koliadis et al., 2006), (Re-

beca Alves, 2013), (de la Vara et al., 2013), (Horita

et al., 2014). Our approaches build on top of them.

The GoalBPM methodology proposes a bi-

directional mapping and satisfaction veriﬁcation be-

tween operational BPMN and goal models both for i*

and KAOS in order to ensure their co-evolution (Ko-

liadis et al., 2006; Koliadis and Ghose, 2006). The

method also relies on clues to establish the required

traceability links but do not provide any heuristics as

we do. However, it introduces a consistency check us-

ing normal and exceptional trajectories which relates

to our notion of obstacle.

Considering more speciﬁcally the KAOS ap-

proach, the Goal-Oriented Business Process Mod-

elling Notation (GO-BPMN) is a language enhancing

standard BPMN with support for the explicit mod-

elling of goals, plans and their relationships (Green-

wood and Ghizzioli, 2009). A GO-BPMN model con-

sists of a set of goal hierarchies (similar to KAOS)

that must be achieved or maintained. Leaf goals (i.e.

requirements) are related to at least one plan describ-

ing the activities to be performed. Although it com-

bines goals and processes, GO-BPMN is however fo-

cusing more on autonomous run-time adaptation of

systems than on supporting a more general redesign

process for which it does not deﬁne useful tools.

A recent survey also reported that the most com-

monly used techniques are i* and Key Performance

Indicators (KPI) for strategic goals and Business Pro-

cess Model and Notation (BPMN) for business pro-

cesses (Carmo et al., 2017). KAOS, used here, is less

popular but offers a clear semantics that can be trans-

posed to those more popular notations. The problem

of dealing with NFR is also still open and our work

only devoted a limited attention to it.

A distinctive characteristic of our approach is the

ability to keep the goal analysis implicit in a ﬁrst at-

tempt to improve the processes and if necessary to

perform a deeper analysis and redesign based on an

MODELSWARD 2019 - 7th International Conference on Model-Driven Engineering and Software Development

532

explicit goal model. Some indicators triggering the

need to build a goal model are the discovery of undoc-

umented goals through the use of Table 1 or the use of

complex redesigns going beyond simple actions like

adding some activity of a transfer of responsibility.

Note Table 1 supports the analysis process and dis-

covery of goals while Table 2 is more a syntactic in-

strument to help in the building a goal model if partial

or not available.

6 CONCLUSION AND FUTURE

WORK

This work considered the problem of the poor atten-

tion to goals in business process models and more

speciﬁcally the widely used BPMN standard which

focuses essentially on the ”who/when/how” opera-

tional dimensions rather than on providing rationales

about the ”why/who” dimensions. Our proposal is

in line with previous work and is structured in two

approaches: a lightweight approach that does not try

to build an explicit goal model for improving BPMN

models and a more powerful one that relies on the

construction of such a model. For the implicit goal ap-

proach, we proposed support under the form of guide-

lines derived from goal analysis principles applied to

generic process constructs. For the explicit goal ap-

proach, we reﬁned existing mappings to build a goal

model in order to apply goal analysis techniques on

it. Our experiment on a small logistics model shows

its applicability and beneﬁts proportional to the con-

sidered approach.

Our work is still in progress as we are now evolv-

ing the guidelines for the implicit approach under the

form of a more consistent knowledge base. For the ex-

plicit approach, we are prototyping tool support base

on an EMF model-to-model transformation according

to the meta-models sketched in Section 2. We also

plan to conduct experiments with novice and more

experienced modellers to assess our current mappings

and to improve them.

ACKNOWLEDGEMENTS

This work was partly funded by the PRiMa-Q project

of the Walloon Region (grant nr. 1610019). Thanks

to our industrial partners.

REFERENCES

ABPMP (2011). Standards for Business Process Manage-

ment. https://www.abpmp.org.

Alotaibi, Y. and Liu, F. (2017). Survey of business process

management: challenges and solutions. Enterprise IS,

11(8).

Carmo, A. et al. (2017). An analysis of strategic goals and

non-functional requirements in business process man-

agement. In Proc. of the 19th Int. Conf. on Enterprise

Information Systems, ICEIS.

de la Vara, J. L. et al. (2013). On the use of goal models

and business process models for elicitation of system

requirements. In Enterprise, Business-Process and In-

formation Systems Modeling.

Greenwood, D. and Ghizzioli, R. (2009). Goal-oriented

autonomic business process modelling and execution.

Multiagent Systems, InTechOpen.

Harmon, P. (2016). Business process modeling survey. BP-

Trends Report.

Horita, H. et al. (2014). Transformation approach from kaos

goal models to bpmn models using reﬁnement pat-

terns. In Proc. of the 29th Annual ACM Symposium

on Applied Computing, New York, NY, USA. ACM.

International Telecommunication Union (2012). Recom-

mendation Z.151 (10/12), User Requirements Nota-

tion (URN) Language Def.

ISO (2011). System and Software Quality Requirements

and Evaluation (SQuaRE). https://iso25000.com.

Koliadis, G. et al. (2006). Combining i* and bpmn for busi-

ness process model lifecycle management. In Busi-

ness Process Management Workshops.

Koliadis, G. and Ghose, A. (2006). Relating Business Pro-

cess Models to Goal-Oriented Requirements Models

in KAOS. In Advances in Knowledge Acquisition and

Management, PKAW’06, Guilin, China, August 7-8.

Kueng, P. and Kawalek, P. (1997). Goal-based business pro-

cess models: creation and evaluation. Business pro-

cess management journal, 3(1):17–38.

OMG (2011). BPMN: Business Process Model And Nota-

tion V2.0. https://www.omg.org/spec/BPMN/2.0.

Rebeca Alves, Carla Silva, J. C. (2013). A bi-directional

integration between i* and bpmn models in the context

of business process management: A position paper. In

Proc. of Req.Eng.@Brazil, Rio de Janeiro, Brazil.

The Open Group (2009). TOGAF 9 - The Open Group Ar-

chitecture Framework Version 9.

The Open Group (2017). Archimate 3.0.1 speciﬁcation.

http://pubs.opengroup.org/architecture/archimate3-

doc.

van Lamsweerde, A. (2009). Requirements Engineering -

From System Goals to UML Models to Software Spec-

iﬁcations. Wiley.

Weske, M. (2012). Business Process Management: Con-

cepts, Languages, Architectures. Springer Berlin Hei-

delberg.

Yu, E. S. K. and Mylopoulos, J. (1997). Enterprise mod-

elling for business redesign: The i* framework. SIG-

GROUP Bull., 18(1):59–63.

Zachman, J. A. (2003). The Zachman Framework for Enter-

prise Architecture: Primer for Enterprise Engineering

and Manufacturing. Zachman International.

Towards Goal-oriented Analysis and Redesign of BPMN Models

533