REGULATION, THE INVISIBLE PART OF THE GOAL

ORIENTED REQUIREMENTS ENGINEERING ICEBERG

Gil Regev

1,2

and Alain Wegmann

Ecole Polytechnique Fédérale de Lausanne (EPFL), School of Computer and Communication Sciences

CH-1015 Lausanne, Switzerland

Itecor, Av. Paul Cérésole 24, cp 568, CH-1800 Vevey 1, Switzerland

{gil.regev, alain.wegmann}@epfl.ch, g.regev@itecor.com

Keywords: Goals, Requirements, Regulation, Survival, Systems, Norms, Beliefs.

Abstract: Goal-Oriented Requirements Engineering (GORE) is considered to be one of the main achievements that

the requirements of the Requirements Engineering field has produced since its inception. Several GORE

methods were designed in the last twenty years in both research and industry. Curiously, GORE methods

seem to have emerged out of nowhere in the early 1990s, the concept of Goal appearing as a natural element

in explaining human and organizational behaviour. We have found no theoretical or philosophical work that

explicitly link GORE to an underlying organizational model. In this paper, we show that most GORE

methods are implicitly based on the goal-seeking, decision making organizational model. We argue that

there are other organizational models that may better explain human behaviour, albeit at the expense of

more complex models. We present one such alternative model that explains individual and organizational

survival through continuous regulation. We give our point of view of the changes needed in GORE methods

to support this alternative view through the use of maintenance goals and beliefs.

1 INTRODUCTION

In the 25 years or so since the advent of

requirements engineering (RE) research as an

academic discipline, its flagship methods have been

the Goal-Oriented Requirements Engineering

(GORE). The GORE methods have been lauded as

one of the main achievement of the RE community,

especially in its first 15 years of existence (van

Lamsweerde, 2001), (Mylopoulos, Kolp and Castro,

2006). GORE is still a very active field of research

with dedicated workshops and conference tracks

(e.g. the i* International workshop series,

International Workshop on Requirements, Intentions

and Goals in Conceptual Modeling).

In RE practice, GORE methods developed in

research have had less influence but they are

matched by goal-oriented methods that were created

by RE practitioners, e.g. Goal-Oriented Use Cases

(Cockburn, 2001), Essential Use Cases (Constantine,

1995). In this paper we designate all these methods

as GORE, whether they have emerged from research

or from practice.

The emergence of GORE methods has coincided

with a less software centric view of requirements.

RE has evolved out of software specification

methods by capturing more and more of the

environment of the envisioned software system

(Nuseibeh and Easterbrook, 2000), i.e. the

composite system (van Lamsweerde, 2001). The

GORE movement has been based on the

understanding that goals justify and explain

requirements that are assigned to agents in the

composite system (software system and its

environment), and that they help detecting and

resolving conflicts among different stakeholder

viewpoints (Dardenne, van Lamsweerde and Fickas,

1993). In GORE methods and subsequently in RE, it

has been assumed that the behaviour of the

stakeholders in the environment of the software

system is predominantly goal-oriented, see for

example (Loucopoulos and Kavakli, 1995),

(Nuseibeh and Easterbrook, 2000).

There has been little debate concerning the

epistemological roots of GORE methods (for an

exception, see our own work (Regev and Wegmann,

2005)). Very few RE researchers have challenged

this assumption. The few papers that have discussed

problems with GORE methods have sought to

supplement them with more artefacts, such as

Regev G. and Wegmann A.

REGULATION, THE INVISIBLE PART OF THE GOAL ORIENTED REQUIREMENTS ENGINEERING ICEBERG.

DOI: 10.5220/0004458400420050

In Proceedings of the First International Symposium on Business Modeling and Software Design (BMSD 2011), pages 42-50

ISBN: 978-989-8425-68-3

subject matters (Zave and Jackson, 1997) and

scenarios (Rolland, Souveyet and Ben Achour,

1998).

For Nuseibeh and Easterbrook (Nuseibeh and

Easterbrook, 2000) there are several types of RE

depending on the end product that is envisioned.

They give the following examples: RE for

information systems, RE for embedded control

systems and RE for generic services e.g. networking

and operating systems. In this classification our

discussion applies mostly to RE for information

systems. In this type of RE, the composite system is

the organization that the envisioned computer-based

system serves. Nuseibeh and Easterbrook further

state that the context of most RE and software

activities is in this field of information systems

development. Hence our discussion is applicable to

many RE projects. We hope that readers interested

in other types of RE will benefit from this discussion

as well.

We take Gause and Weinberg’s view that RE is

