Survey of Non-Functional Requirements Modeling and Verification of Software Product Lines

Fatima Zahra Hammani IMS Team, SIME Laboratory

ENSIAS, Mohammed V Souissi University Rabat, Morocco

Fz.hammani@gmail.com

Abstract—Undoubtedly, Non-Functional Requirements (NFR) such as security, performance and reliability are critical to software systems as there is a growing demand on a higher quality of software. Simultaneously, the increasing pressure to develop software in less time and at lower costs drives software industry towards the promising paradigm of Software Product Line (SPL). However, different approaches have been advanced for modeling NFR of the traditional individual products and few approaches focused on a family of products. On the other hand, as a product line contains several products, it is impracticable and not feasible to verify NFR for each possible product. Therefore, there is a major need for verification approaches specific to product lines. In this paper, we present and analyze the main NFR modeling and verification approaches of SPL.

Keywords—Feature; NFR; Reuse; SPL.

I. INTRODUCTION Today software engineers are faced with a demand for

complex and powerful software systems which must be developed in short time. To solve this problem, software reuse was emerging as a principal key to a successful software development because of its potential to reduce the time to market, increase quality and reduce costs [1], as it consists in creating and in assembling systems with existing components.

Software Product Line Engineering (SPLE) is an expanding approach which aims at developing a set of software systems that share common features and satisfy the requirements of a specific domain [2]. Product Lines are gaining importance in the software development field as they reduce development time, effort, cost and complexity and increase quality of products [3].

Non-Functional Requirements (NFR) such as security, reliability, and performance are very crucial for SPL, and its omission can lead to a huge economic loss or even endanger human life. Hence, it is quite essential to consider NFR at early phases of domain engineering life cycles.

A successful implementation of a product line largely depends on how well domain requirements and their variability are specified and managed [4]. Furthermore, the effectiveness of a SPL approach directly depends on how features are modeled. But despite the importance of Non-Functional Requirements, developers usually pay attention to functional requirements (FR) and overlook NFR.

On the other hand, verifying a design model can interestingly reduce the risk of developing a low quality product [5]. But, in contrast to conventional software development, SPL often contains an exponential number of products, so it’s not feasible to verify NFR for each product, that’s way there is a major need for verification approaches specific to product lines. In this view, this paper is a survey of two particular scopes of SPL: modeling and verification of NFR during design phase of domain engineering.

In spite that NFR have been widely studied by the researchers, our literature review shows that most research efforts have focused on some NFR types (like reliability and performance) and don’t take into account the other types. Besides that the most of proposed approaches in the literature are mostly limited tools. So, the current surveys indicate that we are far from developing acceptable complex and safety-critical systems.

The rest of this paper is organized as follows: section 2 presents the background and the context of our work; it presents SPL and NFR then highlights the main challenges of dealing with NFR in SPL. Section 3 is a survey of the main approaches proposed in the literature in order to handle the challenge of modeling NFR in SPL. In section 4, we analyze current verification approaches of NFR in domain design. In section 5, a comparative study between these works identifies several weaknesses, and then we dress the main further works. Finally, section 6 concludes the paper.

II. BACKGROUND AND MOTIVATION In this section, we recall basic concepts and definitions that

will be used throughout the rest of the paper and we highlight the motivations and challenges of our work problematic.

A. Software Product Line Software Product Line (SPL) is a set of software intensive

systems that share common features satisfying the specific needs of a particular market segment or mission [6]. Such an approach allows rapidly developing a new software product by exploiting a set of reusable assets, known as core assets [7].

A SPL life cycle encompasses two processes, domain engineering and application engineering [8]: The aim of domain engineering is the development of assets which will be used in the product line, and it’s composed of four main

978-1-4799-2393-9/14/$31.00 ©2014 IEEE

activities: (i) domain requirements engineering, (ii) domain design, (iii) domain realization, and (iv) domain testing; whereas the application engineering concerns the construction of final products with specific requirements [9], the application engineering encompasses four far phases: (i) application requirements engineering, (ii) application design, (iii) application realization, and (iv) application testing. Software Product Lines are gaining importance in the software development field [8] as they reduce development costs and time to market and they enhance quality, etc.

