TOWARDS REQUIREMENTS ELICITATION IN

SERVICE-ORIENTED BUSINESS NETWORKS USING VALUE

AND GOAL MODELLING

Rodrigo Mantovaneli Pessoa, Marten van Sinderen

University of Twente, 7500 AE Enschede, The Netherlands

Dick Quartel

Novay, 7500 AN Enschede, The Netherlands

Keywords: Requirements elicitation, Value modelling, Goal modelling, Coordination process modelling, Service-

oriented architecture.

Abstract: Due to the contemporary trends towards increased focus on core competences and outsourcing of non-core

activities, enterprises are forming strategic alliances and building business networks. This often requires

cross enterprise interoperability and integration of their information systems, leading to widespread

adoption of Service Oriented Architectures (SOA). In this paper we present an approach to guide the

development and evolution of service-oriented business networks. Our approach combines value models

and goal models, where the former are used to represent and analyse the economic sustainability of a

business network and the latter are used to represent and analyse the goals of the participants within the

business network. Systematic guidelines are proposed to derive a goal model from a value model. In

addition, a preliminary discussion is presented on how to refine goals and operationalize goals as services

rooted in a SOA. The approach is illustrated using an example of a business network in the electricity

sector.

1 INTRODUCTION

In order to improve their efficiency and better meet

customer needs, many enterprises organize

themselves as networked business constellations,

called business webs (Tapscott et al. 2000) or

business networks. Business networks are formed by

profit-and-loss responsible business units, or

independent companies, that have decided to

cooperate in producing and consuming goods and

services for achieving specific purposes. For this, the

participants in a business network should be able to

to sustain economic activity by exchanging items of

value against money, while operating according to

their respective business goals with proper focus on

core competencies. The operational fulfilment of

business networks usually requires cross-enterprise

interoperability and integration of information

systems (Mantovaneli Pessoa et al. 2008, Quartel et

al. 2008), which can be facilitated by the adoption of

Service-Oriented Architectures (SOA) (OASIS

2006).

The SOA paradigm endorses services as the

fundamental design concept for developing software

architectures and shifts developer focus from the

confines of an individual application towards an

open market of services hosted on arbitrary

computing platforms in a distributed environment.

SOA-compliant (web services) standards not only

allow the definition of information exchange (e.g.,

XML, WSDL, SOAP) but also of the coordination

and composition of services (e.g., BPEL). Thus, in

the SOA paradigm, services perform functions

implemented in software, exposed by well-defined

interfaces which provide the mechanism by which

services can communicate with one another in

compositions to perform higher level functionality.

Although the claimed benefits of SOA are manifold

(Papazoglou & Ribbers 2006), there is no evidence

that the mere adoption of SOA will automatically

lead to improved business networks or agility of the

392

Mantovaneli Pessoa R., van Sinderen M. and Quartel D. (2009).

TOWARDS REQUIREMENTS ELICITATION IN SERVICE-ORIENTED BUSINESS NETWORKS USING VALUE AND GOAL MODELLING.

In Proceedings of the 4th International Conference on Software and Data Technologies, pages 392-399

DOI: 10.5220/0002325703920399

 SciTePress

participants in such networks. An important

challenge, therefore, is to enable consideration of

business factors (Luthria & Rabhi 2009) and enforce

fulfilment of corresponding requirements when

developing technical SOA-based solutions.

In this paper, we propose an approach that

addresses complementary business concerns as a

foundation for designing service-oriented business

networks, i.e., business networks with technical

support rooted in SOA. These concerns are

economic sustainability, goal fulfilment, and process

coordination, which are respectively expressed and

analysed using value, goal and process models. Our

focus in this paper will be on the development of a

goal model based on a given value model.

The paper is further structured as follows.

Section 2 summarizes our overall approach. Section

3 presents some related work. Section 4 describes

our main contribution, namely initial guidelines for

the development of a goal model from a given value

model. This section uses a running example to

