Business Process and Motivation of Objectives in One Model

Ella Roubtsova

Open University of the Netherlands, Valkenburgerweg 177, 6419AT Heerlen, The Netherlands

Ella.Roubtsova@ou.nl

Keywords:

Business Process, Business Objectives, Protocol Model, Motivation Model.

Abstract:

The Object Management Group predicts that the Business Process Modelling Notation will be eventually

merged with the Business Motivation Model to be implemented in integrated tool suites. However, con-

ventional modelling semantics have asynchronous semantics and therefore have difﬁculties to accommodate

motivation of objectives speciﬁed on the basis of synchronous semantics. This paper shows how Protocol

Modelling semantics can be used both for business process modelling and motivation modelling correspond-

ing to objectives. Protocol Modelling uses synchronous composition and this synchronization gives to Protocol

Modelling the expressive means needed to accommodate motivation of objectives and business processes in

one model.

1 INTRODUCTION

Goals, objectivesand motives are very important parts

of system speciﬁcation. Goals are usually formu-

lated as non-functional requirements. They are ab-

stract. The goals can be even unrealizable. The ob-

jectives corresponding to goals are speciﬁc and mea-

surable. They show realisability of goals. Presenta-

tion of goals, objectives and motives in business pro-

cess speciﬁcation can be seen as transformation of

goals into the corresponding objectives and motives

expressed as elements of business processes. Such

a transformation is a way to estimate realisability of

goals.

The need of combining goals and business pro-

cess modelling standards is emphasized by the Object

Management Group and the Business Rules Group.

They predict that ”eventually speciﬁcations such as

the Business Process Modelling Notation (BPMN) to-

gether with the Business Motivation Model (BMM)

should be merged into a single business-oriented

modelling architecture, and implemented in inte-

grated tool suites” (OMG, 2010; BRG, 2010).

In this paper we relate the BMM with business

processes and show how business modelers can bene-

ﬁt from modelling of motivation of objectives.

The structure of the paper is the following.

Section 2 presents elements of the Business Moti-

vation Model (BMM).

Section 3 formulates semantic problems of com-

bining goals and business processes in one model

identiﬁed in related work.

Section 4 formally presents the semantic basis for

motivation modelling.

Section 5 shows how the Protocol Modelling se-

mantics can accommodate motivation of objectives

and business process in one model.

Section 6 describes applications of motivation

models as future work and concludes the paper.

2 BUSINESS MOTIVATION

MODEL

The BMM provides a structure for developing, com-

municating, and managing business plans. The struc-

ture covers four related elements:

• The Ends of a business plan.

“Among the Ends are things the enterprise wishes

to achieve, for example, Goals and Objec-

tives” (BRG, 2010).

• The Means of a business plan.

“Among the Means are things the enterprise will

employ to achieve the Ends, for example, Strate-

gies, Tactics, Business Policies, and Business

Rules”.

• “ The Inﬂuences that shape elements of a business

plan”.

Roubtsova E.

Business Process and Motivation of Objectives in One Model.

DOI: 10.5220/0004460800240032

In Proceedings of the Second International Symposium on Business Modeling and Software Design (BMSD 2012), pages 24-32

ISBN: 978-989-8565-26-6

• “The Assessments that are made about the im-

pacts of such Inﬂuencers on Ends and Means

i.e., Strengths, Weaknesses, Opportunities, and

Threats.”

The OMG predicts that “three types of people are ex-

pected to beneﬁt from the BMM: developers of busi-

ness plans, business modellers, and implementers of

software tools and repositories”.

The BMM is not a full business model and it

does not prescribe in detail business processes, work-

ﬂows and business vocabulary. However, business

processes are key elements of business plans and the

BMM does include a placeholder for Business Pro-

cesses. The relations between Goals and other ele-

ments of BMM are left open.

3 GOAL MODELLING

Goal modelling has its roots in the well known re-

quirements engineering approach KAOS (Knowledge

Acquisition in autOmated Speciﬁcation) (Dardenne

et al., 1993). Goals are speciﬁed in Linear Temporal

Logic and organized using the AND and OR reﬁne-

ment structures.

Van at al (Van et al., 2004) proposed goal-oriented

requirements animation. The modelling formalism is

the UML State Machines that are generated from the

goal speciﬁcations and called Goal State Machines

(GSMs). A GSM contains only transitions that are

justiﬁed by goals. The GSMs receive events through