about discovering what is desired (Gause and

Weinberg, 1989). In this paper, we show that what

people desire has more to do with the way they

regulate their affairs than with the goals they seem to

pursue. We base our proposal mostly on Vickers

concept of Appreciative System (Vickers, 1968),

(Vickers, 1987), (Regev, Hayard and Wegmann,

2011) and show that goals are only the visible part

of the way individuals and organizations regulate

their relationships in order to survive. We also show

that GORE methods have most of the necessary

constructs to model this behaviour, e.g. maintenance

goals and beliefs. We advocate a more systematic

use of and widespread use of these concepts for

better understanding regulation.

We begin by reviewing the GORE research

(Section 2). We then introduce the regulation

organizational model and show that it can be used as

the underlying mechanism of which goal-oriented

behaviour is but the visible part (Section 3). We

identify some of the shortcomings of GORE

methods and propose remedies based on the

regulation-oriented view (Section 4). We review

some related work in Section 5.

2 AN OVERVIEW OF GORE

METHODS

GORE methods use the concept of Goal as the main

construct for defining requirements. The first papers

linking goals and requirements date to the beginning

of the RE discipline, e.g. (Dubois, 1989), (Robinson,

1989), (Dardenne, Fickas and van Lamsweerde,

1991). The link with the concept of goal seems to

have emerged naturally from research into software

specification e.g. (Robinson, 1989) that relied on

Artificial Intelligence (AI) artefacts, e.g. (Nilsson,

1971). Hence, most GORE methods use a

vocabulary inherited from Artificial Intelligence,

e.g. goals, agents, roles, objectives, constraints, and

obstacles.

Many GORE methods have been defined over

the years. The most prominent are: KAOS, GBRAM

(Anton, 1996), i* (Yu, 1997), GRL (ITU-T, 2008),

TROPOS (Mylopoulos, Kolp and Castro, 2001),

ESPRIT CREWS (Rolland et al., 1998), and Goal-

oriented Use Case (Cockburn, 2001).

Numerous goal types have been defined in these

methods. Following is a very partial list of goal

types: Achievement, maintenance, softgoal,

feedback, satisfaction, etc.

Very quickly goals have become a central

concept in RE. Zave and Jackson, for example, offer

the following definition, “Requirements Engineering

is about the satisfaction of goals” (Zave and Jackson,

1997). The call for papers of the Requirements

Engineering conference series also strongly links

requirements and goals, e.g. Requirements

Engineering Conference 2004 (RE04):

Requirements Engineering (RE) is the branch

of systems engineering concerned with the

goals, desired properties and constraints of

complex systems, ranging from embedded

software systems and software-based

products to large enterprise and socio-

technical systems that involve software

systems, organisations and people.

The focus on goals is understandable, not only

because of the AI roots of GORE methods, but also

because it relates with the goal-seeking

organizational model prevalent in the neighbouring

discipline of Information System (Checkland and

Holwell, 1998). Many GORE methods take for

granted this goal-seeking model. Modelling the

organization, through Enterprise modelling, for

example, is assumed to include goals, e.g.

(Loucopoulos and Kavakli, 1995): “Enterprise

modelling is about describing, in some formal way,

a social system with its agents, work roles, goals,

responsibilities and the like.” (Nuseibeh and

Easterbrook, 2000): “Enterprise modelling and

analysis deals with understanding an organisation’s

structure; the business rules that affect its operation;

the goals, tasks and responsibilities of its constituent

members; and the data that it needs, generates and

manipulates.”

REGULATION, THE INVISIBLE PART OF THE GOAL ORIENTED REQUIREMENTS ENGINEERING ICEBERG

It is thus assumed that high-level enterprise goals

can be gradually refined into requirements that can

be assigned to the envisioned system (Dardenne et

al., 1993), (Nuseibeh and Easterbrook, 2000). This

refinement is most often done with the help of

and/or goal trees inherited from (Nilsson, 1971).

Several RE researchers have reported problems

with this assumption, e.g. (Anton, 1996), (Zave and

Jackson, 1997), (Rolland et al., 1998), stating that

goal discovery and goal refinement are not

straightforward tasks, that enterprise goals are not

necessarily a good starting point for goal refinement

and that goal abstraction may lead to unrealistic or

unwanted alternatives. The proposed remedies were

to bound goal abstraction and refinement with the

subject matter of the organization (Zave and

Jackson, 1997), to use interview transcripts and

organizational documents for goal discovery (Anton,

1996) and to use scenarios and goals reasoning

together so that they inform one another (Rolland et

al., 1998).

There have been surprisingly few attempts to

