Goal Modeling

This page evolves constantly and reflects the never ending changes to our understanding of the field of Goal-Driven Requirements Engineering.

About Goal-Driven RE 

Some History :

From the 10th RE conference site (RE’02): “Over the last ten years, RE has moved from an immature software engineering phase to a well-recognised practice and research area spanning the whole system lifecycle. RE requires a variety and richness of skills, processes, methods, techniques and tools. In addition, diversity arises from different application domains ranging from business information systems to real-time process control systems, from traditional to web-based systems as well as from the perspective being system families or not.” Synonyms: Goal-driven, goal-directed, goal-oriented, goal-based. Notice that goal-directed is a trademark of Cooper Interactive Design which is why we will not use this term even though it is more popular than goal-directed, preferring the neutral term goal-driven.

The Key Ideas :

Requirements engineering (RE) is concerned with producing a set of specifications for software systems that satisfy their stakeholders and can be implemented, deployed and maintained. Goal-driven requirements engineering takes the view that requirements should initially focus on the why and how questions rather than on the question of what needs to be implemented. “Traditional” analysis and design methods focused on the the functionality of the system to be built and its interactions with users. Instead of asking what the system needs to do, goal-driven methods ask why a certain functionality is need and how it can be implemented. Thus goal-driven methods give a rationale for system functionality by answering why a certain functionality is needed while also tracking different implementation alternatives and the criteria for the selection among these alternatives.

Underlying the insistence on goals is a model of human organizations which views humans and organizations as goal-seeking entities. This model is prevalent in the Information Technology (IT) and Information System (IS) fields [Checkland & Holwell 1998]. In this model (which remains implicit in the RE literature) information systems are considered to be built in order to help people and organizations achieve their goals . In tune with this traditional view, Requirements Engineering (RE) is now defined by the RE community as goal-driven. For instance, in the words of the 10th RE conference (RE’02): “Requirements Engineering (RE) is the branch of systems engineering concerned with the real-world goals for, functions of, and constraints on software-intensive systems. It is also concerned with how these factors are taken into account during the implementation and maintenance of the system, from software specifications and architectures up to final test cases.”

The focus on goals can be understood by examining the following quote from the seminal KAOS paper [Dardenne et al 1993]: “Goals are important in several respects. They lead to the incorporation of requirements components which should support them. They justify and explain the presence of requirements components which are not necessarily comprehensible to clients. They may be used to assign the respective responsibilities of agents in the system; more precisely, they may provide the basis for defining which agents should best perform which actions to fit prescribed constraints (according to their capabilities, reliability, cost, load, motivation, and so forth). Finally, they provide basic information for detecting and resolving conflicts that arise from multiple viewpoints among human agents [Rob89]. [Rob89] W.N. Robinson, “Integrating Multiple Specifications Using Domain Goals”, Proceedings 5th International Workshop on Software Specification and Design, May 1989, 219-226.”