Several notations exist for modeling the attributes of a family of products and capturing commonality and variability, of which the best-known is feature modeling [10]; feature model represents all the possible products of a SPL in terms of features and the relationships among them [11]. A feature is an aspect or a property of a product line, and it is either [12]: mandatory (if the father feature is selected, the child feature must be selected as well and vice versa), full-mandatory (it is a mandatory feature, whose predecessors in the feature tree are all mandatory), optional (if father feature is selected, then child feature can be selected or not. However, if child feature is selected, then feature father must also be selected), alternative (if father feature is selected, only one option can be chosen from a set of features) and or (if father feature is selected, one or more child feature may be selected).

B. Non-Functional Requirements Requirements can generally be categorized into functional

and Non-Functional requirements (NFR). If Functional Requirements sketch out the functionality that the system has to be performed, Non-Functional Requirements (also called Extra-Functional Requirements) compel the restrictions on these functionalities (such as performance, security, reliability, etc.) [13]. The notion of NFR is flawed, but when analyzing the definitions proposed in literature, we can conclude that Non-functional Requirement is a constraint, property, and characteristic that describes not what the software will do, but how the software will do it.

NFR play more and more important role in software system success and its omission can lead to a huge economic loss or even endanger human life. The research proposed by Vara et al. [14] aims to gain new insights into the importance of NFR in industry, the results of the study provide novel empirical evidence about the perceived importance of NFR types in industry and how it may vary. Also, we can find A detailed study on NFR impact on project success or failure in [15] [16].

In [17], Ameller et al., present a detailed empirical study, they address questions such as: who decides the NFR, what types of NFRs matter to architects, how are NFR documented, and how are NFR validated. But they only study conventional systems development and they overlook SPL. It’s worth to note that handling NFR is difficult because of several factors that we outline below:

Diversity of NFR: There are various types of NFR, and every NFR can be decomposed into several sub-NFR. On the other hand, NFR can be broadly classified as soft (qualitative) and hard (quantitative) constraints.

Subjective nature of NFR: There is a lack of consensus about the meaning of NFR. Also there isn’t an exhaustive list of all the NFR attributes [18].

Scope ambiguity between NFR and FR: often, the specification of NFR is scattered and tangled with functional artifacts they affect.

Conflict between NFR: Conflicting interplays among NFR where one NFR impacts negatively or positively on other, conflicts resolution among NFR is a problem [19].

C. Problem Statement In current Software Product Line Engineering (SPLE), we

can identify some critical problems in design domain:

NFR are not properly modeled: despite the importance that NFR have in SPL, modeling approaches dealing with SPL usually focus on FR and neglect NFR.

Luck of NFR verification approaches in design domain: since NFR managing is very more complex than FR (because of NFR diversity, conflict between NFR, some NFR are quantitative others are qualitative, etc). So, introducing a verification approach of NFR is a key challenge in SPLE.

The next section describes and discusses the main researches addressing the problem of NFR modeling in SPL.

III. KNOWLEDGE BASE ON NFR MODELING IN SPL Developing high quality software depends on elaborating

high quality models and capturing a precise specification. Thus, in this section, we will analyze the main existing researches related to NFR modeling in SPL.

A. Feature-Based Approaches

There are several notations to design feature models like FODA (Feature Oriented Domain Analysis) [2] and FORM (Feature Oriented Reuse Method) [20], but they deal only with characteristics related to the functionality offered by a SPL (functional features); thus, there exists no solid proposal for dealing with NFR. To bridge this gap, several researchers propose various extensions of features models in order to support NFR:

For instance, Benavides et al., extend existing feature models to deal with Non–Functional features [21], every feature may have one or more attribute relations, for example, the price and development time taking a range of values in both a discrete or continuous domain (integer or real for example). Thus, it would be possible to decorate the graphical feature model with this kind of information. Fig. 1 illustrates an example of a feature model with Non–Functional features. Then, they present a mapping to transform an extended feature model into a Constraint Satisfaction Problem (CSP) in order to formalize extended feature models using constraint programming. However, it requires a hierarchical modeling of quality attributes that restricts the possible set of quality dependencies that can be modeled. Later, in [22], they present FAMA (FeAture Model Analyzer) which is a framework for the automated analysis of feature models integrating three of the most promising logic representations proposed in the area of

the automated analysis of feature models: CSP (Constraint Satisfaction Problem), SAT (Boolean Satisfiability Problem )and BDD (Binary Decision Diagram), but more solvers can be added if it’s needed.

Fig. 1 Example of an Extended Feature Model

In [23], Zhang et al., adapt NFR framework [24] to identify

quality attributes for a SPL and extend current feature models to represent the identified quality attributes. They develop also an evaluation method to check the consistency of domain experts’ judgments to ensure the effectiveness of their approach.

B. Aspect-Based Approaches

Feature modeling is widely used for SPL analysis [25]. However, it’s important for Product Line Architecture (PLA) to be flexible behind evolutionary changes. Furthermore, in a software product family, one crosscutting concern may crosscut multiple features. In these cases, an advanced modeling structure is needed to isolate crosscutting concerns from technical concerns. In this scope, different current researches are based on Aspect Oriented Programming (AOP) which provides a promising support for modeling and separating crosscutting concerns from business functionalities:

Zhang et al., [26] classify the features according to the role of aspects and propose a process to map features on to architectural components in aspect-oriented product line engineering. According to this approach, features can be classified according to variability type (common or variable) or to their impact on other features (crosscutting or base). Then, depending on the feature classification, it can be mapped to either a core (i.e. mandatory) or a variable component. We

agree to consider that aspects have two roles: modularize crosscutting features and manage variability.

Tan et al., propose an aspect-oriented framework which is able to improve the modeling of interrelationships between design factors and representation of the variabilities in product family [11]. To include crosscutting concerns in feature models, they divide features into three categories: concrete feature, aspectual feature and aspectual concern.

In the same scope, Tizzei et al., [25] propose a feature-oriented solution with aspects for product line architecture design aiming at improving product line architecture evolvability by adopting aspect-oriented techniques. The advantage of this approach is refining the feature model before deriving architectural components.

C. UML-Based Approaches

UML is a famous language for modeling single systems, and it would be beneficial to use it for modeling SPL. Since several extensions was proposed:

Instead of annotating from scratch each UML model of each product, Tawhid et al., [27] propose to annotate the SPL model with generic performance annotations, and to provide binding information when deriving the annotated model of a desired product from the generic SPL model.

In [28], Bartholdt et al., present IQSPLE (Integrated Quality Software Product Line Engineering), an integrated tool-supported modeling approach that evaluates both qualitative and quantitative quality attributes without imposing hierarchical structural constraints.

We can notice that all the proposals cited above use traditional modeling approaches that don’t provide power of expression. Thus, Mazo et al. propose to specify PL as a constraint program CP instead of a feature model or another kind of PL formalism, in order to carry out two important qualities of CP: expressiveness and direct automation [29]. In [30], Sawyer et al., combine goal modeling techniques with constraint programming to provide the analyst with a means to identify the system variants best suited to the various environmental contexts that a system might encounter.

TABLE I. COMPARISON AMONG NFR MODELING IN SPL

Approach Research work

Development style NFR Tool Support

Feat

ure [21] Not specified Quantitative &

qualitative FAMA framework.

[23] Not specified All NFR types No

Aspe

ct [26] Not specified All NFR Types No

[11] Not specified All NFR Types No

[25] Component Based Software Development All NFR types No

UM

L [27] OOP Quantitative NFR Yes

[28] OOP Quantitative & qualitative IQSPLE

Approach Research work

Development style NFR Tool Support

CP [29] OOP All NFR types Environment composed of

