Configuring Features with Stakeholder Goals Yijun Yu The Open University, UK y.yu@open.ac.uk Alexei Lapouchnian University of Toronto, Canada alexei@cs.toronto.edu Julio Cesar Sampaio do Prado Leite PUC-Rio, Brazil julio@inf.puc-rio.br John Mylopoulos University of Toronto, Canada jm@cs.toronto.edu ABSTRACT Goal models are effective in capturing stakeholder needs at the time when features of the system-to-be have not yet been conceptual- ized. Relating goals to solution-oriented features gives rise to a requirement traceability problem. In this paper, we present a new model-driven extension to an Early Requirements Engineering tool (OpenOME) that generates an initial feature model of the system- to-be from stakeholder goals. Enabled by such generative map- ping, configuration constraints among variability features can be obtained by reasoning about stakeholder goals. Keywords variability, traceability, model-driven, configuration management 1. INTRODUCTION Requirements analysis starts before one can directly describe functionality of the system-to-be. The Early requirements analy- sis phase is distinguished from Late phase in that there we concen- trate on identifying and analysing stakeholder goals through goal- oriented requirements engineering ( [8, 4, 25]) even before func- tional and non-functional requirements of a system are sketched. Goal models, as a result of such elicitation processes, are a natural source of intentional variability [20]. Through generative programming practices, feature models rep- resent system variability and guide configuration of end-products [6]. Integration of requirements variability with feature variability has also been discussed (e.g. [12]). Yet for stakeholders, particularly for end-users, such product-oriented views of features do not an- swer the question of “why do they exist in the system?” [19]. Can one combine the merits of goals and features? Specifically, can we trace system features back to their purposes and configure them in accordance to stakeholder goals? In this paper, we introduce a model-driven approach that attempts to solve the problem described above. Our tool supports the ap- proach by maintaining traceability between goals and features. We first show how an initial feature model is generated for the system- Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. SAC’08 March 16-20, 2008, Fortaleza, Cear´ a, Brazil Copyright 2008 ACM 978-1-59593-753-7/08/0003 ...$5.00. to-be; after connecting it to system-oriented features, we then show how they are configured using goal reasoning algorithms. 2. GOALS AND FEATURES From the very beginning of problem analysis, intentional vari- ability arises from different stakeholder goals [20]. It can lead to variability in system features. In this section, we explore models of stakeholder goals and system features and discuss their connection in terms of variability. 2.1 Goal models and intentional variability A goal model is an AND/OR graph where a goal node is refined into a number of subgoal nodes through either AND- or OR- de- composition links. Every goal has a name. A (hard) goal has a truth value to indicate whether it is satisfied (true) or denied (false). A softgoal has a multi-valued label to indicate the degree of its sat- isfaction: fully satisfied (FS), partially satisfied (PS), fully denied (FD) or partially denied (PD). To reason about softgoals, contribu- tion rules from hard to softgoals such as help (+), hurt (-), make (++), break(--) are introduced: a softgoal is fully (resp. par- tially) satisfied if a satisfied goal makes (resp. helps) it; on the contrary, a softgoal is fully (resp. partially) denied if a satisfied goal breaks (resp. hurts) it [11]. Functional requirements are modeled by (hard) goals. Figure 1 presents our running example: in order to “Schedule Meetings” (a stakeholder goal), one needs to “Collect Timetables” and to “Choose Schedules”. Alternatives in a goal model appear in the form of OR-decompositions, which account for intentional variability. For example, each of the subgoals of “Schedule Meetings” has two alternative solutions, ei- ther done manually “By Person” or automatically “By System”. A system can collect a timetable “From Agents” or directly “From Users”, which can be done by “Sending Requests” and “Receiving Responses”. Quality attributes are modeled as softgoals, such as “Minimal (scheduling) Effort”, “Good Quality Schedule”, “Minimal Distur- bance”, “Accurate (timetable) Constraints”, and so on. They can be further broken down into subcriteria. For example, the “Mini- mal Effort” softgoal can be achieved by minimizing “Collection Ef- fort” and minimizing “Matching Effort”. Similarly, “Good Quality Schedule” is guaranteed by having “Minimal Conflicts” and “Good Participation”. Fulfilment of all hard goals does not necessarily satisfy all qual- ity requirements. To trade off quality requirements by satisfying prioritized ones, the contributions to these softgoals must be anal- ysed to find a subset of hard goals. In our example, “(Collecting Timetable) By Person” is a tedious task for a meeting scheduler,