event broadcast. A GSM that can’t accept an event

in its current state keeps it in a queue. These events

will be submitted to GSMs internally. This means

that the composition of GSMs contains extra states

that cannot be composed from the states of separate

GSMs. Therefore the GSMs cannot be seen as purely

goal models as they also deal with the events from the

queues.

The User Requirements Notation (URN) (ITU,

2008) is a standard that recommends languages for

software development in telecommunication. The

URN consists of the Goal-Oriented Requirements

Language (GRL), based on i* modelling frame-

work (Yu, 1995), and Use Case Maps (UCM) (Al-

sumait et al., 2003), a scenario modelling notation.

The GRL provides a notation for modelling goals and

rationales, and strategic relationships among social

actors (Yu et al., 2001). It is used to explore and iden-

tify system requirements, including especially non-

functional requirements. The UCM is a convenient

notation to represent use cases. The use cases are se-

lected paths in the system behaviour and they can be

related to goals by developers. The goals are used

to prioritize some use cases. If a use case presents

alternative behaviours or cycles, then the goals pri-

oritize alternatives. The use cases can be simulated.

However, use cases do not model data and the state of

the system and they present only selected traces. This

means that behaviour model as well as the motivation

model shown by use cases are incomplete and can-

not guarantee the achievement of goals in the whole

system.

Letier at al. (Letier et al., 2008) derive event-based

transition systems from goal-oriented requirements

models. Then the operations are derived from goals

as triples of domain pre-conditions, trigger-conditions

and post-conditions for each state transition. The

declarative goal statements are transformed into the

operational model. To produce consistent operational

models, a required trigger-condition on an operation

must imply the conjunction of its required precondi-

tions. The problems of goal-oriented approaches are

mostly caused by different semantics used by process

modelling and goal modelling techniques. Letier at

al (Letier et al., 2008) explained that the operational

speciﬁcation and the KAOS goal models use different

formalisms. KAOS uses synchronous temporal logics

that are interpreted over sequences of states observed

at a ﬁxed time rate. The operational models use asyn-

chronous temporal logics that are interpreted over se-

quences of states observed after each occurrence of an

event. Temporal logic operators have very different

meanings in synchronous and asynchronous temporal

logics. Most operational formalisms have the asyn-

chronous semantics. Letier at al. (Letier et al., 2008)

admit that in order to be semantically equivalent to the

synchronous KAOS models, the derived event-based

models need to refer explicitly to timing events or in-

clude elements of synchronization.

4 SEMANTICS FOR

MOTIVATION MODELING

The need of synchronization is not the only one se-

mantic need to direct business processes to objectives.

Let us identify the necessary semantics in a state tran-

sition system.

We take a state transition system which is usually

presented as a triple of

P = (S,A,T),where

• S is a ﬁnite set of states {s

,....s

,...s

...},

• A is the alphabet of P, a ﬁnite set of environmental

actions ranged over {a,b,...},