illustrate our approach. Section 5 briefly discusses

how to map goals onto services that can be

operationalized in a SOA. Finally, Section 6 presents

our conclusions and identifies further research.

2 OVERALL APPROACH

Business networks are complex systems, hence

creating models of such systems in order to

understand and define them normally requires a

multi-viewpoint approach in which different

concerns and interests are distinguished and

captured by separate models. An important

consequence of this 'divide and conquer' strategy is

that in any individual development project proper

attention should be given to the mutual consistency

of the various models (Pijpers & Gordijn 2008,

Dijkman et al. 2008), since they all refer to the same

phenomenon (i.e., a business network). In our

approach, we focus on goal, value and process

models (see Fig. 1).

Figure 1: Different perspectives of enterprise architectures

require different models.

A value model is used to represent that

something of economic value is exchanged; a goal

model focuses on describing intentional aspects of

business activities; and a process model typically

shows what these activities are and how they are

coordinated.

Our proposal is to initially design and analyse a

value model of the business network raised by the

various stakeholders. Once an economically feasible

business network is identified, we then take the

resulting value model as a starting point and

subsequently derive a model that considers the goals

of each participant within the business network.

These high-level goals are then refined into a set of

more specific sub-goals. We believe that the explicit

definition of these relations facilitates traceability

among goals and the (design) artefacts that

ultimately realize the goals. Typically these artefacts

are business and IT services, and the processes and

rules that support these services. Finally, service

orchestration models (e.g., BPEL processes) can be

derived from the refined goal model by identifying

and articulating the causal relations between the

participants' goals. These causal relations provide

our basis for the coordination of services that

accomplish these goals.

3 RELATED WORK

In (Gordijn et al. 2006), the combined use of goal

and value models is explored using two

requirements engineering techniques, namely i* (Yu

1997) and e

value (Gordijn & Akkermans 2001).

The main focus lies in showing how the

complementary use of both techniques can help in

creating, representing, and analyzing e-service

business models. E-service models are then used for

modelling interaction points of cooperating IT

systems, within and between enterprises. In (van der

Raadt et al. 2005), the authors propose a method for

transforming an i* goal model into an e

value value

model. First, the method involves modelling the

strategic business goals of the enterprises that want

to cooperate. It then focuses on formulating

alternatives for reaching those goals. Then, for each

proposed alternative, an e

value model is

constructed. These value models are then used to

evaluate whether those alternatives are economically

viable for each of the enterprises involved.

In (Pijpers & Gordijn 2007), an approach is

introduced to arrive at a business process model of a

business network that is consistent with an economic

value model of the same business network. The

TOWARDS REQUIREMENTS ELICITATION IN SERVICE-ORIENTED BUSINESS NETWORKS USING VALUE

AND GOAL MODELLING

393

authors propose a step-wise approach that first

considers the independent transfer of the ownership

right of a value object and the actual object itself,

and then considers time ordering of these transfers.

The consistency between models is achieved by

applying a set of informal guidelines describing how

to move in a structured way from a value model to a

process model.

In (Zlatev & Wombacher 2005), a methodology

is proposed for determining the consistency of a

process model and a value model, where both

models are assumed to represent the same business

network but were created independently from each

other. In order to determine consistency, a

preparation step is carried out in which the given

models are 'reduced' such that they only use

constructs present in both models. Since the reduced

models describe only the common concepts and

relations, they can be compared for consistency. The

major disadvantage of this approach is that, under

certain conditions, it is still possible that the original

value model and process model are mutually

consistent, while the reduced models show

otherwise.

The authors of (Decreus & Poels 2009) present

an approach to generate business process models

from enriched goal models. They extend existing i*

goal models with semantic annotations in order to

describe dynamic constraints among goals and tasks.

Then, they propose detailed mappings to translate

the semantically enriched goal models into business

process models.

In (Koliadis & Ghose 2006, Koliadis et al. 2006), a