link GORE to other organizational viewpoints, the

only exception known to us is our own previous

work (Regev and Wegmann, 2005). This is

surprising because in their suggested roadmap for

RE, Nuseibeh and Easterbrook (2000) suggest that,

“RE is a multi-disciplinary, human-centred process.”

They further state that (Nuseibeh and Easterbrook,

2000),

RE needs to be sensitive to how people

perceive and understand the world around

them, how they interact, and how the

sociology of the workplace affects their

actions. RE draws on the cognitive and social

sciences to provide both theoretical

grounding and practical techniques for

eliciting and modelling requirements

Nuseibeh and Easterbrook (2000) list the following

disciplines as part of RE: Cognitive psychology,

anthropology, sociology and linguistics. They

proceed to prescribe that (Nuseibeh and Easterbrook,

2000):

There is an important philosophical element

in RE. RE is concerned with interpreting and

understanding stakeholder terminology,

concepts, viewpoints and goals. Hence, RE

must concern itself with an understanding of

beliefs of stakeholders (epistemology), the

question of what is observable in the world

(phenomenology), and the question of what

can be agreed on as objectively true

(ontology). Such issues become important

whenever one wishes to talk about validating

requirements, especially where stakeholders

may have divergent goals and incompatible

belief systems.

While prescribing the need to incorporate different

epistemological, phenomenological and ontological

systems, Nuseibeh and Easterbrook perpetuate the

already prevalent organizational model in RE,

namely goal achievement by repeating the main

assumption of GORE methods about goal

achievement.

By focusing on goal achievement, GORE

methods have set aside all these aspects of

epistemology and phenomenology and have applied

a unique ontology supposed to be universal. In the

recent years, KAOS and more so i* have become the

main GORE methods with dozens of research papers

devoted to them. Most of these are papers that use

these methods in specific areas or that propose

extensions to them. i* has been incorporated into the

URN ITU-T standard (ITU-T, 2008) with seemingly

hardly a questioning of its assumptions. Recently, a

well received study of the i* graphical notation was

published (Moody, Heymans and Matulevičius,

2009), noting that major improvement is needed in

order to make i* user friendly. The study however

remained at the graphical level and did not

investigate the epistemological or ontological

aspects of i*.

Sutcliffe and Maiden (1993) proposed a notable

kind of goal in a paper that seems to have received

little attention by GORE researchers. They proposed

6 classes of goals. One of the classes is called

“feedback goals.” They describe these goals as

maintaining a desired state with a related tolerance

range, spawning corrective actions when the state is

considered to be outside the tolerance range

(Sutcliffe and Maiden, 1993). Curiously, this class

of goals has not been picked up by subsequent

GORE research. We have ourselves added feedback

into GORE research about 10 years later (Regev and

Wegmann, 2004), (Regev and Wegmann, 2005)

without noticing the significance of Sutcliffe and

Maiden’s feedback goal class at the time.

In the following section we propose an

epistemological view for GORE methods that may

help to alleviate some of their shortcomings. This

view is an extension of our previous work (Regev

and Wegmann, 2005). To clarify our discussion, we

use Zave and Jackson’s example of the development

of a turnstile for a zoo (Zave and Jackson, 1997) as a

running example. We reproduce their problem

description here verbatim for the clarity of the

discussion (Zave and Jackson 1997):

BMSD 2011 - First International Symposium on Business Modeling and Software Design

Requirements engineering is about the

satisfaction of goals [..]. But goals by

themselves do not make a good starting point

for requirements engineering. To see why,

consider a project to develop a computer-

controlled turnstile guarding the entrance to a

zoo [..].

If the engineers are told that the goal of the

system is to deny entrance to people who

have not paid the admission charge, they may

decide that the goal has been stated too

narrowly. Is not the real goal to ensure the

profitability of the zoo? Should they consider

other ways of improving profits, such as

cutting costs? What if there is more money to

be made by closing the zoo and selling the

land? And what is the goal of profit? If the

goal of profit is the happiness of the zoo

owner, would religion or devotion to family

be more effective? Obviously there is

something wrong here. Almost every goal is

a subgoal with some higher purpose. Both

engineering and religion are concerned with

goal satisfaction; what distinguishes them is

their subject matter.

The engineers should be told, in addition to

the goal, that the subject matter is the zoo

entrance. This information should take the

form of designations of phenomena

observable at the zoo entrance, such as

visitors, coins, and the action of entering the

zoo. These designations circumscribe the

area in which alternative goal satisfaction

strategies can be considered, at the same time

that they provide the basis for formal

representation of requirements.