VariaMos and GNU Prolog [30] Not specified All NFR types VariaMos tool adapted

Besides modeling NFR, stockholders must be able to evaluate their models. So, in the next section, we present the main recent approaches proposed in literature in order to verify NFR in SPLE domain engineering.

IV. KNOWLEDGE BASE ON NFR VERIFICATION IN SPL Verifying a design model in the early stages of

development can interestingly reduce the risk of developing a low quality product [5]. In this scope, several researchers have proposed interesting approaches in the last decades. In the following we analyze the existing NFR verification approaches in SPL:

Siegmund et al., propose an approach to predict a product’s NFR, based on the product’s feature selection. To this end, they generate and measure a small set of products, and by comparing the measurements, they approximate each feature’s non-functional properties. By aggregating the approximations of selected features, they predict the product’s properties [31]. Later, in [32] they conduct controlled experiments and evaluated prediction accuracy for footprint and main-memory consumption. But, in principle, their approach is applicable for all quantifiable NFR.

Formal verification approaches like model checking are powerful methods for software verification. However, model checking of SPL is more difficult than for a single product, since the SPL often contains an exponential number of products. Thus, Ghezzi and Molzam describe an approach to efficiently verify NFR of all configurations of a SPL with probabilistic model-checking [5], to achieve this aim, they model the systems behavior with sequence diagrams enriched with variation points and annotated with quality parameters. But this approach presents some limitations: each feature must be restricted to one module, they model the system’s behavior with sequence diagrams where fragments can be annotated to be active only in certain products, and they don’t consider that multiple scenarios can be active concurrently.

In [33] and [34], Classen et al., extend transition systems with features in order to describe the combined behavior of an

entire system family. Then, they define and implement a model checking technique that allows verifying such transition systems against temporal properties. But the two approaches proposed by Ghezzi et al., et Classen et al., don’t support quantitative evaluation of NFR, for which probabilistic model checkers are needed. In [35], Greenyer et al propose a scenario-based approach for a precise specification of product lines. They present a novel technique for efficiently consistency checking the specification of all the variants in a product. Their checking procedure is founded on Featured Transition System (FTS) which is a recent formalism for modeling the behavior of product lines; it is a usual transition system where transitions are annotated with constraints over a set of features from an attached feature model. Although, the solutions proposed by Ghazi, Classen et Greenyer consist of building a single model checking representing all SPL products, thing that can present restrictions over SPL expressiveness (such as restrictions over variability or Software Product Architecture).

To solve problems cited before, Nunes et al., [36] present an analytical study of the process of conversion of a parametric model for an arithmetic formula and an approach to deal with the expressiveness issue emphasizing decisions that impact the size of the final formula and consequently the cost of further evaluation. This work deals with the process of generating an arithmetic formula corresponding to the reliability of SPL, through parametric model checking using the PARAM tool. A feature model is considered as the input to this approach and the output is a reliability formula for the SPL in which variables represent features of the feature model. Through this study, they are able to develop new parametric modeling techniques to handle variability efficiently with less restriction to expressiveness. To verify the variability model and its configurations, Alférez et al., as a continuation of the proposal of Mazo et al., [29] presented in the previous sub-section, incorporate a constraint logic programming [37].

TABLE II. A COMPARISON AMONG RESEARCH WORKS ON NFR VERIFICATION ON SPL

Research work Development style NFR Tool

Support Based on

[32] Not specified Footprint, Memory consumption No Feature model

[5] OOP Reliability, Energy Consumption, It can be used for other NFR such as performance No Sequence diagram

[34] Not specified Temporal properties No Featured Transition Systems (FTS)

[35] OOP Consistency No Combination of MSDs, FM and FTS

[36] Not specified Reliability No Feature model

Research work Development style NFR Tool

Support Based on

[37] OOP All NFR types Yes Constraint Logic

V. OUTSTANDING ISSUES In section III, we have addressed several research efforts