methodology is proposed for relating business

process models to high-level stakeholder goals. They

use BPMN to represent business models and KAOS

and i* to express goals. The relationship between

processes and goals is evaluated with informal

techniques, however with consideration of dynamic

environments in which changes to goals and

processes constantly emerge.

4 FROM VALUES TO GOALS

4.1 Example

We will use a simple running example to illustrate

our approach. The example refers to a business

network in the Dutch electricity sector, as reported

in (Pijpers & Gordijn 2008).

In the electricity business network, suppliers

provide electricity to consumers, and the consumers

pay for this electricity. The Suppliers acquire

electricity from a set of producers. In this context,

consumers, suppliers and producers define different

market segments taken into consideration and used

to represent a set of actors. For instance, a specific

actor may use technical expertise to become the low-

cost electricity producer within his company's

market segment, while other actors may choose a

production strategy that emphasizes flexibility,

consumer choice, and quality.

In order to be eligible for electricity provision, a

consumer must first obtain power distribution

capabilities from a distributor. In practice, a physical

infrastructure (consisting of cables and transformers)

is needed to transport the electricity, and the

consumer also has to pay for this. Instead of

collecting money directly from the consumers, the

distributor sells these “debts” to the supplier, which,

in turn, charges a corresponding fee from the

consumers. It is assumed that related participants in

this network have pair-wise contracts which are

valid for a year. A contract is yearly renewed, unless

one of the participants indicates that it does not want

to continue the relationship. The new contract may

state new conditions on the relationship, such as

changed tariffs for the electricity.

4.2 Value Modelling

In short, our proposal is to initially design (and

evaluate) a value model, e.g. using the e

value

language. The result of this design step for our

example is illustrated in Fig. 2.

Figure 2: e3value model of Dutch Electricity Sector

(adapted from (Pijpers & Gordijn 2008)).

It is important to realize that value exchanges

represented in the value model do not necessarily

coincide with physical exchanges. For example, the

model explicitly represents that the distributor

ACT4SOC-EHST 2009 - 4th International Conference on Software and Data Technologies

394

provides the electricity distribution service to the

consumer in exchange of some agreed sum of

money. Indeed, this is correct from the value

perspective. But a naive interpretation of the model

that the customer directly pays the distributor is

wrong. As already announced in the introduction of

the example, the actual money flow is via the

supplier.

4.3 An Intermediate Step

Since a value transfer in an e

value model implicitly

involves the transfer of both the value object itself

and its respective ownership right, it is not possible

to directly derive from an e

value model the actual

physical flow of value objects. To this end, we

followed the approach described in (Pijpers &

Gordijn 2007) to derive an e

value (physical) model

from the e

value model, such that the e

value

(physical) model will represent the physical transfer

of the value objects rather than the value transfer. In

brief, this approach incorporates the physical flow of

a value object by distinguishing between the transfer

of the ownership right of an object and the transfer

of the value object itself (transfer of physical

possession). The obtained e

value (physical) model

is shown in Fig. 3.

Figure 3: e3value (physical) Model of Dutch Electricity

Sector (adapted from (Pijpers & Gordijn 2008)).

4.4 Goal Modelling

In previous work, we have presented a language for

modelling requirements in enterprise architectures –

namely ARMOR (Quartel et al. 2009), which is

aligned with the ArchiMate language (Jonkers et al.

2007) and supports the modelling of goals and

requirements during the early and late requirements

engineering phases. In this paper, we use the

ARMOR language for representing and analysing

goal models. ARMOR was inspired by the Business

Motivation Model (OMG 2007), the i* framework

(Yu 1997) and KAOS (van Lamsweerde 2008).

Table 1 shows the notation for the main abstract

language elements.

Table 1: ARMOR notation.

Abstract element Concrete notation

Stakeholder

Hard goal

Soft goal

Requirement

Realisation

AND realisation

OR realisation

Contribute relation

Conflict relation

