To: gil.regev@epfl.ch, lieber@ccs.neu.edu
Subject: Re: Information about Goal-Driven Requirements Engineering

Hi Gil:

thank you for your brief summary of the field of
goal-driven requirements engineering (GDRE).

I think it is useful to explore the connection between
GDRE and AOSD.

1. What are the connections between goals and concerns?
   Do the goals become concerns?

2. The goals seem to crosscut the application code.

3. Can the hierarchical organization of goals be translated into
   a hierarchical organization of aspectual components.
   You mentioned the example of decomposing flying
   into takeoff, ascend, descend, land, etc.

Is it ok to post this message on the web?

-- Karl

>From gil.regev@epfl.ch  Fri Nov 16 07:55:52 2001
>From: "Gil Regev" <gil.regev@epfl.ch>
>To: "Karl J. Lieberherr" <lieber@ccs.neu.edu>
>Subject: Information about Goal-Driven Requirements Engineering
>Date: Fri, 16 Nov 2001 13:55:16 +0100
>
>Dear Professor Lieberherr,
>
>It was a pleasure for me to attend your AOP presentation at ABB last
>Tuesday.
>
>As promised, here is some information on goal-driven RE
>
>An brief overview of the goal-driven requirements engineering field taken
>from a recent paper I wrote:
>-----------
>Enterprise information systems are generally considered to be built in order
>to help organizations achieve their goals. Requirements Engineering (RE) is
>the discipline that seeks to produce a detailed description of an
>information system to be built so that it matches the goals of the
>organization for which it was built. As defined by van Lamsweerde & Letier
>[45], RE is, “concerned with the elicitation of high-level goals to be
>achieved by the envisioned system, specifications of software behavior, and
>to their evolution.”
>In the RE community, goals are usually defined as objectives to be achieved
>by the system and its environment [14], [43], [44], [45] or a state of
>affairs that is deemed desirable by stakeholders [19], [38]. Some methods
>distinguish between kinds of goals, such as, private and system goals [14],
>personal, corporate, practical, and false goals [13], business and personal
>goals [32]. 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 [44].
>The KAOS approach [14], [43], [44], [45] 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 [29], [30] is based on the notion of softgoals rather than (hard)
>goals. A softgoal is satisficed rather than achieved [29]. Goal satisficing
>is based on the notion that goals are never totally achieved or not
>achieved. Therefore Mylopoulos et al [29] 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.”
>Goal-Based Requirements Analysis Method (GBRAM) [2] and ESPRIT CREWS [38]
>are less formal than KAOS but focus more on goal definition and the linking
>of goals to stakeholders’ actual needs. Pohl [32] and Kaindl [19] also
>address this seemingly difficult phase of defining initial goals for the
>system to support.
>
>The complete paper is available at:
>http://dscwww.epfl.ch/EN/publications/documents/tr01_043.pdf
>Abstract:
>Current goal-oriented requirements engineering methods focus on the
>definition of optimal requirements that an information system needs to
>support in order to help its stakeholders to achieve their goals. But, the
>lack of systemic reasoning and disregard for questions of interpretation
>lead to insufficient attention given to activities and implicit policies
>affecting the definition of these goals. This results in the optimization of
>the requirements for potentially inadequate goals. Our framework relates
>stakeholders’ goals to the their activities, their policies and their
>interpreted constraints and capabilities. It enables requirements engineers
>to better understand the rationale for goals found through requirements
>elicitation techniques and shows that conflicting goals can be reconciled by
>understanding how they fit in a higher-level activity. This results in the
>formulation of a more adequate set of goals that the information system
>should support in order for the organization and stakeholders to perform
>their activities
>
>
>The most known actors in the field are:
>-----------
>Axel van Lamsweerde (KAOS method):
>http://www.info.ucl.ac.be/people/cvvanlams.html
>
>Eric Yu and John Mylopoulos (NFR framework):
>http://www.cs.toronto.edu/~eric/
>
>Collette Rolland (ESPRIT CREWS project):
>http://panoramix.univ-paris1.fr/CRINFO/users/rolland/coletteEN.html
>
>
>
>A partial list of references from the above paper (only pertaining to
>goal-driven RE):
>-----------
>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.
>
>A. Cockburn, Writing Effective Use Cases. Reading, MA: Addison-Wesley, 2000.
>
>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.
>
>A. Cooper, “Goal-Directed software design,” Dr. Dobbs Journal, Sept. 1996.
>
>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, “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.
>
>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, “Intent specifications: An approach to building human-centered
>specifications,” IEEE Trans. Software Eng., vol. 26, pp. 15–35, Jan. 2000.
>
>J. Mylopoulos, L. Chung and E. Yu, “From Object-Oriented to Goal-Oriented,”
>Communications of the ACM, vol. 42. No. 1, Jan. 1999.
>
>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, “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, “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, “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, “Handling Obstacles in Goal-Oriented
>Requirements Engineering,” IEEE Trans. Software Eng. Special Issue on
>Exception Handling, 2000.
>
>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.
>
>****************************************************************
>Gil Regev
>Institute for computer Communications and Applications
>Swiss Federal Institute of Technology (EPFL-ICA)
>CH-1015 Lausanne, SWITZERLAND
>email: gil.regev@epfl.ch
>Web: http://icawww.epfl.ch
>Phone: +41-21-693-6790
>Fax: +41-21-693-6610
>Mobile Phone: (078) 637-5116
>****************************************************************
>