Search

Software Product Line Engineering (SPLE) is a promising paradigm for reusing knowledge and artifacts among similar software products. However, SPLE methods and techniques require a high up-front investment and hence are profitable if several similar software products are developed. Thus in practice adoption of SPLE commonly takes a bottom-up approach, in which analyzing the commonality and variability of existing products and transforming them into reusable ones (termed core assets) are needed. These time-consuming and error-prone tasks call for automation. The literature partially deals with solutions for early software development stages, mainly in the form of variability analysis. We aim for further creation of core requirements—reusable requirements that can be adapted for different software products. To this end, we introduce an automated extractive method, named CoreReq, to generate core requirements from product requirements written in a natural language. The approach clusters similar requirements, captures variable parts utilizing natural language processing techniques, and generates core requirements following an ontological variability framework. Focusing on cloning scenarios, we evaluated CoreReq through examples and a controlled experiment. Based on the results, we claim that core requirements generation with CoreReq is feasible and usable for specifying requirements of new similar products in cloning scenarios.

Software reuse can be defined as the process of creating software products from the existing ones rather than developing software from scratch. Thus, software reuse is normally proposed to increase software productivity and quality and leads to economic benefits. In this sense, the reuse of software requirements has received important attention because it provides a solid support to develop quality software through obtaining and reusing quality software requirements [i.e., software product line (SPL) approach used in large-sized software enterprises]. However, the small-sized enterprises--which represent up to 85 % of all software organizations in many countries around the world--cannot implement a SPL approach because it does not fit with the context, properties, and complexity of their software projects. Moreover, the software engineering community has not adequately explored a more proper approach in the context of small-sized software enterprises. The use of a software requirements catalog could be this proper approach. In this context, the aim of this paper was to introduce the requirements reuse model for software requirements catalog (RRMSRC). Also, a set of guidelines to perform the main activities defined for reusing functional requirements within small-sized software enterprises is provided. As evidence of its feasibility, RRMSRC has been used in an industrial context, and the obtained results and learned lessons are summarized.

In current software systems with highly volatile requirements, traceability plays a key role to maintain the consistency between requirements and code. Traceability between artifacts involved in the development of software product line (SPL) is still more critical because it is necessary to guarantee that the selection of variants that realize the different SPL products meet the requirements. Current SPL traceability mechanisms trace from variability in features to variations in the configuration of product-line architecture (PLA) in terms of adding and removing components. However, it is not always possible to materialize the variable features of a SPL through adding or removing components, since sometimes they are materialized inside components, i.e., in part of their functionality: a class, a service, and/or an interface. Additionally, variations that happen inside components may crosscut several components of architecture. These kinds of variations are still challenging and their traceability is not currently well supported. Therefore, it is not possible to guarantee that those SPL products with these kinds of variations meet the requirements. This paper presents a solution for tracing variability from features to PLA by taking these kinds of variations into account. This solution is based on models and traceability between models in order to automate SPL configuration by selecting the variants and realizing the product application. The FPLA modeling framework supports this solution which has been deployed in a software factory. Validation has consisted in putting the solution into practice to develop a product line of power metering management applications for smart grids.

In theory, software product line engineering has reached a mature state. In practice though, implementing a variability management approach remains a tough case-by-case challenge for any organization. To tame the complexity of this undertaking, it is inevitable to handle variability from multiple perspectives and to manage variability consistently across artifacts, tools, and workflows. Especially, a solid understanding and management of the requirements to be met by the products is an inevitable prerequisite. In this article, we share experiences from the ongoing incremental adoption of explicit variability management at TRW Automotive's department for automotive slip control systems--located in Koblenz, Germany. On the technical side, the three key drivers of this adoption effort are (a) domain modeling and scoping, (b) handling of variability in requirements and (c) tighter integration of software engineering focus areas (e.g., domain modeling, requirements engineering, architectural modeling) to make use of variability-related data. In addition to implementation challenges with using and integrating concrete third-party tools, social and workflow-related issues are covered as well. The lessons learned are presented, discussed, and thoroughly compared with the state of the art in research.

Requirements engineering (RE) offers the means to discover, model, and manage the requirements of the products that comprise a product line, while software product line engineering (SPLE) offers the means of realizing the products' requirements from a common base of software assets. In practice, however, RE and SPLE have proven to be less complementary than they should. While some RE techniques, particularly goal modeling, support the exploration of alternative solutions, the appropriate solution is typically conditional on context and a large product line may have many product-defining contexts. Thus, scalability and traceability through into product line features are key challenges for RE. Feature modeling, by contrast, has been widely accepted as a way of modeling commonality and variability of products of a product line that may be very complex. In this paper, we propose a goal-driven feature modeling approach that separates a feature space in terms of problem space and solution space features, and establish explicit mappings between them. This approach contributes to reducing the inherent complexity of a mixed-view feature model, deriving key engineering drivers for developing core assets of a product line, and facilitating the quality-based product configuration.