A goal is defined as some desired result that is to

be realized in the problem domain. Here a desired

result represents some desired situation, state or

value, such as a satisfied customer, increase of sales,

a completed purchase, the calculation of some

exchange rate, the delivery of some goods, etc.

Eventually, this result has to be realized through

cooperation of the participants in a business

network. A distinction can be made between hard

and soft goals. This distinction concerns the criteria

for assessing the satisfaction of a goal. In case of a

hard goal, these criteria are clear and precise. In case

of a soft goal, these criteria are typically vague or

subject to interpretation. A requirement is a goal that

can be assigned to some system (-to-be), such that

the system is made responsible for the satisfaction of

the goal. A goal can be refined into one or more sub-

goals, where the following types of refinement are

distinguished:

− AND-realization (conjunction): defining one or

more sub-goals that must be satisfied all to satisfy

the goal;

− OR-realization (disjunction): defining one or

more alternative sub-goals of which at least one

must be satisfied to satisfy the goal;

− a combination: typically in disjunctive normal

form.

A goal G1 may conflict with the satisfaction of

another goal G2, where G1 and G2 can only be a

hard goal. In addition, a goal G1 may contribute to

+/-

TOWARDS REQUIREMENTS ELICITATION IN SERVICE-ORIENTED BUSINESS NETWORKS USING VALUE

AND GOAL MODELLING

395

the satisfaction of another goal G2, where G1 and

G2 can both be either a hard or a soft goal.

Properties of the contribute relation are:

− type: the type of contribution, i.e., positive or

negative;

− strength: the strength of the contribution, e.g.,

weak or strong.

4.5 Goal Elicitation and Refinement

A goal model is derived from a given value model

by applying the following guidelines (assuming

value and ARMOR employed languages):

1) Identification of Stakeholders and their Primary

Goals. For each actor and for each market segment

present in the value model, we derive a stakeholder

in the goal model. Subsequently, for each economic

activity and for each value exchange performed by

each actor, we derive a primary goal and associate it

with its stakeholder. Fig. 4 illustrates this step with

our example for the actor/stakeholder ‘producer’,

where the economic activity ‘generate electricity’

raises a goal with the same name. In addition, the

value exchange between producer and supplier

raises another goal that promotes the ‘exchange of

electricity for money’. Since this value exchange

matches a pattern that reflects a selling activity (i.e.,

the exchange of goods for money between

stakeholders), we then rename its respective goal to

‘sell electricity’. Other common patterns include:

advertising, reservation, insourcing, rating,

registration, screening, and resource renting. For a

more detailed description of value patterns, we refer

to (Zlatev 2007).

Producer

Sell

electricity

Generate

electricity

Figure 4: (Step1) Identification of stakeholders and their

respective primary goals.

2) Refinement of Primary Goals. Next, we extend

the goal model by refining the primary goals. For

this, for each goal derived from a value exchange,

we derive sub-goals by analyzing how each value

transfer, which constitutes the same value exchange,

are physically operated according to the

value(physical) model (shown in Fig. 3). This step

is illustrated in Fig. 5. The value transfer between

producer and supplier raises the goal that promotes

the transfer of money from one stakeholder

(supplier) to another (producer). Since this value

transfer matches a pattern that reflects a charging

activity, we then rename its respective goal to

‘charge supplyer’. An analogous derivation is

carried out for the transfer of electricity between

producer and distributor. This transfer raises the goal

‘deliver electricity to distributor’.

Producer

Sell

electricity

Gen erate

electricity

Charge

supplier

Deliver electricity

to distributor

Figure 5: (Step2) Refinement of primary goals into sub-

goals.

3) Manual Refinement of Sub-goals. Finally, we

extend the goal model by manually refining the

goals obtained from steps 1 and 2 into more concrete

and specific sub-goals. This is essentially a creative

process which requires domain-specific knowledge

since the appropriate information can not be directly

derived from the given models. However, Fig. 6