3 SURVIVAL AND REGULATION

AS THE SOURCE OF GOALS

As we have seen, GORE methods seek to define the

highest-level goals that are adequate for defining

requirements for an envisioned system. Despite their

important advancement, this is one aspect that the

mainstream GORE methods (e.g. i*, KAOS) have

not defined yet. So-called high-level goals are often

described as strategic goals in GORE papers (see

High-level goals entry in the previous section). It is

therefore important to understand what is a strategic

goal. If we define the strategic level as being geared

toward the survival of the organization we have to

define what survival means: We have shown

elsewhere, e.g. (Regev and Wegmann, 2005),

(Regev and Wegmann, 2009), that survival can be

understood in terms of the maintenance of relatively

stable states, often called norms, that an observer

can use to identify an organization. The zoo, for

example, maintains a large set of norms for its

animals, employees, visitors, owners, animal rights

activists etc. For the animals, it maintains a stable

place in which to live, get fed and cared for, and

maybe reproduce. For the visitors the zoo maintains

a stable place where they can view animals while

being certain that they are well cared for. The

location of the zoo, its name, its layout, the animals

it houses are all aspects that change very little over

time. It is quite probable that the zoo you visited as a

child still exists and you can visit it with your

children or grandchildren. It is also quite probable

that most of the animals and employees who were at

the zoo when you were a child are no longer there.

But the zoo is still there. Hence the zoo maintains its

identity despite changes in all of its components

(e.g. employees, suppliers, management, animals,

visitors).

Maintaining norms is a powerful motivator for

action. The zoo’s management might want to

maintain its image as a modern facility and therefore

maintain the fit with the state of the art in visitor

management and feel that it’s entrance system is not

up to date and needs to be replaced. It may believe

that manual entrance control is not efficient enough

and that by cutting costs on entrance control, it could

use the money thus saved to better maintain its

animals’ health.

To maintain its norms relatively stable doesn’t

mean that the norms don’t change at all.

Organizations that survive over the long run make

changes to their norms but in a very controlled way.

This means that changes must be controlled for the

organization to maintain its identity for its

stakeholders. Consider what may happen if the zoo

changed its location or name twice a year or more

often. Would it be still recognized by its visitor?

Would its employees continue to work there? What

if it changed its mission from a zoo to a theme park,

to a museum etc.? But of course the zoo also

changes its norms, it may add new kinds of animals,

playgrounds, activities, partnerships with other

likeminded organizations. By saying that its norms

should not change too much, we are actually placing

bounds on how much change is acceptable.

Remember the tolerance range defined by Sutcliffe

and Maiden for feedback goals (1993).

What enables an organization to maintain and

change its norms are the relationships it has with

REGULATION, THE INVISIBLE PART OF THE GOAL ORIENTED REQUIREMENTS ENGINEERING ICEBERG

individuals and organizations, both inside and

outside the organization. This is a consequence of

the open system model of organizations (Regev and

Wegmann, 2005), (Regev and Wegmann, 2009).

These relationships must themselves be maintained

within very specific bounds (norms) for the

organization to be able to leverage them for

maintaining other norms. Thus, the zoo needs a

continuous flow of visitors to maintain its funding

and it places very strict bounds on what the visitors

can and cannot do. For starters, visitors must in most

cases pay their admission. They may pay a bit less if

they are part of specific classes of people (seniors,

children group members). Some visitors may not

pay at all if the zoo has a real reason to want them to

visit the zoo (e.g. VIPs, teachers accompanying a

school class, very young children). Hence, there is a

tolerance range for the admission price but it is not a

wildly changing aspect. There are other bounds on

what visitors are allowed to do in the zoo so that

their presence will be beneficial for the zoo and not

detrimental, e.g. it is probably forbidden to feed the

animals outside of very controlled food dispensed by

the zoo to specific animals, it is forbidden to

mistreat animals etc. Visitors who do not conform to

these bounds may be denied further admission to the

zoo, despite the zoo’s willingness to have as many

visitors as possible. Applying different price

schemes and denying entrance are likely to be

translated into goals for the turnstile. Understanding

the norms and where they come from helps analysts

to understand the goals expressed by the

stakeholders and discover non-expressed goals as

well.

The study of the way norms are maintained

stable is called regulation (or control). A feedback

regulator (or controller), e.g. a thermostat, an

automatic pilot, maintains a given state stable, e.g.

temperature, course, by sensing the current state

comparing it with the given state, and applying some

action if the difference is above the tolerance level.

Vickers (Vickers, 1968), (Vickers, 1987) proposed

the concept of the appreciative system, by extending