Many modern software-intensive systems consist of multiple components interacting together to deliver the intended functionality. Often, these systems come in many variants (products) and are managed together as a software product line. This variability is the source of additional complexity which can cause inconsistencies and offset the economies of scale promised by product line engineering. Engineers thus need intuitive, yet precise means for specifying requirements and require tools for automatically detecting inconsistencies within these requirements. In recent work, we proposed a technique for the scenario-based specification of interactions in product lines by a combination of Modal Sequence Diagrams and Feature Diagrams. Furthermore, we elaborated an efficient consistency-checking technique based on a dedicated model-checking approach especially tailored for product lines. In this paper, we report on further evaluations that underline significant performance benefits of our approach. We describe further optimizations and detail on how we encode the consistency-checking problem for a model-checker.

Software product line engineering practices offer desirable characteristics such as rapid product development, reduced time-to-market, and more affordable development costs as a result of systematic representation of the variabilities of a domain of discourse that leads to methodical reuse of software assets. The development lifecycle of a product line consists of two main phases: domain engineering, which deals with the understanding and formally modeling of the target domain, and application engineering that is concerned with the configuration of a product line into one concrete product based on the preferences and requirements of the stakeholders. The work presented in this paper focuses on the application engineering phase and builds both the theoretical and technological tools to assist the stakeholders in (a) understanding the complex interactions of the features of a product line; (b) eliciting the utility of each feature for the stakeholders and hence exposing the stakeholders' otherwise implicit preferences in a way that they can more easily make decisions; and (c) dynamically building a decision model through interaction with the stakeholders and by considering the structural characteristics of software product line feature models, which will guide the stakeholders through the product configuration process. Initial exploratory empirical experiments that we have performed show that our proposed approach for helping stakeholders understand their feature preferences and its associated staged feature model configuration process is able to positively impact the quality of the end results of the application engineering process within the context of the limited number of participants. In addition, it has been observed that the offered tooling support is able to ease the staged feature model configuration process.

Software Product Line Engineering (SPLE) can reduce software development costs, reduce time to market and improve product quality. A software product line is a set of software products sharing a set of common features but containing variation points. Successful SPLE requires making selection decisions at variation points effectively and efficiently. A significant challenge is how to identify, represent and manage the inter-dependency of selection decisions for requirements. We developed the concept of a meta-model for requirement decision models to bring formalism and consistency to the structure and to model inter-dependencies between requirement selection decisions. Here we present a meta-model for requirement selection decisions that includes inter-dependencies and we use a mobile phone worked example to illustrate our approach. To support our method, we developed two separate tools, V-Define (for domain decision model construction) and V-Resolve (for new product derivation). Finally the results of a metal processing product line case study using the tools are described.

Many attempts have been made to increase the productivity and quality of software products based on software reuse. Software product line practice is one such approach, one that focuses on developing a family of products which have a majority of features in common. Hence, there are numerous requirements that are common across the family, but others are unique to individual products. Traditional requirements engineering methods were conceived to deal with single product requirements and are usually not flexible enough to address the needs arising from reusing requirements for a family of products. There is also the additional burden of correctly identifying and engineering both product-line-wide requirements and product-specific requirements as well as evolving them. Therefore, in this special issue, we want to highlight the importance and the role of requirements engineering for product line development as well as to provide insights into the state of the art in the field.

Delivering great consumer experiences in competitive market conditions requires software vendors to move away from traditional modes of thinking to an outside-in perspective, one that shifts their business to becoming consumer-centric. Requirements engineers operating in these conditions thus need new means to both capture real preferences of consumers and then relate them to requirements for software customized in different ways to fit anyone. Additionally, because system development models require inputs that are more concrete than abstract, the indistinct values of consumers need to be classified and formalized. To address this challenge, this study aims to establish a conceptual link between preferences of consumers and system requirements, using software product line (SPL) as a means for systematically accommodating the variations within the preferences. The novelty of this study is a conceptual model of consumer preference, which integrates generic value frameworks from both psychology and marketing, and a method for its transformation to requirements for SPL using a goal-oriented RE framework as the mediator. The presented artifacts are grounded in an empirical study related to the development of a system for online education.