Why Goal-Oriented Requirements Engineering

Eric Yu and John Mylopoulos

University of Toronto

  

  1. Introduction
  2. 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.

     

  3. Why are goals useful in RE?
  4. 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
    2. 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.

    3. Relating Requirements to Organizational and Business Context
    4. 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].

    5. Clarifying Requirements
    6. 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.

    7. Dealing with Conflicts
    8. 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.

    9. Driving Design
    10. 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].

    11. Other RE tasks

In addition to the above, goals have been used to provide traceability of rationales (e.g., [Lee91]), management of change (e.g., [Chung96]), verification of achievement of requirements (e.g., [Dubois89]), and process support (e.g., [Chung93] [Pohl96]), support of reuse (e.g., [Chung93] [vanLamsweerde97]). Goals have also been used in scenario-based approaches to RE (e.g., [Potts94] [Pohl97]).

 

  1. Goals as Part of an Intentional Ontology
  2.  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.

     

  3. Towards Unifying Goal-Oriented Approaches to RE

If goal concepts indeed have such fundamental significance in RE, then it would be desirable to seek some coherent view of the various notions of goal within the field. If the various goal-oriented approaches can be put together, one would hope to have a stronger framework that takes advantage of the contributions from the many streams of RE research. We do not know to what extent such a reconciliation or even unification might be feasible. However, even if such attempts are not successful, we would gain better understanding of the issues from the difficulties encountered.  

One approach is to study ontological issues directly. The role and significance of ontologies have been studied within RE (e.g., [Wand90] [Opdahl97]). An extension of such foundational studies to include intentional concepts could help consolidate the diverse notions of goal and goal-oriented approaches in RE. A more concrete approach is to analyze and synthesize the many goal concepts and operations used in various areas of RE. Prat has approached this from a linguistic perspective [Prat97]. 

One could also start from conceptual frameworks that have been developed for characterizing and understanding the relationships among the various activities, issues, and aspects of RE. A number of such frameworks have been proposed. For example, among the more recent ones: Pohl [Pohl93] proposed to see the RE process as progressing along three dimensions – specification, representation, and agreement; Sutcliffe [Sutcliffe96] considered RE from the viewpoint of task activities, initiating conditions, and several product dimensions; Zave [Zave97] used two major dimensions – problems and contributions to solutions – to classify research efforts in RE.  

Goals are mentioned quite prominently in Zave’s categories, although the scheme is not meant to single out any particular concept. Goals are discussed in several contexts in Sutcliffe’s overall framework for assessing RE research and practice. Goals are not as evident in Pohl’s three-dimensional scheme. All three frameworks offer considerable insight in relating the diverse aspects of RE, although none offers any immediate suggestions on how goals might have an overall role in RE.  

One observation while developing the I* framework was that one may need different modelling concepts and reasoning support for different phases of RE. Most requirements techniques have focused on the objectives of achieving completeness, consistency, and precision in moving towards the final requirements document. In contrast, during the earlier stages of the requirements process, it is more important to model and analyze stakeholder interests, and how they might be addressed or compromised by various system-and-environment alternatives. Distinguishing the needs of early vs. late phase RE can lead to conceptions of goals and analysis methods that are substantially different [Yu97a].  

In attempting to reconcile and unify goal-oriented concepts and approaches in RE, at least the following research issues need to be addressed: 

    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)

 

  1. Conclusions

We have argued for the need to develop an overall view of goal concepts in RE and goal-oriented approaches to RE. We noted that the wide-spread adoption of goal concepts in many RE framework in diverse areas suggests that goals may be a core concept for RE in general. Nevertheless, different areas and stages of RE may have distinct needs, and these may present substantial research challenges in the quest for a unified goal-oriented approach for RE. Pursuing these issues could shed light on our understanding of RE as well as on the role of goals in RE.

 

References 

[Antón97] A. I. Anton, Goal Identification and Refinement in the Specification of Software-Based Information Systems, Ph.D. thesis, Department of Computer Science, Georgia Institute of Technology, June 1997.