this model of a feedback regulation to human and

organizational regulation. Vickers’s appreciative

system has three components (Vickers, 1968),

(Vickers, 1987), (Regev, Wegmann and Hayard,

2011): Reality judgments, Value judgments and

Action judgments. With reality judgments, some

aspect of reality is singled out to be the study of

attention. In value judgments, this reality judgment

is matched to a category within which it is then

compared to the norm (what ought to be). In Action

judgment, some action might be taken to bring the

reality judgment closer to the norm. The three

judgments function as a complete system so that

change to one of them requires change to the others.

Hence, the way we view and judge the world affect

our actions and our actions affect our view and

judgments (Vickers, 1968), (Vickers, 1987).

As we have seen before, the value judgment is

done with some tolerance around the norm. In a

simple automaton the information to be sensed, the

norm and tolerances to be compared with and the

kind of actions to be taken are all given by its

designer. In an appreciative system, they are all

subject to continuous change; nothing is set once

and for all by a designer. Hence, an appreciative

system creates its own dynamics, which an

automaton does not.

Whereas the appreciative system creates its own

judgments, it is nevertheless a rather stable

construct, i.e. it creates its own norms. Vickers calls

these norms readiness. Hence an organization has a

readiness (a tendency) to see things in certain ways,

to value them in certain ways and to act in certain

ways. All these are rather stable in time. It is often

the role of the analyst to try and shake these

readinesses.

Linking the appreciative system and GORE

aspects, we can see that maintenance goals can be an

approximation of norms, beliefs can be an

approximation of reality and value judgments, and

achievement goals can be an approximation of

action judgments.

From this point of view, GORE methods have

concentrated on the third stage, action judgments

(achievement goals), and neglected the other two,

norms (maintenance goals), and reality and value

judgments (beliefs). This is easily understandable if

we consider that actions judgments are much more

visible than reality and value judgments.

Because the three judgments of the appreciative

system are interlocked, goals cannot be changed

without changing the beliefs that justify them.

4 IMPROVING GORE METHODS

Based on the regulation view we proposed in the

previous section, we identified a number of

shortcomings common to most GORE methods. We

explain them and provide pointers for addressing

them.

Maintenance is Higher-level than Achievement.

Although many types of goals have been defined in

GORE methods, the most popular goal type has been

BMSD 2011 - First International Symposium on Business Modeling and Software Design

and remains the achievement goals; a goal that is to

be achieved once and for all. The next most popular

goal type is the softgoal. Both KAOS and GBRAM

have introduced the concept of maintenance goal, a

goal that “is satisfied as long as its target condition

remains true” (Anton and Potts, 1998). Maintenance

goals have not received much attention and remains

largely unused. This is particularly unfortunate

because maintenance goals have been identified as

“high-level goals with which achievement goals

should comply” (Anton and Potts, 1998).

As we have shown, the concept of maintenance

goal is very useful to model norms. Consider some

of the norms maintained by the zoo. A zoo just as

any other organization is an organism that seeks

some permanency and which takes actions to

maintain this permanency. Thus, the zoo needs a

continuous in-flow and out-flow of visitors, animals,

feed, medicine, employees etc. Without these flows

the zoo may not survive. The zoo is likely to take

many actions to restore any one of these flows to the

norm it depends on if the flow comes to be below a

given tolerance level. These actions can be modelled

as maintenance, softgoals, feedback and

achievement goals.

If maintenance goals are augmented with

tolerance levels (imported from feedback goals) they

can be used to model norms.

The Concept of High-level Goal. While both why

and how questions are encouraged by GORE

methods, the how is much more prevalent in GORE

publications. Most often, a so-called high-level goal

is postulated to be strategic for the organization

under analysis and is refined into subgoals.

For example, van Lamsweerde gives the

following examples for “high-level, strategic

concern”: “serve more passengers” for a train

transportation system” and “provide ubiquitous cash

service for an ATM network system.” (van

Lamsweerde, 2001). It is not clear why these should

be considered as high-level, strategic goals and how

they can be satisfied. If the train transportation

system serves a few more passengers, is this goal

achieved? What will the system do next once this

goal is achieved? What if this goal is never

achieved? What would the ATM network system do

once the ubiquitous cash service is provided? What

are the criteria of achievement for a ubiquitous cash

service? Looking closely at these goals, it becomes

clear that they cannot be achieved once and for all

but should be seen as maintenance goals, which are

never fully satisfied. From the regulation viewpoint

they therefore represent norms that may be

considered essential for the survival of the system.

Identifying the norms that are considered

essential for survival helps solve the unacceptable