The goal-driven approaches we know of:

  • The KAOS ((Knowledge Acquisition in autOmated Specification) approach consists of a formal framework based on temporal logic and AI refinement techniques where all terms such as goal and state are consistently and rigorously defined. The main emphasis of KAOS is on the formal proof that the requirements match the goals that were defined for the envisioned system.
  • The Non-Functional Requirements (NFR) approach [Mylopoulos et al. 1999], [Nixon 1992] is based on the notion of softgoals rather than (hard) goals. A softgoal is satisficed rather than achieved [Mylopoulos et al. 1999]. Goal satisficing is based on the notion that goals are never totally achieved or not achieved. Therefore Mylopoulos et al [Mylopoulos et al. 1999] state that, “softgoals are satisficed when there is sufficient positive and little negative evidence for this claim, and that they are unsatisficeable when there is sufficient negative evidence and little positive support for their satisficeability.” For more information about NFR and its related techniques, Tropos, I*, Telos etc. check out Mylopoulos’s 1999 presentation. The NFR approach evolved into the Goal-oriented Requirement Language (GRL). GRL is part of the ITU-T URN standard draft which also incorporates Use Case Maps (UCM).
  • Goal-Based Requirements Analysis Method (GBRAM) [Anton 1997] defines a top-down analysis method refining goals and attributing them to agents starting from inputs such as corporate mission statements, policy statements, interview transcripts etc.
  • The ESPRIT CREWS approach [Rolland et al. 1998] focuses more on goal definition and the linking of goals to stakeholders’ actual needs by linking goals and scenarios.
  • Pohl and Haumer [Pohl & Haumer 1997] and Kaindl [Kaindl 2000] also define methods for relating goals with scenarios.

Owners of goals:

A important aspect of a goals is to know whose goal it is. The different methods define different kinds of “owners” of goals.

  • KAOS distinguishes between private and system goals [Dardenne et al 1993]:
    • private goals are goals of individual agents
    • system goals are the goals of the system as whole.
  • Cooper distinguishes between personal, corporate, practical, and false goals [Cooper 1996]:
    • personal goals are goals of individual users which are connected with their self esteem and the interest they see in the system they use
    • corporate goals are goals of the organization as a whole
    • practical goals are goals that individual users need to achieve to satisfy corporate goals
    • false goals are goals that are imposed on users by the system and are part of the goal that the developers of the system need to satisfy
  • Pohl and Haumer distinguish between business and personal goals [Pohl & Haumer 1997].

Types of goals:

KAOS defines a goal taxonomy having 2 dimensions [Dardenne et al 1993]:

  • goal patterns: Achieve, Cease, Maintain, Avoid, Optimize.
  • goal categories
    Goal categories form a hierarchy. At the root of the hierarchy are system goals and private goals (see owner of a goal). System goals have the following sub-categories:

    • Satisfaction goal,
    • information goal,
    • robustness goal,
    • consistency goal,
    • safety and privacy goal.
  • GBRAM distinguishes between achievement goals and maintenance goals, stating that “a maintenance goal is satisfied as long as its target condition remains true. Maintenance goals are usually high-level goals with which associated achievement goals should comply” [Anton & Potts 1998].

Goal refinement and abstraction:
Goal refinement is the process through which goals are broken down into sub-goals. Goal abstraction proceeds in the opposite direction providing super-goals. Goals can be refined into sub-goals by asking how these goals should be achieved while super goals are found by asking why a certain goal is sought [van Lamsweerde 2000].

The source of goals:
In the goal-driven literature, the main sources for identifying goals are considered to be scenarios, use cases, interview transcripts, corporate mission statements, policy statements, corporate goals etc [Anton 1997, van Lamsweerde et al. 1995].

Scenarios are used extensively, both to express how goals can be implemented and to “discover” goals. Rolland et al. [Rolland et al. 1998], for instance, propose a bi-directional linking of goals and scenarios: “As each individual goal is discovered, a scenario can be authored for it. In this sense, the goal-scenario coupling is exploited in the forward direction, from goals to scenarios. Once a scenario has been authored, it is explored to yield goals. This leads to goal discovery by moving along the goal-scenario relationship in the reverse direction.” 
However, scenarios are and were used independently of goal-driven methods. Object-Oriented Analysis and Design methods (OOAD), for instance, use scenarios and their abstract counterparts – use cases – for defining objects and their associated methods. Nouns identified in scenarios are tentative objects while verbs represent their tentative methods. An identical strategy is followed by goal-driven methods. 
The advantage of goal-driven methods over standard OOAD is in the explicit search for sub-goals, super-goals and alternative goals. Whereas OOAD produces tentative objects and methods which are then transformed (many time by an obscure mechanism) into design objects and methods, goal-driven methods will explicitly attempt to define

  • sub-goals by asking how a goal can or should be implemented
  • super-goals by asking why a goal is necessary or needed
  • alternatives by asking what different ways of satisfying the super-goal exist
  • conflicting goals by asking what obstacles can be found for a goal and what goals may conflict with one another

When used with inputs other than scenarios and use cases such as problem statements and informal requirements documents, goal-driven methods infer goals contained in those documents by asking questions such as “what goal does this fragment exemplify?” [Anton 97, p. 76]. Anton defines these techniques as an extension of OOD techniques for circling action words and verbs as proposed by Abbott, Booch and Rumbaugh et al. Cockburn and Constantine are not directly related to the goal-driven RE community but also focus on goals and use cases:

  • Cockburn [Cockburn 2000] defines that each use case be the implementation of a stakeholder’s goal.Multiple stakeholders participate in the use case and their interests should also be protected by the interactions defined in the use case. For Cockburn the collection of use cases is at the heart of the system’s requirements, even though they don’t represent all the requirements.
  • Constantine’s essential use cases [Constantine 1995, Constantine & Lockwood 1999] are also goal-driven. An essential use case implements a user goal but focuses only on the most important aspects of the interaction between the user and the system as seen from the user’s point of view. Constantine defined these use cases because he felt that standard use cases as defined by Jacobson focus too much on the details of the interaction with the system rather than on the minimal steps necessary to satisfy the user’s goal. In other words standard use cases are full of “false” goals as defined by Cooper. Constantine defined essential use cases with the goal of improving system usability, hence the one on one interaction between the use and the system.

What is a goal?
The definitions found in the literature

  • [Dardenne et al. 93]
    • “A goal is a nonoperational objective to be achieved by the composite system. Nonoperational means that the objective is not formulated in terms of objects and actions available to some agent in the system; in other words, a goal as it is formulated cannot be established through appropriate state transitions under control of one of the agents.”
    • “A constraint is an operational objective to be achieved by the composite system. As opposed to goals, a constraint is formulated in terms of objects and actions available to some agent in the system; that is, it can be established through appropriate state transitions under control of one of the agents.”
    • Objective: not defined.
  • [Anton 97]
    • Goals are targets for achievement which provide a framework for the desired system. Goals are high level objectives of the business, organization, or system. They express the rationale for proposed systems and guide decisions at various levels within the enterprise. Corporate profits maximized is an example of a high-level enterprise goal. The two primary types of goals discussed in this thesis are achievement and maintenance goals.
    • Achievement goals are objectives of an enterprise or system. For example, a university course registration system may need to satisfy the goal of enrolling students in courses before the first day of class each semester. The object of the goal identified by the stakeholders as the primary purpose of the system is course registration. In general achievement goals ma be mapped to functional requirements.
    • Maintenance goals are those goals which are satisfied while their target condition remains constant or true. They tend to be operationalized as actions or constraints that prevent certain states from being reached. In general, maintenance goals map to nonfunctional requirements.
  • [Van Lamsweerde et al. 1998]
    • “Goal: a goal is an objective the composite system should meet.”
    • “Requisite: a requisite is a goal that can be formulated in terms of states controllable by some individual agent. Goals must be eventually AND/OR refined into requisites assignable to individual agents.”
    • “A requirement is a requisite assigned to a software agent;”
    • “An assumption is a requisite assigned to an environmental agent. Unlike requirements, assumptions cannot be enforced in general.”
  • [Lamsweerde & Letier 2000]
    • “Semantically speaking, a goal defines a set of desired behaviors, where a behavior is a temporal sequence of states (see Section 2.2). A positive scenario is a sequence of state transitions, controlled by corresponding agent instances, that produces such a desired behavior (see Section 2.1). Goal refinement yields sufficient subgoals for the goal to be achieved.”
    • “Likewise, an obstacle defines a set of undesirable behaviors; a negative scenario produces a behavior in this set. Goal obstruction yields sufficient obstacles for the goal to be violated; the negation of such obstacles yields necessary preconditions for the goal to be achieved.”
  • [Lamsweerde 2000]
    • “Broadly speaking, a goal corresponds to an objective the system should achieve through cooperation of agents in the software-to-be and in the environment.”
  • [Mylopoulos et al. 1999]
    • “Soft-goals are goals that do not have a clear-cut criterion for their satisfaction. We will say that softgoals are satisficed when there is sufficient positive and little negative evidence for this claim, and that they are unsatisficeable when there is sufficient negative evidence and little positive support for their satisficeability.”
  • [Kaindl 2000]
    • “The goals considered here are only the “basic” goals that can be achieved through the execution of a scenario. We view them as partially specified states of the “world” that the user participating in such a scenario considers as desirable.”
  • [Rolland et al 1998]
    • “A goal is defined as something that some stakeholder hopes to achieve in the future”
  • [Pohl & Haumer 1997]
    • “the goals represent the objectives an actor wants to achieve when requesting a certain service.”
    • “The concept of goal is used to describe an objective to be achieved in the macrosystem, e.g. business goal, personal goal etc.”
  • [RM-ODP Enterprise Language]
    • Purpose (of a system): The practical advantage or intended effect of the system.
    • Objective: Statements of preference about possible future states, which influence the choices within some behaviour.
  • [Cockburn 2000]
    • “Delivering a service promise is a topmost goal, achieved through subgoals.”
  • [Cooper 1996]
    • Goal, not defined.
    • Goal categories: false (system centric goals), corporate (community), practical (get job done), and personal (self esteem).

What’s missing :

What’s missing from the goal-driven RE methods we have reviewed above is the following:

From the perspective of enterprise information systems, a discussion of whether goal-seeking is the correct organizational model. Since goal-driven RE methods seem to be based on a goal-seeking model of human and organizational behavior, it would be beneficial to understand how these methods would fare if we tried to use them with a different human and organizational model.

Goals are considered to exist in the “reality” and their hierarchical standing seems to be an absolute value. Consider this statement from the KAOS seminal paper [Dardenne et al 1993]: “A distinguished feature of the approach presented in the paper is the importance given to high-level goals as opposed to their operationalization into constraints to be ensured by agents through appropriate actions. Instead of starting directly from lower-level process- or action-oriented descriptions as usually done in current requirements engineering methods, the approach starts from system-level and organisational objectives from which such lower-level descriptions are progressively derived.” We can ask, what is a high-level goal? Who says it is high-level? One person’s high-level goal is another’s implementation detail. How do we know that the identified goals are really the right goals to be designing the system for? Consider the example of an ATM (Automatic Teller Machine), the favorite example in requirements engineering and software engineering. We usually consider a high level goal of the ATM to be cash delivery [Constantine 95]. It is a high level goal for the ATM but not necessarily for the user.

Goals seem to be either a system goal or a private/individual goal. There’s no mention of the influence of (interrelated) communities, their corresponding activities, their policies and their interpretations of each other’s policies on the goal structure. In our views, inherited from Sir Geoffrey Vickers and Peter Checkland, interpretations, policies, activities and goals, are interrelated and cannot be separated one from the other. A policy cannot be changed without changing the corresponding interpretation and activities that led to the definition of the policy. Changing the policy, in turn, changes the acticities and goals. GRL moves in the right direction by adding the concepts of scope and belief. The scope enables the modeler to model a community or individual, the belief, attached to means-ends or satisficing relationships shows that an interpretation (or belief) is not dissociable from the way of doing something (policy). Unfortunately, in the examples provided in the i* and GRL literature, these two concepts (scope, belief) are not fully exploited. See Yu et al’s paper Modelling the Organization and the GRL tutorial

Goals are assumed to exist in a hierarchy. This hierarchy is assumed to be “discoverable” by mechanistic processes.

The most often assumed definition of a goal is the achievement goal. From the methods we surveyed only KAOS [Dardenne et al 1993] and GBRAM [Anton 1997] distinguish between achievement goals and maintenance goals. Unfortunately, KAOS states that maintenance goals restrict behavior [Dardenne et al. 1993]. Consider the example of maintaining a good relationship with a customer. This would qualify as a maintenance goal but is far from restricting behavior. It actually defines an infinite number of possible behaviors stemming from insuring the satisfaction of the customer. In GBRAM the definition of maintenance goals includes the following “They tend to be operationalized as actions or constraints that prevent certain states from being reached. In general, maintenance goals map to nonfunctional requirements” [Anton 1997]. This formulation does take into account that maintenance goals generate behavior but saying that they map to non-functional requirements tend to diminish their importance.

The separation of functional from non-functional requirements. In our sense, this separation depends on the point of view of the requirements engineer. For instance, it can be argued that for the security specialist security requirements are functional, i.e. some functions need to be built into the system to protect it from attacks. Requirements engineers, however, usually categorize security as non-functional. The same can be said about business rules (which also define behavior and therefore functionality), persistency etc. The a-priori separation between functional and non functional requirements leads to confusion about the requirements and avoidable conflicts.

Bibliography :

  • [Anton 97]
    • A.I. Anton, “Goal Based Requirements Analysis,” in Proc. Second Int. Conference on Requirements Engineering., ICRE ’96, pp. 136–144, 1996.
    • A. I. Anton, “Goal Identification and Refinement in the Specification of Software-Based Information Systems,” Ph.D. Dissertation, Georgia Institute of Technology, Atlanta GA, 1997.
    • A. I. Anton, C. Potts, “The use of goals to surface requirements for evolving systems,” in Proc. of the 1998 Int. Conference on Software Engineering, pp. 157-166, 1998.
    • A. I. Anton, J.B. Earp, C. Potts, T.A. Aspaugh, “The role of Policy and Stakeholder Privacy Values in Requirements Engineering,” in Proc. Fifth IEEE Int. Symposium on Requirements Engineering, pp. 138-145, 2001.
  • [Cockburn 2000]
    • A. Cockburn, Writing Effective Use Cases. Reading, MA: Addison-Wesley, 2000.
  • [L. Constantine]
    • L. Constantine, “Essential modeling: Use cases for user interfaces,” ACM Interactions, vol. II.2, pp. 34–46, Apr. 1995.
    • L. Constantine and L. Lockwood, Software for Use. New York: ACM Press 1999.
  • [Cooper 1996]
    • A. Cooper, “Goal-Directed software design,” Dr. Dobbs Journal, Sept. 1996.
  • [Dardenne et al. 93]
    • A. Dardenne, A. van Lamsweerde and S. Fickas, “Goal Directed Requirements Acquisition,” Science of Computer Programming, vol. 20, pp. 3–50, Apr. 1993.
  • [R. Darimont and A. van Lamsweerde]
    • R. Darimont and A. van Lamsweerde, “Formal Refinement Patterns for Goal-Driven Requirements Elaboration,” in Proc. 4th ACM Symposium on the Foundations of Software Engineering (FSE4), San Francisco, pp. 179-190, Oct. 1996.
  • [Kaindl 2000]
    • H. Kaindl, “A Design Process Based on a Model Combining Scenarios with Goals and Functions,” IEEE Trans. Syst., Man, Cybern. A, vol. 30, no. 5, September 2000.
  • [N. G. Leveson]
    • N. G. Leveson, “Intent specifications: An approach to building human-centered specifications,” IEEE Trans. Software Eng., vol. 26, pp. 15–35, Jan. 2000.
  • [J. Mylopoulos]
    • J. Mylopoulos, L. Chung and E. Yu, “From Object-Oriented to Goal-Oriented,” Communications of the ACM, vol. 42. No. 1, Jan. 1999.
  • [K. Pohl and P. Haumer]
    • K. Pohl and P. Haumer, “Modelling Contextual Information about Scenarios,” Third Int. Workshop on Requirements Engineering: Foundation for Software Quality RESFQ, Barcelona, Spain, June 16-17, 1997.
  • [C. Rolland, C. Souveyet, C. Ben Achour]
    • C. Rolland, C. Souveyet, C. Ben Achour, “Guiding goal modeling using scenarios,” IEEE Trans. Software Eng., vol. 24, pp. 1055–1071, Dec. 1998.
  • [A.G. Sutcliffe and N.A.M. Maiden]
    • A.G. Sutcliffe and N.A.M. Maiden, “Bridging the Requirements Gap: Policies, Goals and Domains,” Proc. 7th Int. Workshop on Software Specification and Design, Redondo Beach, CA, December 1993.
  • [A. van Lamsweerde, R. Darimont and P. Massonet]
    • A. van Lamsweerde, R. Darimont and P. Massonet, “Goal-Directed Elaboration of Requirements for a Meeting Scheduler: Problems and Lessons Learnt,” 2nd Int. Symposium on Requirements Engineering (RE’95), York, UK, pp. 194-203, March 1995.
  • [A. van Lamsweerde]
    • A. van Lamsweerde, “Requirements Engineering in the Year 00: A Research Perspective,” in Proc. 22nd Int. Conf. Software Engineering, Limerick, ACM Press, June 2000.
  • [A. van Lamsweerde, E. Letier]
    • A. van Lamsweerde, E. Letier, “Handling Obstacles in Goal-Oriented Requirements Engineering,” IEEE Trans. Software Eng. Special Issue on Exception Handling, 2000.
  • [E. Yu, J. Mylopoulos]
    • E. Yu, J. Mylopoulos, “Using Goals, Rules and Methods to Support Reasoning in Business Process Reengineering,” Proc. 27th Hawaii Int. Conf. System Sciences, Maui, Hawaii, vol. 4, pp. 234–243, Jan. 1994.
  • [E. Yu, J. Mylopoulos]
    • E. Yu, J. Mylopoulos, “Toward Modeling Strategic Actor Relationships for Information Systems Development – with Examples from Business Process Reengineering”, Proc 4th Workshop on Information Technologies and Systems, 1994.

Who’s who :

  • Axel van Lamsweerde (KAOS method)
  • Eric Yu (NFR framework)
  • John Mylopoulos (NFR framework)
  • Collette Rolland (ESPRIT CREWS project)
  • Annie Anton (GBRAM)
  • Requirements Engineering Journal
  • RE’xx Conference
  • Goal-oriented Requirements Language (GRL) site
  • Use Case Maps (UCM) site