[Antón96] A. I. Anton, "Goal-based Requirements Analysis." Proc.2nd IEEE Int. Conf. Requirements Eng. April 1996.

[Boehm96] B. Boehm, H. In, Identifying Quality-Requirement Conflicts, IEEE Software, pp. 25-35, March 1996.

[Bubenko80] J. A. Bubenko, Information Modeling in the Context of System Development, Proc. IFIP, pp. 395-411, 1980.

[Bubenko93] J. A. Bubenko, Extending the Scope of Information Modeling, Proc. 4th Int. Workshop on the Deductive Approach to Information Systems and Databases, Lloret-Costa Brava, Catalonia, Sept. 20-22, 1993, pp. 73-98.

[Chung93] K. L. Chung, Representing and Using Non-Functional Requirements for Information System Development: A Process-Oriented Approach, Ph.D. Thesis, also Tech. Rpt. DKBS-TR-93-1, Dept. of Comp. Sci., Univ. of Toronto, June 1993.

[Chung96] L. Chung, B. Nixon, and E. Yu, ``Dealing with Change: An Approach Using Non-Functional Requirements," Requirement Engineering, Springer-Verlag, vol. 1, no. 4, 1996, pp. 238-260.

[Chung98] L. Chung, B. Nixon, E. Yu, and Mylopoulos, J., Non-Functional Requirements in Software Engineering, Kluwer Publishing, (to appear).

[Dardenne93] A. Dardenne, A. van Lamsweerde and S. Fickas, Goal-Directed Requirements Acquisition, Science of Computer Programming, 20, pp. 3-50, 1993.

[DeMarco78] T. DeMarco, Structured Analysis and System Specification, Yourdon Press, N.Y., 1978.

[Dubois98] E. Dubois, E. Yu, and M. Petit, ``From Early to Late Formal Requirements: a Process Control Case Study," Proc. 9th Int. Workshop on Software Specification and Design, Ise-Shima, Japan, April 1998.

[Feather87] M. S. Feather, Language Support for the Specification and Development of Composite Systems, ACM Trans. Prog. Lang. and Sys. 9 (2), pp. 198-234, April 1987.

[Feather94] M. S. Feather, Composite System Design, ICSE-16 Workshop on Research Issues in the Intersection Between Software Engineering and Artificial Intelligence, International Conference on Software Engineering, Sorrento, Italy, May 16-20, 1994.

[Greenspan82] S. J. Greenspan, J. Mylopoulos, and A. Borgida, Capturing More World Knowledge in the Requirements Specification, Proc. Int. Conf. on Software Eng., Tokyo, 1982.

[Greenspan84] S. J. Greenspan, Requirements Modelling: A Knowledge Representation Approach to Software Requirements Definition, Ph. D. Thesis, Dept. of Comp. Sci., Univ. of Toronto, 1984.

[Greenspan94] S. Greenspan, J. Mylopoulos, and A. Borgida. "On Formal Requirements Modelling Languages: RML Revisited." Proc. 16th Int. Conf. Software Eng. Pp. 135-148, Sorrento, Italy, May 1994.

[Jackson83] M. A. Jackson, System Development, Prentice Hall, London, 1983.

[Jacobs95] S. Jacobs and R. Holten, "Goal-Driven Business Modelling – Supporting Decision Making within Information Systems Development," Proc. Conf. On Organizational Computing Systems, Milpitas, Calif. 1995, pp. 96-105.

[Lee91] J. Lee, ``Extending the Potts and Bruns Model for Recording Design Rationale," Proc. 13th Int. Conf. On Software Eng., Austin, Texas, May 1991, pp. 114-125.

[Mylopoulos98] J. Mylopoulos, "Information Modeling in the Time of the Revolution", (submitted for publication).

[Nuseibeh93] B. Nuseibeh, J. Kramer, and A. Finkelstein, ``A Framework for Expressing the Relationships Between Multiple Views in requirements Specifications," IEEE Trans. On Software Eng., vol. 20, no. 10, October 1994, pp.760-773.