illustrates a possible result of this step for our

example.

Producer

Sell

electricity

Generate

electricity

Charge

supplier

Deliver electricity

to distributor

Send an

invoice

Au to m a t i c

bank debit

Use existing

infrastructure

Figure 6: (Step3) Manual refinement of sub-goals.

Fig. 7 shows the obtained diagrams for the

remaining stakeholders, namely supplier and

distributor, after steps 1 and 2.

ACT4SOC-EHST 2009 - 4th International Conference on Software and Data Technologies

396

Supplier

Sell

Electricity

Buy

electricity

Buy

Debts

Charge

consumer

Deliver electricity

to consumer

Distributor

Offer dis tribution

service

Sell debts

Charge

supplier

Provide distribution

to consumer

Figure 7: The supplier's and distributor's goals, after steps 1 and 2.

5 FROM GOALS TO PROCESSES

TO SERVICES

Since goals are intended to be achieved by (intra-

and inter-) business processes, during late

requirements elicitation, functional goals should be

mapped onto activities of these processes.

Non-functional requirements, specified as soft

goals, are then refined into measurable indicators.

Our objective is to finally operationalize goals as IT-

level services which can be rooted in a SOA.

We are still in the first phase of investigating the

possibilities for doing this. The following are

preliminary ideas, which should be further studied

and converted into concrete guidelines:

− Goals can be associated with activities, where the

purpose of each activity is to achieve a result that

is supportive of, or even fully operationalize the

associated goal. Goal refinement may be driven

by the objective to directly relate goals to existing

IT services. For example, when goals can be

formulated in the proper formalism, they may be

used as input to goal-based service discovery

approaches (Bonino da Silva Santos et al. 2008).

− The goal model can be analyzed for dependencies

and relationships between identified goals, in

order to find clues on how the associated

activities (or services) must be related, such as the

time ordering in which activities must take place

and the value dependency of one activity on

another. For example, if the goal model states that

a goal G1 can only be satisfied if G2 and G3 are

satisfied, this means that the activities associated

with G2 and G3 both have to be executed for the

fulfilment of G1, and that the activity associated

with G1 (if not already fulfilled by G2 and G3)

can only be completed after completion of the

activities associated with G2 and G3. The precise

implications of goal relationships (conjunction,

disjunction, contribute, conflict) for activity

relationships need to be further investigated.

− Sets of activities related in this way form abstract

business processes. These processes represent

behaviour that participants in a business network

wish to expose. Therefore they can be interpreted

as (part of) an abstract service choreography.

Corresponding service orchestrations or missing

parts of the service choreography can be created

using patterns such as proposed in (Khalaf et al.

2006), or designed and validated using service

design frameworks such as (Quartel et al. 2007).

− If for identified abstract services no

corresponding existing services can be discovered

using (semantic) service discovery approaches,

they have to be designed and implemented. This

means that manual effort is needed to create

WSDL descriptions and to implement the WSDL

interfaces and service processes. Similarly, for

compositions of services executable processes

have to be developed, such as BPEL processes.

6 CONCLUSIONS

With the advent of business networks, the alignment

between business and information technology gets a

new dimension. In such networks, there is not a

single point of authority for making decisions about

IT support to solve conflicts in requirements that the

participants in these networks may have (Wieringa

et al. 2005).

In our approach, a requirement defines a goal

that can be assigned to some system (-to-be), such

that the system is made responsible for the

satisfaction of the goal. In this sense, a requirement

should model desired characteristics of products,

processes and services under development. The main

reason for using goal modelling is that the rationale

for designing and changing a system is to be found

outside the system itself (Loucopoulos 1994). By

explicitly modelling and representing enterprise

goals, goal-oriented modelling languages help in

TOWARDS REQUIREMENTS ELICITATION IN SERVICE-ORIENTED BUSINESS NETWORKS USING VALUE

AND GOAL MODELLING

397