addressing the challenge of NFR modeling in domain design phase. The first limitation is that almost of these approaches describe mechanisms for modeling NFR in SPL, but there is no tooling support for these approaches. The second limitation is that we can’t identify the relationships between conflicting NFR. Moreover, every NFR can be decomposed into several sub-NFR, thing that isn’t taken into account by researchers. It’s true that the effectiveness of a SPL approach directly depends on how features are modeled. However, Evaluating and verifying a design model in the early stages of development can interestingly reduce the risk of developing low quality products. In this scope, several researchers have attempted to shed light on this issue and many efforts have been made towards the verification of NFR; Table II shows a comparison among several research works in the area of SPLE. At first sight, we can observe that researchers have focused on some quantitative NFR (such as energy consumption, memory consumption) and they neglected the other types. Moreover,

some approaches are not formal and don’t have rigorous analysis mechanisms to verify NFR, and several proposed approaches are not supported by tooling environment.

Our ongoing works focus mainly on proposing practical approach to model and verify NFR in SPL. It is interesting to note that the result of frequency analysis indicates that performance, reliability, usability, security, and maintainability are the top five of the most frequent types of NFRs required by consumers [15]. So, due to the wide variety of NFR, the first alternative of our approach focuses only on this five NFR types. First and foremost, we will propose a detailed NFR checklist with different information about the five famous NFR (performance, reliability, usability, security and maintainability) as well as a detailed decomposition into sub-NFR. Fig. 2 shows a first alternative of the proposed checklist, but a detailed decomposition is recommended. However, in several situations, a conflict may arise between requirements defined over NFR that have an opposite behavior, to bridge this gap, we are thinking about elaborating a systematic and formal mechanism in order to detect and resolve these conflicts.

Fig. 2: Non-Functional Requirements Tree (depth = 2)

Then we will propose use case diagram extended with generic profile in order to support NFR Analysis in domain requirements engineering. To model NFR during domain design, we will propose a feature model extended with crosscutting aspect as well as UML diagrams annotated with NFR information. As the most of NFR are quantitative in nature, they need to be specified in a parametric way to take different influencing factors and to facilitate the prediction and verification of NFR. As the basic principle of our approach is to promote reusability, modularity and flexibility we must base on Aspect Oriented Paradigm (AOP). A substantial amount of work needs to be done to further formalize this engineering process. In addition, there is also a need to investigate how create suitable tools in order to be able to use this approach.

VI. CONCLUSION AND OUTLOOK Software Product Line is a recent approach that gaining

importance in the software development field as it increases

reusability and product quality, and they decrease development coast and time to market. On the other hand, NFR are not building blocks added to an application at the end of the life cycle, it is necessary to take into account this concern from the requirement to the testing phase. In this view, this paper shows that modeling and verifying NFR in design level of Domain engineering may reduce the risk of developing a low quality product; so the central problem of SPL is how to deal with the challenge of integrating NFR in domain engineering. However, very few approaches are handling NFR in domain design phase; also these approaches are limited tools and have several weaknesses.

This research work presents the current approaches proposed in the literature in order to model and verify NFR in SPL. However, a comparative study between these works identifies several weaknesses. To overcome these limitations, the main aim of our ongoing work is proposing a new approach for modeling and verifying performance, reliability, usability, security, and maintainability as well as their decomposition

into sub-NFR in domain design with a suitable tooling environment.

REFERENCES

[1] K. M. Kranthi, B. M. Konda, K. T. Reddy, B. R. Kiran, and A. Vindhya, “A Systematic Mapping Study on Value of Reuse,” International Journal of Computer Applications, vol. 34, 2011.

[2] K. C. Kang, S. G. Cohen, J. A. Hess, W. E. Novak, and A. S. Peterson, “Feature-oriented domain analysis (FODA) feasibility study,” (No. CMU/SEI-90-TR-21). CARNEGIE-MELLON UNIV PITTSBURGH PA SOFTWARE ENGINEERING INST, 1990.

