Goal-Driven Software Product Line Engineering Mohsen Asadi, Ebrahim Bagheri, Dragan Gasevic and Marek Hatala ABSTRACT Feature M odels encapsulate functionalities and quality properties of a product family. The employment of feature models for man- aging variability and commonality of large-scale product families raises an important question: on what basis should the features of a product family be selected for a target software application, which is going to be derived from the product family. Thus, the selection of the most suitable features for a specific application requires the understanding of its stakeholders‘ intentions and also the relationship between their intentions and the available soft- ware features. To address this important issue, we adopt a stan- dard goal-oriented requirements engineering framework, i.e., the i* framework, for identifying stakeholders‘ intentions and propose an approach for explicitly mapping and bridging between the fea- tures of a product family and the goals and objectives of the stakeholders. We propose a novel approach to automatically pre- configure a given feature model based on the objectives of the target product stakeholders. Also, our approach is able to eluci- date the rationale behind the selection of the most important fea- tures of a family for a target application. 1. INTRODUCTION A software product line (SPL) covers the feasible space of all possible software products for a given domain of interest. In other words, it provides the means for capturing the commonalities of all possible products of a given domain and also addresses varia- bility by covering a comprehensive set of dissimilarities between the products. In SPLs, characteristics of a software system mostly including its functionalities are represented by Features [7]. Soft- ware product lines have two main lifecycles, namely domain en- gineering and application engineering. The Domain Engineering lifecycle is concerned with representing all of the features of a set of similar/related software systems as a Feature Model (Section 2.3). Later, the Application Engineering lifecycle involves the eli- citation of the needs, requirements and expectations of the stake- holders to develop a suitable final product based on a given fea- ture model. As the target domain becomes more complex, the structure of the feature model grows to be more complicated with many more features and interactions between its features. Given large-scale software product families (modeled using feature models), the main important question is how and what fea- tures should be selected for the next product that is going to be de- rived from this product family. The process of selecting the ap- propriate features for a product from the feature model is referred to as the Configuration Process. This process requires the consid- eration of many factors such as technical limitations, implementa- tion costs, and stakeholders‘ expectations. M oreover, stakeholders are not always familiar with the structure of feature models and the available feature. In addition, stakeholders are often more comfortable to express their needs in terms of their goals and ob- jectives. Therefore, in order to be able to select the best set of fea- tures based on the stakeholders‘ intentions and expectations, the software practitioners should understand the relations between the available SPL features and stakeholders‘ goals and intentions. It is not easy for the stakeholders to view a feature model and decide which set of features are the ones that they are interested in or which ones are the most beneficial and useful for their purpose. Even more, it is not enough to know what features exist and can be selected, what their interactions are and how they are able to perform their tasks, but it is also important for the stakeholders to know why these features essentially exist, interact and perform in the way that they do. Knowing the ‗why‘ behind the existence of these feature model elements can easily speak to the intentions and objectives (goals) of the stakeholders [10]. A goal is defined as something that the stakeholders hope to achieve as a result of the development of a software product. In other words, it is the high-level objective of the business, organi- zation or system owned, managed, or operated by the stake- holders [1]. Stakeholder goals have been widely captured through goal models within the requirements engineering domain [13][14][15]. Goal models are graph-like representations of the re- lationship between stakeholders‘ goals and their operational plans . They are often used to represent the realistic space of stakehold- ers‘ intentions and objectives [10]. Goal models are fundamental- ly built over three important concepts, namely goals, soft-goals, and plans (aka scenarios or tasks). Goals are objectives related to the functional aspects of the system. In contrast, soft-goals refer to quality attributes of the system. Furthermore, plans are ways to operationalize stakeholders‘ goals (Section 2.2). The idea of employing goal models within the software product family has recently gained focus [12][15][17]. The proposed ap- proaches have mainly attempted to use goal models for representing the variability of software products and transforming goal models into corresponding feature models. Although this idea provides the means for representing the features of a product family in terms of the stakeholders‘ objective, it confines variabil- ity to those defined based on the stakeholders‘ point of view (re- ferred to as essential variability) and ignores technical and infra- structure variability (e.g., variability related to hardware, and op- erating systems). With this issue in mind, the main research ques- tions that we are interested in addressing in this paper are: how are the most suitable features for a target application selected based on stakeholders‘ needs; how do the stakeholders ‘ needs and goals relate with the available features within a feature model and va- riabilities (essential and technical), in other words, what is the re- lationship between the feature space and the intention space; and finally, how can a relationship between the stakeholders goals and the SPL features be formulated to select the best set of features for a target application of interest. In this paper, we investigate how the most suitable set of fea- tures can be selected for the product configuration process by ex- amining the stakeholders‘ needs and requirements gathered through a standard goal-oriented requirements engin eerin g process. The stakeholders‘ intentions and goals are important within the software product line feature selection and prioritiza- tion process as they ensure that: 1) a complete and comprehensive set of initial features from the set of available features is selected (that can be passed into automated feature model configuration processes), which is due to the fact that we can make sure that all stakeholders‘ intentions, objectives and concerns are covered and addressed by the selected features; 2) irrelevant superfluous fea- tures are not included in the selected features, since features that do not correspond with at least one of the stakeholders‘ goals can