analysing, changing, and communicating

requirements to stakeholders.

By outlining guidelines for deriving intentional

goal models from economic value models, we want

to facilitate the use of both models during

requirements engineering and design of service-

oriented business networks, in order to help

stakeholders in considering ways to compose

supplier services into bundles that are valuable from

a consumer perspective and profitable for all

concerned (Wieringa et al. 2005). We believe that

value models and goal models are relevant tools that

should be explored in this context. The paper offers

initial guidelines for deriving a model that considers

the goals of each participant within a business

network. In this work, we used e

value for value

models ARMOR for goal models.

Our work differs in several aspects from existing

work. The difference is mainly that of scope and

focus. In contrast with (Zlatev & Wombacher 2005),

our approach introduces goal modelling as an

intermediate perspective to arrive at a business

process model of a business network. In contrast

with (van der Raadt et al. 2005), in the goal analysis,

we move the focus from more general strategic goals

of organizations to more specific goals of reciprocal

cooperation efforts within business networks. These

goals and their refinements into architectural

requirements form the basis of our approach.

As future work we intend to identify further

guidelines, investigate the formalization of the

approach, the resolution of conflicts between goals,

the late requirements phase, and the automation of

steps 1 and 2 (of the goal elicitation and refinement

phase). In order to validate our approach, we want to

consider further scenarios and use cases where goal

interdependencies and value exchanges require

strategic thinking and conflict resolution. To be

economically and operationally viable for business

use, our approach would benefit from additional

analysis techniques (e.g. risk and value analysis).

ACKNOWLEDGEMENTS

This work is part of the Freeband A-MUSE project