[3] M. Voelter, and I. Groher, “Product line implementation using aspect-oriented and model-driven software development,” In Software Product Line Conference, 2007. SPLC 2007. 11th International, pp. 233-242, IEEE, 2007.

[4] N. Abbas, J. Andersson, and D. Weyns, “Modeling variability in product lines using domain quality attribute scenarios,” In Proceedings of the WICSA/ECSA 2012 Companion Volume, pp. 135-142, ACM, 2012.

[5] C. Ghezzi, and A. M. Sharifloo, “Verifying non-functional properties of software product lines: Towards an efficient approach using parametric model checking,” In Software Product Line Conference (SPLC), 2011 15th International, pp. 170-174, IEEE, 2011.

[6] P. Clements and L. Northrop, “Software Product Lines: Practices and Patterns,” Addison-Wesley Longman Publishing Co., Inc., 2001.

[7] M. Noorian, E. Bagheri, and W. Du, “Non-functional Properties in Software Product Lines: A Taxonomy for Classification,” In SEKE, pp. 663-667, 2012.

[8] G. Böckle, and F. Van Der Linden, “Software product line engineering,” vol. 10, pp. 3-540, K. Pohl (Ed.). Heidelberg: Springer, 2005.

[9] M. Rhanoui and B. El Asri, “A Contractual Specification of Functional and Non-Functional Requirements of Domain-Specific Components,” International Journal of Computer Science Issues, vol. 11, 2014.

[10] D. Benavides, S. Segura, and A. Ruiz-Cortés, “Automated analysis of feature models 20 years later: A literature review,” Information Systems, vol. 35, no 6, pp. 615-636, 2010.

[11] L. Tan, Y. Lin, and H. Ye, “An Aspect-Oriented Framework for Software Product Line Engineering,” 2013.

[12] R. Mazo. “A Generic Approach for Automated Verification of Product Line Models,” Doctoral dissertation, Université Panthéon-Sorbonne-Paris I, 2011.

[13] S. Ullah, M. Iqbal, and A. M. Khan, A. M. “A survey on issues in non-functional requirements elicitation,” In Computer Networks and Information Technology (ICCNIT), 2011 International Conference on, pp. 333-340, IEEE, 2011.

[14] J. L. de la Vara, K. Wnuk, R. Berntsson-Svensson, J. Sánchez, and B. Regnell, “An Empirical Study on the Importance of Quality Requirements in Industry,” In SEKE, pp. 438-443, 2011.

[15] D. Mairiza, D. Zowghi, and N. Nurmuliani, “An investigation into the notion of non-functional requirements,” Proceedings of the 2010 ACM Symposium on Applied Computing, pp. 311-317. ACM, 2010.

[16] E. R. Poort, N. Martens, I. Van de Weerd, and H. Van Vliet, “How architects see non-functional requirements: beware of modifiability,” In Requirements Engineering: Foundation for Software Quality, pp. 37-51. Springer Berlin Heidelberg, 2012.

[17] D. Ameller, C. Ayala, J. Cabot, and X. Franch, “How do software architects consider non-functional requirements: An exploratory study,” In Requirements Engineering Conference (RE), 20th IEEE International, pp. 41-50, IEEE, 2012.

[18] M. Glinz, “On non-functional requirements,” In Requirements Engineering Conference, 2007. RE'07. 15th IEEE International, pp. 21-26, IEEE, 2007.

[19] P. Singh, and A. K. Tripathi, “Exploring Problems and Solutions in estimating Testing Effort for Non Functional Requirement,” International Journal of Computers & Technology, vol. 3, no 2b, pp. 284-290, 2012.

[20] K. C. Kang, S. Kim, J. Lee, K. Kim, E. Shin, and M Huh, “FORM: A feature-; oriented reuse method with domain-; specific reference architectures,” Annals of Software Engineering, vol. 5, no 1, pp. 143-168, 1998.

[21] D. Benavides, P. Trinidad, and A. Ruiz-Cortés, “Automated reasoning on feature models,” In Advanced Information Systems Engineering, pp. 491-503, Springer Berlin Heidelberg, 2005.