• T is a ﬁnite set of transitions (s

,a, s

Business Process and Motivation of Objectives in One Model

The semantics of a transition contains two rela-

tions (Milner, 1980):

1. C ⊆ (A × S) is a binary relation, where (a, s) ∈ C

means that action a is a possible action for P when

in state s. C is called the can-model of P because

it models the actions that P “can do” in each state.

2. U is a total mapping C → S that deﬁnes for each

member of C the new state that P adopts as a re-

sult of the action. U(a;s

) = s

means that if P

engages in action a when in state s

it will then

adopt state s

. U is called the update-model of P

because it models the update to the state of P that

results from engagement in an action.

With separation of the can- and update-models a

process P is a tuple:

P = (S;A;C;U).

There are always states in the process where par-

ticular goals are achieved. Let us name them the goal-

states. From the goal perspective, the actions, leading

to a goal-state, are the priority actions or wanted ac-

tions in the states preceding the goal-state. So, a state

preceding a goal-state and the action that is on the

path may lead to the goal-state, form a new binary

relation:

• W ⊂ (A × S), (a;s) ∈ W means that action a is

a wanted action for P when in state s. We call

relation W the want-model to show its semantic

difference from the relation C.

In order to model motivation we propose to add

the want-model W to the process:

P = (S;A;C;U;W).

The can- and want-models of a process are inde-

pendent of each other, so when a process is in a given

state, an action can have different combinations of

can- and want- alternatives:

{can happen; can not happen}× {wanted;not wanted}

Usually W ⊆ C and W is included into the process

model. However, the new goals emerging in the life

cycle of the modeled system may challenge the pro-

cess and may need actions that do not belong to the

alphabet A.

In this paper we base the modeling of motivation

on this extra relation W added to the process.

A service may have several (n) goals. In this case

several want-models should be taken into account

P = (S;A;C;U;W

,...,W

The goals can be OR-composed or AND-

composed (Pohl and Rupp, 2011).

In real systems, some goals can be conﬂicting. For

instance, information goals may conﬂict with security

and privacy goals. Wishes of different user roles may

also conﬂict. Two goals are conﬂicting if the system

has a state from which it is impossible to reach a state

where both goals are satisﬁed simultaneously. It is

important to identify any conﬂicting goals and cor-

responding motivation models as soon as possible in

the software life cycle. One of the ways to do this is

modelling of motivation corresponding to objectives

in process models.

5 PROTOCOL MODELS WITH

MOTIVATION MODELS

A Protocol Model is a synchronous CSP parallel com-

position of protocol machines (McNeile and Simons,

2006). This composition has its roots in the alge-

bra Communicating Sequential Processes (CSP) pro-

posed by Hoare (Hoare, 1985). McNeile (McNeile

and Simons, 2006) extended this composition for ma-

chines with data.

Protocol Modelling semantics accumulates can-

and want- semantics needed for accommodation of

objectives in business processes.

We will demonstrate the use of Protocol Mod-

elling for business process and motivation modelling

on a simple case study.

An Insert Credit Card Number web service can

be seen in many electronic booking systems. The

behaviour of the service is the following. The user

of the service instantiates the service. The user is

asked to insert his credit card number and read the

privacy conditions of the service. The user may in-

sert the credit card number without reading the pri-

vacy conditions and after reading and accepting the

privacy conditions. When the user has accepted the

privacy conditions, he can rethink and read the state-

ment again. The service can be cancelled before in-

serting the credit card number.

We recognize two goals for this service (Figure 1),

namely,

• to get the credit card number inserted and

• to get the privacy conditions read by the user.

The possibility of service cancelation is yet another

concern. It is obvious that cancelation cannot be

called a goal of the service.

5.1 Business Process

After the identiﬁcation of the goals the KAOS ap-

proach suggests to identify objects, agents, entities

and operations.

Second International Symposium on Business Modeling and Software Design

Insert Credit Card Number

Credit Card Number inserted Privacy Statement read

Service can be canceled

from any Intemediate state

AND

Figure 1: Goal Model.

Using Protocol Modelling we also identify enti-

ties, objects, agents and yet aspects but all of them

are presented as protocol machines.

For example, we model the can-update process of

the Insert Credit Card Number web service as a CSP

composition of protocol machines

Input

Decision

and

Cancelation

. These protocol machines corre-

spond to formulated goals and the cancelation re-

quirement. Figure 2 shows the graphical presentation

of our model. The executable Modelscope metacode

is shown in Figure 2. The metacode is the complete

artefact. As we show later the graphical form does

not contain all the modelling constructs of protocol

models.

It is not always the case that one requirement is

mapped onto one protocol machine. However, the

compositional protocol machines allows for any ways

of decomposition.

The protocol machine

Input

describes behaviour

of an

OBJECT

of type

Input

. Each object has its iden-

tiﬁcation name.

The protocol machines

Decision

and

Cancelation

specify

BEHAVIOURS

. They do not

have own identiﬁcation name and included into each

instance of object

Input

. The Include relations are

shown between protocol machines depicted as arcs

with half-dashed ends.

A human interacts with the service (and with a

protocol model) by submitting events. Each protocol

machine has an alphabet of recognized events. The

events recognized by protocol machines are speciﬁed

as types. Each type is a data structure. Each in-

stance of an event type contains own values of speci-

ﬁed types.

For example, each instance of event

Insert

contains own identiﬁer

Input:Input

and

Credit

Card Number: Integer

(Figure 2). All three ma-

chines are synchronously instantiated accepting event

Instantiate

. Generic

Finalize

is an alias of events

Insert

and

Cancel

The generic interface generated from the model by

the Modelscope tool shows to the user the state and

the possible events at any execution step. The advan-

tage of using Protocol Machine with goal models is

that we result in an executable model of identiﬁed ob-

jects, agents and entities and can test achievement of

chosen goals. We are able to identify the goal states.

Not all scenarios of system behaviour lead to the goal

states. Protocol machines present all life cycle sce-

narios of objects, agens and entities. The execution

of the protocol models allows for testing realizability

of goals and completing the incomplete or imprecise

requirements.

Similar to a state machine, a protocol machine has

a set of states and the local storage presented with at-

tributes. However, the semantics of a protocol ma-

chine is different.

• A transition label of a state machine presents the

pre-condition and the post-condition for enabling

event to run to completion. A transition from state

to state s

is labeled by

, [precondition]event/ [postcondition], s

) (OMG,

2003).

The label shows that the transition in a state takes

place only if the pre-condition is satisﬁed. If the

pre-condition is not satisﬁed, the behaviour is de-

ﬁned by the semantic rules. Namely, the event is

kept in a queue and waits for a state change to ﬁre

the transition.

• A transition label of a protocol machine presents

an event that causes this transition. The storage

information is localized in the state. Being in a

quiescent state in which the protocol machine can

accept the submitted event, the protocol machine

accepts one event at a time and handles it until an-

other quiescent state. If the protocol machine can-

not accept the event in its current state, the event

is refused (McNeile and Simons, 2006; McNeile

and Roubtsova, 2009).

The default type of protocol machines is

ESSENTIAL

. Essential protocol machines are com-

posed (synchronized) using the CSP parallel compo-

sition and these machines are used to present the can-

update-model, the business process.

The CSP parallel composition means that a Pro-

tocol Model accepts an event if all the protocol ma-

chines recognizing this event accept it. Otherwise the

Business Process and Motivation of Objectives in One Model

Insert Credit Card Number

Credit Card Number inserted Privacy Statement read

Service can be canceled

from any Intemediate state

AND

inserted

Input

not

accepted

instantiated

Insert

Instantiate

Decision

final

Finalize

Rethink

Instantiate

cancelled

Cancelation

not

cancelled

Cancel

Instantiate

Finilize= {Insert, Accept}

Include

1 MODEL InsertCreditCardNumber

2 OBJECT Input

3 NAME Session

4 INCLUDES Decision, Cancelation

5 ATTRIBUTES Session: String, Card Number: Integer

6 STATES instantiated,inserted

7 TRANSITIONS @new*Instantiate=instantiated,

8 instantiated*Insert=inserted

10 BEHAVIOUR Decision

11 STATES instantiated ,not accepted, accepted, final

12 TRANSITIONS @new*Instantiate=not accepted,

13 not accepted*Accept=accepted,

14 accepted*Rethink=not accepted,

15 accepted*Finalize=final,

16 not accepted*Finalize=final

17 BEHAVIOUR Cancelation

18 STATES not cancelled, cancelled

19 TRANSITIONS @new*Instantiate=not cancelled,

20 not cancelled*Cancel=cancelled,

22 EVENT Instantiate

23 ATTRIBUTES Input:Input, Session:String,

24 EVENT Insert

25 ATTRIBUTES Input: Input, Credit Card Number: Integer,

26 EVENT Accept

27 ATTRIBUTES Input:Input,

28 EVENT Rethink

29 ATTRIBUTES Input:Input,

30 EVENT Cancel

31 ATTRIBUTES Input:Input,

32 GENERIC Finalize

33 MATCHES Insert, Cancel

Figure 2: Goal Model and Can-Update Protocol Model.

Second International Symposium on Business Modeling and Software Design

Insert Credit Card Number

Credit Card Number inserted

Privacy Statement read

Service can be canceled

from any Intemediate state

AND

inserted

Input

not

accepted

instantiated

Insert

Instantiate

Decision

final

Finalize

Rethink

Instantiate

cancelled

Cancelation

not

cancelled

Cancel

Instantiate

Finilize= {Insert, Accept}

Include

Motivate

Insert

Motivate Insert

Insert

Motivate

Motivate Accept

Figure 3: Goals, Protocols and Motivation.

event is refused.

A protocol model accepts one event at a time and

do not accepts any other event until it achieves the

quitrent state. The results of this semantics are two

important distinct properties:

• the state of a protocol model at any moment is a

composition of state of protocol machines;

• the behaviour of any protocol machine is pre-

served in the whole protocol model and it is pos-

sible to reason locally on protocol machines about

behaviour of the whole model.

5.2 Semantic Elements of Protocol

Modelling for Motivation Modelling

There are some other semantic properties of Protocol

Modelling for modelling of objectives and separation

them from the can-update-model.

1. Ability of protocol machines to read but not

modify the state of other protocol machines and to

have an associated state function. This property

makes it possible to build protocol machines with de-

rived states. A derived state is a state that is calculated

from the states of other machines using the state func-

tion associated with the protocol machine.

2. Different types of protocol machines are used

to changes the use of CSP composition. The proto-

col machines of type

ESSENTIAL

are composed (syn-

chronized) using the CSP parallel composition tech-

nique and these machines are used to present the can-

update-model of the business process. The protocol

machines of type

DESIRED

are not composed using

the CSP parallel composition technique. These ma-

chines can be used to model the wanted behaviour or

motivation.

5.3 BMM Elements in Protocol Models

The elements of the BMM can be mapped onto pro-

tocol Models.

Ends or objectives are achieved in particular goal

states.

Means or Strategies of the Business Motivation

Model are events and sequences of events. Events or

sequences leading to some chosen goal states form the

corresponding motivation model.

Inﬂuences are presented as Protocol Machines in-

cluded into the model. The inﬂuences add extra be-

haviour or constraints.

If an

Influence

is in the model, this means that

this

Influence

assessed

as important.

5.4 Motivation Model

In this section we add motivation models to the can-

update protocol model in order to give to the user of

the model the indication of means leading to objec-

tives.

A want-model cannot forbid any transition in the

can-update-model and it does not participate in the

event synchronization with the can-update-models.

Therefore, the want-models are not composed using

Business Process and Motivation of Objectives in One Model

35 BEHAVIOUR !Motivate Insert

36 TYPE DESIRED

37 STATES motivate insert, other

38 TRANSITIONS motivate insert*Insert=@any

40 BEHAVIOUR !Motivate Accept

41 TYPE DESIRED

42 STATES motivate accept, other

43 TRANSITIONS motivate accept*Accept=@any

1 package InsertCreditCardNumber;

3 import com.metamaxim.modelscope.callbacks.*;

6 public class MotivateInsert extends Behaviour {

8 public String getState() {

11 String y=this.getState("Input");

12 String x=this.getState("Decision");

13 if (y.equals("instantiated")

14 || x.equals("accepted")

15 ) return "motivate insert";

16 else return "other";

17 }

19 }

1 package InsertCreditCardNumber;

3 import com.metamaxim.modelscope.callbacks.*;

6 public class MotivateAccept extends Behaviour {

8 public String getState() {

10 String x=this.getState("Decision");

11 if (x.equals("not accepted")

12 ) return "motivate accept";

13 else return "other";

14 }

17 }

Figure 4: Motivation Model.

the CSP parallel composition and have type

DESIRED

The motivation models are depicted in Figure 3.

• Protocol machine

Motivate Insert

models mo-

tivation for the goal ”to get the credit card number

inserted”.

• Protocol machine

Motivate Accept

models mo-

tivation for the goal ” to get the privacy conditions

Second International Symposium on Business Modeling and Software Design

read by the user”.

Each of those protocol machines has a derived

state and an arc labeled with an event. The arc leads

to any state allowed by the can-update-model. This

structure is presented in the metamodel. Behaviours

presented by lines 35− 43 in Figure 4) contain tran-