(http://a-muse .freeband.nl), which is supported by

the Dutch government under contract BSIK 03025.

REFERENCES

Bonino da Silva Santos, L.O., Ferreira Pires, L., van

Sinderen, M.J., 2008. A goal-based framework for

dynamic service discovery and composition. In

ACT4SOC 2008, 2nd International Workshop on

Architectures, Concepts and Technologies for Service

Oriented Computing. INSTICC Press, pp. 67-78.

Decreus, K., Poels, G., 2009. Mapping semantically

enriched Formal Tropos to business process models.

In SAC 2009, 24th Annual ACM Symposium on

Applied Computing. ACM, pp. 371-376.

Dijkman, R.M., Quartel, D.A.C., van Sinderen, M.J.,

2008. Consistency in multi-viewpoint design of

enterprise information systems. Information and

Software Technology, 50 (7-8): 737-752.

Gordijn J., Akkermans H., 2001. E3-value: design and

evaluation of e-business models. IEEE Intelligent

Systems, 16(4):11-17.

Gordijn, J., Yu, E., van der Raadt, B. 2006.. E-service

design using i* and e3value modeling. IEEE Software,

23(3): 26-33.

Jonkers, H. et al., 2007. Concepts for architectural

description, Technical Report TI/RS/2003/007,

Enschede: Telematica Instituut.

Khalaf, R., Keller, A., Leymann, F., 2006. Business

processes for web services: principles and

applications. IBM Systems Journal, 45(2): 425-446.

Koliadis, G., Ghose, A., 2006. Relating business process

models to goal-oriented requirements models in

KAOS. In PLAW 2006, Pacific Rim Knowledge

Acquisition Workshop. LNCS 4303, Springer, pp. 25-

39.

Koliadis, G. et al., 2006. Combining i* and BPMN for

business process model lifecycle management. In

BPM 2006 Workshops, Business Process Management

Workshops. LNCS 4103, Springer, pp. 416-427.

Loucopoulos, P. (1994) The F3 (from fuzzy to formal)

view of requirements engineering. Journal of

Ingenierie des Systemes d'Information, 2(6): 639-655.

Luthria, H., Rabhi, F., 2009. Service oriented computing

in practice - an agenda for research into the factors

influencing the organizational adoption of service

oriented architectures. Journal of Theoretical and

Applied Electronic Commerce Research, 4(1): 39-56.

Mantovaneli Pessoa, R., Quartel, D.A.C., van Sinderen,

M.J., 2008. A comparison of data and process

mediation approaches. In I-WEST 2008, 2nd

Workshop on Enterprise Systems and Technology.

INSTICC Press, pp. 48-63.

OASIS, 2006. Reference Model for Service Oriented

Architecture 1.0. URL http://www.oasisopen.org

/committees/download.php/19361/soa-rm-cs.pdf.

OMG, 2007. Business Motivation Model (BMM)

Specification. Object Management Group. URL

http://www.omg.org/

Papazoglou, M. Ribbers, P., 2006. e-Business:

organizational and technical foundations. John

Wiley& Sons Inc.

Pijpers, V., Gordijn, J., 2007. Bridging business value

models and process models in aviation value webs via

possession rights. In HICCS 2007, 40th Annual

Hawaii international Conference on System Sciences.

IEEE Computer Society.

ACT4SOC-EHST 2009 - 4th International Conference on Software and Data Technologies

398

Pijpers, V., Gordijn, J., 2008. Consistency checking

between value models and process models: a best-of-

breed approach. In BUSITAL 2008, 3rd International

Workshop on Business/IT Alignment and

Interoperability. CEUR-WS.org , pp. 58-72.

Quartel, D.A.C., Steen, M.W.A., Pokraev, S.V., van

Sinderen, M.J., 2007. COSMO: a conceptual

framework for service modelling and refinement.

Information Systems Frontiers, 9 (2-3): 225-244.

Quartel, D.A.C., Pokraev, S.V., Mantovaneli Pessoa, R.,

van Sinderen, M.J., 2008. Model-driven development

of a mediation service. In EDOC 2008, 12th

International IEEE Enterprise Distributed Object

Computing Conference. IEEE Computer Society, pp.

117-126.

Quartel, D., Jonkers, H., Engelsman, W., 2009. A

requirements modelling language for enterprise

architecture: ARMOR for requirements modelling.

Enschede: Telematica Instituut.

Tapscott, D., Ticoll, D., Lowy, A., 2000. Digital capital:

harnessing the power of business webs. Ubiquity,

1(13): 3.

van der Raadt, B., Gordijn, J., Yu, E., 2005. Exploring

web services from a business value perspective. In RE

2005, 13th IEEE International Conference on

Requirements Engineering. IEEE Computer Society,

pp. 53-62.

van Lamsweerde, A., 2008. Requirements engineering:

from craft to discipline. In FSE 2008, 16th ACM

Sigsoft Intl. Symposium on the Foundations of

Software Engineering. ACM, pp. 238-249.

Wieringa, R.J., Gordijn, J., van Eck, P.A.T., 2005. Value-

based business-IT alignment in networked

constellations of enterprises. In REBNITA 2005, 1st

International Workshop on Requirements Engineering

for Business Need and IT Alignment. Univ. of New

South Wales Press, pp. 38-43.

Yu, E., 1997. Towards modelling and reasoning support

for early-phase requirements engineering. In ISRE '97,

3rd IEEE Int. Symp. on Requirements Engineering.

IEEE Computer Society, pp. 226-235.

Zlatev, Z., Wombacher, A., 2005. Consistency between e

value models and activity diagrams in a multi-

perspective development method. In CoopIS 2005,

CoopIS, DOA, and ODBASE: OTM Confederated

International Conferences, On the Move to

Meaningful Internet Systems. LNCS 3760, Springer,

pp. 520-538.

Zlatev, Z.V., 2007. Goal-oriented design of value and

process models from patterns. PhD thesis, CTIT

Ph.D.-thesis series No.07-102, Enschede: University

of Twente.

TOWARDS REQUIREMENTS ELICITATION IN SERVICE-ORIENTED BUSINESS NETWORKS USING VALUE

AND GOAL MODELLING

399