[22] D. Benavides, S. Segura, P. Trinidad, and A. R. Cortés, “FAMA: Tooling a Framework for the Automated Analysis of Feature Models,” VaMoS. pp. 01, 2007.

[23] G. Zhang, H. Ye, and Y. Lin, “Modelling Quality Attributes in Feature Models in Software Product Line Engineering,” In ICSOFT (2), pp. 249-254, 2011.

[24] L. Chung, B. Nixon, E. Yu, and J. Mylopoulos, “Non-Functional Requirements,” in Software Engineering. Kluwer Academic, 2000.

[25] L. P. Tizzei, C. M. Rubira, and J. A. Lee, “Feature-oriented Solution with Aspects for Component-based Software Product Line Architecting,” 2012.

[26] J. Zhang, X. Cai, and G. Liu, “Mapping features to architectural components in aspect-oriented software product lines,” In Computer Science and Software Engineering, 2008 International Conference on, vol. 2, pp. 94-97, IEEE, 2008.

[27] R. Tawhid, and D. C. Petriu, “Towards automatic derivation of a product performance model from a UML software product line model,” In Proceedings of the 7th international workshop on Software and performance, pp. 91-102, ACM, 2008.

[28] J. Bartholdt, R. Oberhauser, A. Rytina, and M. Medak, “Integrating Quality Modeling in Software Product Lines,” International Journal On Advances in Software, vol. 3, no 1 and 2, pp. 161-174, 2010.

[29] R. Mazo, C. Salinesi, O. Djebbi, D. Diaz, and A. Lora-Michiels, “Constraints: The heart of domain and application engineering in the product lines engineering strategy,” International Journal of Information System Modeling and Design IJISMD, vol. 3, no 2, 2012.

[30] P. Sawyer, R. Mazo, D. Diaz, C. Salinesi, and D. Hughes, “Constraint programming as a means to manage configurations in self-adaptive systems,” Special Issue in IEEE Computer Dynamic Software Product Lines, pp. 1-12, 2012.

[31] N. Siegmund, M. Rosenmuller, C. Kastner, P. G. Giarrusso, S. Apel, and S. S. Kolesnikov, “Scalable prediction of non-functional properties in software product lines,” In Software Product Line Conference (SPLC), 2011 15th International, pp. 160-169, IEEE, 2011.

[32] N. Siegmund, M. Rosenmüller, C. Kästner, P. G. Giarrusso, S. Apel, and S. S. Kolesnikov, “Scalable prediction of non-functional properties in software product lines: Footprint and memory consumption,” Information and Software Technology, vol. 55, no 3, pp. 491-507, 2013.

[33] A. Classen, P. Heymans, P. Y. Schobbens, A. Legay, and J. F. Raskin. “Model checking lots of systems: efficient verification of temporal properties in software product lines,” In Proceedings of the 32nd ACM/IEEE International Conference on Software Engineering-Volume 1, pp. 335-344, ACM, 2010.

[34] A. Classen, P. Heymans, P. Y. Schobbens, and A. Legay, “Symbolic model checking of software product lines,” In Proceedings of the 33rd International Conference on Software Engineering, pp. 321-330, ACM, 2011.

[35] J. Greenyer, A. M. Sharifloo, M. Cordy, and P. Heymans, “Efficient consistency checking of scenario-based product-line specifications,” In Requirements Engineering Conference (RE), 2012 20th IEEE International, pp. 161-170, IEEE, 2012.

[36] V. Nunes, P. Fernandes, V. Alves, and G. Rodrigues, “Variability management of reliability models in software product lines: An expressiveness and scalability analysis,” In Software Components Architectures and Reuse (SBCARS), 2012 Sixth Brazilian Symposium on, pp. 51-60, IEEE, 2012.

[37] G. H. Alférez, V. Pelechano, R. Mazo, C. Salinesi, and D. Diaz, “Dynamic adaptation of service compositions with variability models,” Journal of Systems and Software, 2013.