goal alternatives identified by Zave and Jackson.

Identifying these strategic norms places the

appropriate bounds on what is acceptable and not

acceptable. For the zoo, these norms are the result of

the relationships it maintains, between animals,

visitors, employees, veterinarians, investors,

buildings, donors, etc. Hence, rather than limiting

the field of investigation to the objects and actions

observable at the zoo entrance, the turnstile can be

seen as an essential artefact in this regulation of

relationships, even those that are not immediately

observable at the zoo entrance, which will expand

the field of investigation without crossing into

subjects such as selling the zoo or religious

devotion.

For example, asking what norms does the

turnstile maintain may lead to answers such as that it

regulates the in-flow of people, filtering between

people who have the right to enter the zoo and those

that don’t. Knowing more about the norms

maintained by the rest of the zoo, we can infer more

about current and possible future norms. It is clear

that the turnstile cannot maintain the expected norm

if the zoo is not protected from rogue entrance

elsewhere. The zoo must maintain this protection

(probably in the form of a fence). Knowing that

people can enter and leave the zoo only through the

turnstile, we can see that the turnstile can maintain

the number of people presently inside the zoo, which

can help maintain security norms (preventing

overcrowding, helping to insure complete

evacuation in case of emergency and at closing time

(another norm). Knowing about new norms of

potential visitors, the turnstile can be made to accept

cash, credit card and smartphone payments. It can

allow quick admission of groups (a norm).

A more widespread use of maintenance goals as

the highest-level goals that model an organization

survival is therefore necessary.

Goal Refinement and Goal Abstraction. All

GORE methods place goals in a hierarchy. Goal

refinement is used to identify lower-level goals by

asking how a given goal is achieved. Goal

abstraction is used to identify higher-level goals by

asking why a given goal needs to be achieved.

GORE methods have very good constructs for

formalizing more or less predefined goals but goal

discovery is still a challenge. Hence, despite

arguments to the contrary (e.g. (van Lamsweerde,

2001)), GORE publications often describe tools for

goal refinement but very little goal abstraction. The

REGULATION, THE INVISIBLE PART OF THE GOAL ORIENTED REQUIREMENTS ENGINEERING ICEBERG

problem may come from the difficulty in identifying

the sought-out high-level goals.

Both goal refinement and goal abstraction create

a rather simplistic model of human and

organizational behaviour.

Consider goal abstraction, in Zave and Jackson’s

(1997) example of the zoo turnstile, the engineers

ask themselves why questions and come up with

higher level goals and alternatives. This is not

usually the way requirements are identified. The

engineers are supposed to ask the zoo employees or

owners why they need a turnstile. In our experience,

asking stakeholders why they need some solution

that they identified is as likely to lead to answers

such as, “because I want this other thing” as to

answers such as “because I believe this.” In the zoo

example, asking the owners why they want to install

a computer-controlled turnstile may yield answers

such as:

• We want to have a more efficient admission

system.

• We believe that a computer-controlled turnstile

will be more efficient than our manually controlled

admission system.

• The zoo in the neighbouring town recently

installed a computer-controlled turnstile and are very

happy with it.

These answers can be translated into higher-level

goals (i.e. improve efficiency, match the

competition) but this would mask the issue that this

is just the owners’ beliefs about their zoo. If these

issues are captured as goals they are more likely to

go unchallenged than if they are treated as beliefs.

Goal refinement can equally be improved by the

use of beliefs. Remember that goals and beliefs are

co-dependent as a result of the interlocking of the

three judgments that form the appreciative system.

Consider asking the zoo owners how they would

like to make their zoo more efficient. If they believe

that the best way is to install a computer-controlled

turnstile, they will ask for one. If they believe that

cost cutting will yield better results, they will ask for

cost cutting measures. If they think that both are

needed, they will ask for both. Capturing the goal

refinement as an and/or tree will result in the loss of

these beliefs and more importantly in the

opportunity to challenge them. For a more elaborate

explanation of beliefs and their use in GORE

methods, see (Regev and Wegmann, 2005). More

research can be done on modelling reality and value

judgments as beliefs.

A more widespread use of maintenance goals in

conjunction with achievement goals and beliefs can

help in modelling regulation and may help to better

understand requirements. A beginning of a solution

is proposed in our previous work (Regev and

Wegmann, 2004).

5 RELATED WORK

Several conceptual studies of GORE methods have

been published over the years, e.g. (Kavakli, 2002),

(Kavakli and Loucopoulos, 2005). These studies

assume a viewpoint from within the RE research

paradigm. They do not ground their research in an

external body of knowledge, which limits their

explanatory power of goals. Moody et al. (2010)

have studied the graphical language of i* and its fit

with users’ understanding. We have proposed an

explanation of goals based on General Systems

Thinking and Vickers’s work in (Regev and

Wegmann, 2005).

Our work is similar in nature to Checkland and

Holwell’s conceptual cleansing (1998) of the field of

information systems. Checkland (Checkland and

Scholes, 1990) has worked extensively to popularize

Vickers’s work with Soft System Methodology

(SSM). Ours is a very short description of Vickers’s

appreciative system. More elaborate descriptions are

available in Vickers’s writings (Vickers, 1968),

(Vickers, 1987), and in (Checkland and Scholes,

1990), (Checkland, 2005), (Regev et al., 2011).

6 CONCLUSIONS

RE is about understanding peoples’ desires and

maybe designing some automated system to help

them to obtain or maintain them. RE must therefore

make the balance between what is desired and what

is feasible. To understand what is desired, it is above

all necessary to understand how people behave.

GORE methods have made major contributions to

the practice of RE but have modelled human and

organizational behaviour in too simplified terms,

mostly as goals to be achieved. In this paper, we

have shown that goals can be seen as the visible part

of regulation. Regulation models the way

organizations (be they people or organizations)

attempt to survive in a changing environment.

Regulation results in the establishment of norms,

stable states that define the identity and therefore the

survival of an organization. A long lasting

BMSD 2011 - First International Symposium on Business Modeling and Software Design

organization manages its internal and external

relationships in a way that controls the changes to

these norms but still allows them to change when

needed. Looking at regulation rather than goals

shifts the attention to the way people manage

stability and change by managing relationships.

To understand people’s desires it is important to

analyse this more fundamental aspect of their

behaviour, which is regulation rather than goals. RE

has already defined most of the useful concepts

needed for the study of regulation, e.g. maintenance

goals, and beliefs. What is needed is a paradigm

change from goals to regulation. This paradigm

change will hopefully result in the more widespread

use of these goal-oriented concepts.

A useful stream of research with which to

connect, is General Systems Thinking, which has

most of the necessary constructs to understand

regulation in all kinds of systems, e.g. (Weinberg,

1975), (Weinberg and Weinberg, 1988), (Ashby,

1956). Organizational Semiotics can also be useful

because it is the study of norms in organizations

(Chong and Liu, 2002), (Shishkov, Xie, Liu, Dietz,

2002).

REFERENCES

Anton, A. I., 1996. Goal-based requirements analysis. In

ICRE’96 Second International Conference on

Requirements Engineering, IEEE.

Anton, A. I., Potts, C., 1998. The use of goals to surface

requirements for evolving systems. In ICSE 98

International Conference on Software Engineering,

IEEE.

Ashby, W. R., 1956. An Introduction to Cybernetics,

Chapman Hall. London.

Checkland, P., Scholes, J., 1990. Soft System Methodology

in action, Wiley. Chichester, UK.

Checkland P, Holwell, S., 1998. Information, systems and

information systems - making sense of the field. Wiley.

Chichester, UK.

Chong, S., Liu, K., 2002. A Semiotic Approach to

Improve the Design Quality of Agent-Based

Information Systems. In Liu, K., Clarke, R.J.,

Anderson, P.B., and Stamper, R.K. Coordination and

Communication Using Signs: Studies in

Organizational Semiotics, Kluwer.

Cockburn, A., 2001. Writing Effective Use Cases,

Addison-Wesley. Reading, MA.

Constantine, L., 1995. Essential modeling: Use cases for

user interfaces. In ACM Interactions, 2(2), 34–46.

Dardenne, A., Fickas, S., van Lamsweerde, A., 1991.

Goal-directed concept acquisition in requirements

elicitation. In IWSSD ’91, Sixth International

Workshop on Software Specification and Design,

ACM.

Dardenne, A., van Lamsweerde A., Fickas, S., 1993. Goal

Directed Requirements Acquisition. Science of

Computer Programming, 20(1-2), 3–50.

Dubois, E., 1989. A Logic of Action for Supporting Goal-

oriented Elaborations of Requirements. In IWSSD ’89,

Fifth International Workshop on Software

Specification and Design, ACM.

Gause, D.C., Weinberg, G. M., 1989. Exploring

Requirements: Quality BEFORE Design, Dorset

House, N.Y.

ITU-T, Telecommunication Standardization Sector of

ITU, 2008. User requirements notation (URN) –

Language definition (Z.151).

Kavakli, E., 2002. Goal-Oriented Requirements

Engineering: A Unifying Framework. Requirements

Engineering, 6(4), 237-251.

Kavakli, E., Loucopoulos, P., 2005. Goal Modeling in

Requirements Engineering: Analysis and Critique of

Current Methods. Information Modeling Methods and

Methodologies, 102-124.

Loucopoulos, P., Kavakli, E., 1995. Enterprise Modelling

and the Teleological Approach to Requirements

Engineering. Intelligent and Cooperative Information

Systems, 4(1), 45-79.

Moody, D., Heymans, P., Matulevičius, R., 2010. Visual

syntax does matter: improving the cognitive

effectiveness of the i* visual notation.

Requirements

Engineering, 15(2), 141-175.

Mylopoulos, J., Kolp, M., Castro, J., 2001. UML for

Agent-Oriented Software Development: The Tropos

Proposal. In UML 2001, Fourth International

Conference on the Unified Modeling Language,

Springer.

Mylopoulos J., 2006. Goal-Oriented Requirements

Engineering: Part II. Keynote Talk, RE’06, 14

IEEE

Requirements Engineering Conference, Minneapolis,

MS, September 2006.

http://www.ifi.uzh.ch/req/events/RE06/ConferencePro

gram/RE06_slides_Mylopoulos.pdf, accessed May

2011.

Nilsson, N. J., 1971. Problem Solving Methods in

Artificial Intelligence, McGraw-Hill.

Nuseibeh, B., Easterbrook, S., 2000. Requirements

engineering: a roadmap. In ICSE '00, International

Conference on The Future of Software Engineering,

ACM.

RE04, 2004. Requirements Engineering International

Conference 2004, http://www.re04.org/, accessed May

2011.

Regev, G., Wegmann, A., 2004. Defining early it system

requirements with regulation principles: the

lightswitch approach. In RE’04, 12th IEEE

International Requirements Engineering Conference,

IEEE.

Regev, G., Wegmann, A., 2005. Where do Goals Come

From: the Underlying Principles of Goal-Oriented

Requirements Engineering. In RE’05 13th IEEE

International Requirements Engineering Conference,

IEEE.

REGULATION, THE INVISIBLE PART OF THE GOAL ORIENTED REQUIREMENTS ENGINEERING ICEBERG

Regev, G., Hayard, O., Gause, D. C., Wegmann, A. 2009.

Toward a Service Management Quality Model. In

REFSQ'09, 15th International Working Conference on

Requirements Engineering: Foundation for Software

Quality Springer.

Regev, G., Hayard, O., Wegmann, A., 2011. Service

Systems and Value Modeling from an Appreciative

System Perspective. In IESS1.1, Second International

Conference on Exploring Services Sciences, Springer.

Robinson, W. N., 1989. Integrating multiple specifications

using domain goals. In In IWSSD ’89, Fifth

International Workshop on Software Specification and

Design, ACM.

Rolland, C., Souveyet, C., Ben Achour, C., 1998. Guiding

goal modeling using scenarios. IEEE Trans. Software

Eng., 24, 1055–1071.

Sutcliffe, A. G., Maiden, N. A. M., 1993. Bridging the

Requirements Gap: Policies, Goals and Domains. In

IWSSD ’93 7th International Workshop on Software

Specification and Design, IEEE.

Shishkov, B., Xie, Z., Liu, K., Dietz, J. L. G., 2002. Using

Norm Analysis to Derive Use Cases from Business

Processes, In OS 2002, 5th Workshop On

Organizational Semiotics.

van Lamsweerde, A., 2001. Goal-Oriented Requirements

Engineering: A Guided Tour, in RE’01, 5th IEEE

International Symposium on Requirements

Engineering, IEEE.

Vickers, Sir G., 1968. Value Systems and Social Process,

Tavistock, London.

Vickers, Sir G., 1987. Policymaking, Communication, and

Social Learning, eds, Adams, G. B., Forester, J.,

Catron, B. L.,Transaction Books. New Brunswick NJ.

Weinberg, G. M., 1975. An Introduction to General

Systems Thinking, Wiley, New York.

Weinberg, G. M., Weinberg, D., 1988. General Principles

of Systems Design, Dorset House.

Yu, E. S. K., 1997. Towards modelling and reasoning

support for early-phase requirements engineering. In

RE’97, Third IEEE International Symposium on

Requirements Engineering, IEEE.

Zave, P. and Jackson, M., 1997. Four Dark Corners of

Requirements Engineering, ACM Transactions on

Software Engineering and Methodology, 6(1), 1-30.

BMSD 2011 - First International Symposium on Business Modeling and Software Design