Gil Regev
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},
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.
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.
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
2011 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
subject matters (Zave and Jackson, 1997) and
scenarios (Rolland, Souveyet and Ben Achour,
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.
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
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
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,
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,
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
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.
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,
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
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
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
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.
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
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
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
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
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).
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).
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,
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,
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,
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.
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,
Mylopoulos J., 2006. Goal-Oriented Requirements
Engineering: Part II. Keynote Talk, RE’06, 14
Requirements Engineering Conference, Minneapolis,
MS, September 2006.
gram/RE06_slides_Mylopoulos.pdf, accessed May
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,
RE04, 2004. Requirements Engineering International
Conference 2004,, accessed May
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,
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,
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