sitions described the arcs as transitions with the ﬁnal

state

@any

Each behaviour is labeled with an exclamation

mark. The exclamation mark shows to the Mod-

elscope tool that there is a call-back java ﬁle with

the name of the marked behaviour. Each call-back

function (lines 1−20,1− 18 in Figure 4) derives state

of the motivation model from the state of the objects

and behaviours of the can-update-model. For example

the state

Motivate Insert

is derived if

Input

is in

state

instantiated

or if the

Decision

is in the state

accepted

(lines 11-15 in class

MotivateInsert

5.5 Motivation Model for Composition

of Goals

If the goals are OR-composed then achieving any

of the goals is the goal and both call-back functions

shown in Figure 4 are valid.

Motivation model of the AND-combination of

goals should not direct to states where at least one

of goals cannot be achieved. In our case, mo-

tivation of event

Insert

when the object

Input

is in the state

instantiated

leads to the state

where the goal

to get the privacy condition

accepted

will never be achieved. Event

Insert

should not be motivated in state

instantiated

and

lines 11 and 13 should be deleted from the call-back

function in Figure 4. The motivation models will ﬁrst

motivate event

and then the event

Insert

The execution steps of the protocol model with the

AND combination of motivation models are shown in

Figure 5. The green light is given to the motivated

events.

6 DISCUSSION AND FUTURE

WORK

This paper has shown the expressive means of Proto-

col Modelling allowing combination of business pro-

cesses and motivation of objectives in one model. It

is the synchronous composition semantics of Proto-

col Modelling and the ability to derive states makes

the combination possible.

Figure 5: Execution of the Protocol Model with Motivation

Models.

There are several ways to use motivation models

built into protocol models:

•

Generating user interface elements.

Motivation models can be used to generate the

elements of the user interface. The wanted event

and elements of user interface corresponding to

them can be made of different form, color and use

another order. In the generic interface of the the

Modelscope tool (McNeile and Simons, 2011),

the wanted events are presented in green.

•

Reuse of models.

The motivation models open

another ways of reuse of business process models

for systems with different goals.

•

Analysis of consistency and adequate

completeness of requirements.

Motivation

of goals in models stimulates analysis of realiz-

ability of goals and identiﬁcation of contradicted

goals and requirements. The psychological stud-

Business Process and Motivation of Objectives in One Model

ies show that people tend to think contextually.

Execution of requirements presented in protocol

machines is better understood by users than the

result of the formal methods applied on operation

models. Execution of requirements provides

better chance for recognizing of inconstant or

incomplete requirements.

•

Composition of business processes

on the basis of matching motivation

model.

Such an approach promises creating

effective business processes. This is especially

importance in the context of the electronic busi-

ness where the motivation provided by human

is gone and the motivation should be built in to

services as an element of service intelligence.

In the future work we plan the projects aimed to in-

vestigate analysis of consistency and adequate com-

pleteness of requirements and composition of busi-

ness processes on the basis of motivation models.

REFERENCES

Alsumait, A., Seffah, A., and Radhakrishnan, T.

(2003). Use Case Maps: A Visual Nota-

tion for Scenario-Based Requirements. 10th

International Conference on Human - Com-

puter Interaction, http://wwwswt.informatik.uni-

rostock.de/deutsch/Veranstaltungen/HCI2003/.

BRG (2010). The Business Motivation Model. Business

Governance in a Volatile World.

Dardenne, A., van Lamsweerde, A., and Fickas, S. (1993).

Goal-directed requirements acquisition. Sci. Comput.

Program., 20(1-2):3–50.

Hoare, C. (1985). Communicating Sequential Processes.

Prentice-Hall International.

ITU (2008). Formal description techniques (FDT).

User Requirements Notation Recommendation Z.151

(11/08). http://www.itu.int/rec/T-REC-Z.151-200811-

I/en.

Letier, E., Kramer, J., Magee, J., and Uchitel, S. (2008).

Deriving event-based transition systems from goal-

oriented requirements models . Automated Software

Engineering archiveD, 15(2):1–22.

McNeile, A. and Roubtsova, E. (2009). Composition Se-

mantics for Executable and Evolvable Behavioural

Modeling in MDA. BM-MDA’09, pages 1–8.

McNeile, A. and Simons, N. (2006). Protocol Modelling.

A Modelling Approach that Supports Reusable Be-

havioural Abstractions. Software and System Model-

ing, 5(1):91–107.

McNeile, A. and Simons, N. (2011).

http://www.metamaxim.com/.

Milner, R. (1980). A Calculus of Communicating Systems.

volume 92 of Lecture Notes in Computer Science.

Springer.

OMG (2003). Uniﬁed Modeling Language: Superstructure

version 2.1.1 formal/2007-02-03.

OMG (2010). Business Motivation Model. Version

1.1.formal/2010-05-01.

Pohl, K. and Rupp, C. (2011). Requirements Engineering

Fundamentals. Rocky Nook.

Van, H. T., van Lamsweerde, A., and Philippe Massonet,

C. P. (2004). Goal-oriented requirements animation.

In RE, pages 218–228.

Yu, E. (1995). Modelling Strategic Relationships for Pro-

cess Reengineering. Ph.D. Thesis. Dept. of Computer

Science, University of Toronto.

Yu, E., Liu, L., and Li, Y. (2001). Modelling Strategic

Actor Relationships to Support Intellectual Property

Management. LNCS 2224 Spring Verlag. 20th Inter-

national Conference on Conceptual Modeling Yoko-

hama, Japan, pages 164–178.

Second International Symposium on Business Modeling and Software Design