Eric Yu and John Mylopoulos

University of Toronto

1. Introduction

The notion of goal is increasingly being used in requirements engineering (RE) methods and techniques today. Goals have been introduced into RE for a variety of reasons – within different RE activities, and to achieve different objectives. In some RE frameworks, they are central; in others, they play a supporting role. While authors have argued convincingly for the significance and usefulness of goals in their respective frameworks, there has not been a comprehensive attempt at understanding and clarifying the roles of goals across the different areas of RE. This paper argues that such an attempt would be worthwhile, and outlines some research issues that need to be addressed.

 

2. Why are goals useful in RE?

It has been observed that "the subject of RE is inherently broad, interdisciplinary, and open-ended. It concerns translation from informal observations of the real world to mathematical specification languages. For these reasons, it can seem chaotic in comparison to other areas in which computer scientists do research." [Zave97] Perhaps for the same reasons, it is difficult to discern a uniform notion of goal in RE. Many researchers have found it helpful to introduce some notion of goal in the area of their work. We briefly review some of these to see why some researchers have considered goals to be an important construct in a number of different areas of RE.

1. Requirements Acquisition

Goals are seen to have substantial promise in aiding the elicitation and elaboration of requirements. For example, the KAOS methodology [Dardenne93] uses goal as the central concept in requirements acquisition. Anton also uses goals as the main guiding concept in developing requirements specifications [Anton96, 97]. The identification of goals naturally lead to the repeated asking of "why", "how" and "how else" questions [Yu94a]. The requirements of a stakeholder are often revealed in the process of elaborating a goal (or means-ends) hierarchy. Stakeholders also become more aware of potential alternatives for meeting their substantive goals, and are therefore less likely to over-specify by prematurely committing to certain technological solutions. A goal-oriented approach to requirements acquisition may be contrasted with methodologies that treat requirements as consisting only of processes and data, such as traditional systems analysis, e.g, [Ross77][DeMarco78], or "objects," e.g., [Rumbaugh91], but which do not explicitly capture why and how relationships in terms of goals.

2. Relating Requirements to Organizational and Business Context

In the early days, requirements focused only on what the system is supposed to do. Subsequent work emphasized the need to understand and characterize the interaction between the intended system and its environment [Bubenko80] [Greenspan82] [Jackson83]. More recently, as systems are seen as providing solutions to business and organizational problems, the relationship between systems and their environments are being expressed in terms of goal-based relationships [Bubenko93] [Yu94b] [Jacobs95]. This is partly motivated by today’s more dynamic business and organizational environments, where systems are increasingly used to fundamentally change business processes rather than to automate long-established practices. Modelling techniques need to support "why" and "how else" types of reasoning analysis. Pohl et al have emphasized the need to model contexts, and have included goals as an important element [Pohl97].

3. Clarifying Requirements

Requirements are often unclear when first elicited from clients and stakeholders. The introduction of goals offers one way of clarifying requirements [van Lamsweerde95]. Analyzing requirements in terms of goal decomposition and refinement can be seen as teasing out many levels of requirements statements, each level addressing the demands of the next level. This approach to the clarification of requirements is especially appropriate in the case of non-functional requirements (such as flexibility, robustness, reusability, maintainability), where initial requirements can be difficult to make precise. A goal-oriented approach would allow the requirements to be refined and clarified through an incremental process. Chung’s NFR framework [Chung93] [Chung98] is a goal- and process-oriented approach for dealing with non-functional requirements.

4. Dealing with Conflicts

Requirements conflict has been an important focus for RE research. Goal concepts have been used quite extensively to deal with various kinds of conflict. For example, multiple viewpoints can lead to requirements that overlap but do not agree [Nuseibeh93]. Stakeholders may have divergent interests that pull the system in different directions [Yu94][Boehm96] and which may require negotiation to resolve [Robinson90]. Even within a single coherent set of requirements, there can be competing demands on a system. This is especially evident among non-functional requirements, where difficult tradeoffs often need to be made among requirements such as costs, performance, flexibility, usability, etc. [Chung93]. Goals provide a useful way of dealing with conflict because the meeting of one goal may interfere with the meeting of others. Different conceptions of meeting a goal – satisfaction [Dardenne93] vs. satisficing [Chung93] has led to different ways of handling conflict.

5. Driving Design

Requirements must eventually lead to design and implementation. Goals have been used as an important mechanism for connecting requirements to design. The Composite Systems Design approach used goals to construct and later prune the design space [Feather87, 94]. The NFR framework trreats non-functional requirements as goals to guide the design process [Chung93].

6. Other RE tasks

3. Goals as Part of an Intentional Ontology

 One way to look at why goals are used in RE is that goal constructs offer benefits and advantages in each particular area as outlined above. In other words, goals are introduced for pragmatic or engineering reasons – they help accomplish the objectives of several specific subtasks of RE. However, the relatively broad applicability of goal concepts in RE suggests that a more fundamental force may be at work. Perhaps the elucidation and manipulation of goals is a natural and inherent part of doing RE, even though earlier RE methods have not made this explicit, and have not provided the associated support. This interpretation is plausible since requirements by its very nature represents a target to be reached, a wish to be fulfilled, a vision to be materialized.

In this view, the explicit treatment of goals in recent RE frameworks is an indication of a fundamental shift in the ontological underpinnings of RE [Mylopooulos98] [Greenspan94]. Ontology here refers to the basic existential categories in the world that are of interest to the discipline. For a long time, the ontology for RE (or systems analysis) has been limited to those dealing with entities (a static ontology) and activities (a dynamic ontology). Recent movements to object orientation for modelling and analysis have not ventured much beyond these traditional grounds. The deeper significance of the explicit representation of goals in RE is the recognition of the need for intentional concepts when doing RE, of which goal is one of the most central.

Intentional concepts allow one to express that the world can be other than what it is. Goals convey alternate visions of the world as one would desire. Other intentional concepts convey knowledge, belief, intention, ability, commitment, and so forth. Considering goals raises the possibility of success and failure, not just truth versus falsity. Goals lead to the exploration and consideration of alternatives, decision spaces, tradeoffs, and decisions. Very importantly, it allows the expression of freedom within such spaces. One can state a goal without having to specify how it is to be achieved. This allows openness and freedom to be dealt with and reasoned about in RE. If and when appropriate, a goal can be elaborated on incrementally, which may eliminate or reduce some areas of freedom while opening up others. It is this family of related concepts that can add considerably to RE across the board. Goal orientation can therefore be seen as a fundamental movement in RE to extend its traditional ontology to encompass intentional concepts.

 

4. Towards Unifying Goal-Oriented Approaches to RE

1. What aspects of goal concepts can (or should) be common across the various activities and stages of RE, and what aspects need to be different?
2. What types of analyses are associated with what conceptions of goal?
3. In dealing with multiple related goal concepts, what approaches to coupling or integration are appropriate? [Dubois98] [Yu95]
4. How should goal-oriented approaches be related to more traditional, non-goal-oriented approaches (e.g., object-oriented approaches)? For example, would different goal concepts interact differently with classification, generalization, aggregation, encapsulation, and other abstraction mechanisms?
5. Would different conceptions of goal extend differently to Agent-Oriented RE [Yu97b]
6. What are the implications for tools support and tool integration? (e.g., the desired degree of automation and user involvement)

3. Conclusions