[Opdahl97] A. Opdahl, ``Applying Semantic Quality Criteria to Multi-Perspective Problem Analysis Methods," Proc. 3rd Int. Workshop on Requirements Engineering: Foundations of Software Quality REFSQ’97, Barcelona, Catalonia, Spain, June 1997, pp. 49-66.

[Pohl93] K. Pohl, ``The Three Dimensions of Requirements Engineering," Proc. CAiSE’93, Paris. Springer-Verlag, Berlin, 1993, pp. 275-292.

[Pohl96] K. Pohl, Process-Centered Requirements Engineering. Wiley/Research Studies Press, New York, 1996.

[Pohl97] K. Pohl and P. Haumer, ``Modelling Contextual Information about Scenarios," Proc. 3rd Int. Workshop on Requirements Engineering: Foundations of Software Quality REFSQ’97, Barcelona, Catalonia, Spain, June 1997, pp. 187-204.

[Potts94] C. Potts, K. Takahashi, and A. Anton, ``Inquiry Based Requirements Analysis, IEEE Software, March 1994, pp. 21-32.

[Prat97] N. Prat, ``Goal Formalisation and Classification for Requirements Engineering," Proc. 3rd Int. Workshop on Requirements Engineering: Foundations of Software Quality REFSQ’97, Barcelona, Catalonia, Spain, June 1997, pp. 145-156.

[Robinson90] W.N. Robinson, ``Negotiation Behavior During Requirements Specification," Proc. 12th Int. Conf. on Software Eng., March 1990, pp. 268-276.

[Ross77] D. Ross, "Structured Analysis: A Language for Communicating Ideas", IEEE Transactions on Software Engineering, 3(1), January 1977.

[Rumbaugh91] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and W. Lorensen, Object-Oriented Modeling and Design, Prentice Hall, 1991.

[Sutcliffe96] A. Sutcliffe, ``A Conceptual Framework for Requirements Engineering," Requirements Engineering, vol. 1, 1996, pp. 170-189.

[van Lamsweerde95] A. van Lamsweerde, R. Darimont, and P. Massonet, "Goal Directed Elaboration of Requirements for a Meeting Scheduler: Problems and Lessons Learnt. Proc. 2nd IEEE Int. Symp. on Requirements Eng. pp. 194-203.

[Wand90] Y. Wand and R. Weber, ``An Ontological Model of an Information System, IEEE Trans. On Software Eng., 1990, pp. 1282-1292.

[Yu94a] E. Yu, Modelling Strategic Relationships for Process Re-Engineering, Department of Computer Science, University of Toronto, 1994.

[Yu94b] E. Yu and J. Mylopoulos, ``From E-R to ‘A-R’ -- Modelling Strategic Actor Relationships for Business Process Reengineering," Entity-Relationship Approach (ER'94) -- Business Modelling and Re-Engineering (Proceedings of 13th Int. Conf. on the Entity-Relationship Approach, Manchester, U.K., December 1994), P. Loucopoulos (Ed.), Lecture Notes in Computer Science no. 881, Springer-Verlag. pp. 548-565.

[Yu95] E. Yu, P. Du Bois, E. Dubois, J. Mylopoulos, ``From Organization Models to System Requirements - A `Cooperating Agents' Approach,'' Proc. 3rd Int. Conf. on Cooperative Information Systems (CoopIS-95), Vienna, Austria, pp. 194-204, May 1995.

[Yu97a] E. Yu, ``Towards Modelling and Reasoning Support for Early-Phase Requirements Engineering,'' Proc. IEEE Int. Symp. Requirements Engineering, Annapolis, Maryland, pp. 226-235, January 1997.

[Yu97b] E. Yu, ``Why Agent-Oriented Requirements Engineering," Proc. 3rd Int. Workshop on Requirements Engineering: Foundations of Software Quality REFSQ’97, Barcelona, Catalonia, Spain, June 1997, pp. 171-183.

[Zave97] P. Zave, ``Classification of Research Efforts in Requirements Engineering," ACM Computing Surveys, vol. 29, no. 4, 1997, pp. 315-321.