Requirements taxonomies help to classify and channel the requirements in a project. A very simple taxonomy is the distinction between functional and non-functional requirements. Furthermore, a taxonomy helps to decide if a statement is a requirement at all or just something else (e.g., 'information'). The quality of a taxonomy is important as we do not want to put a statement in the wrong category.In this paper, we argue that we need to take cognitive psychology into account in this task of requirements classification. Cognitive psychology focuses on the abilities and limitations of the human mind. We present a controlled experiment and a replication in which we compare three requirements taxonomies.The participants had to evaluate a set of requirements based on the given taxonomies. The results of these experiments show that there are differences between the taxonomies: Interestingly, the question whether a statement is identified as a requirement or not depends on the taxonomy. These experiments present initial results, we assume that these results are related to phenomena of cognitive psychology.We conclude that the wording should be carefully taken into account in the definition of the categories of a high quality requirements taxonomy.

The formalization of variability models (e.g. feature models) is a prerequisite for the automated analysis of these models. The efficient execution of the analysis operations depends on the selection of well-suited solver implementations. Regarding feature models, on the one hand, the formalization with Boolean expressions enables the use of SAT or BDD solvers. On the other hand, feature models can be transformed into a Constraint-Satisfaction Problem (CSP) in order to use CSP solvers for validation. This paper presents a performance comparison regarding nine contemporary high-performance solvers, three for each base problem structure (BDD, CSP, and SAT). Four operations on 90 feature models are run on each solver. The results will in turn clear the way for new improvements regarding the automatic verification of software product lines, since the efficient execution of analysis operations is essential to such automatic verification approaches.

In product line engineering individual products are derived from the domain artifacts of the product line. The reuse of the domain artifacts is constraint by the product line variability. Since domain artifacts are reused in several products, product line engineering benefits from the verification of domain artifacts. For verifying development artifacts, model checking is a well-established technique in single system development. However, existing model checking approaches do not incorporate the product line variability and are hence of limited use for verifying domain artifacts. In this paper we present an extended model checking approach which takes the product line variability into account when verifying domain artifacts. Our approach is thus able to verify that every permissible product (specified with I/O-automata) which can be derived from the product line fulfills the specified properties (specified with CTL). Moreover, we use two examples to validate the applicability of our approach and report on the preliminary validation results.

The domain requirements specification (DRS) of a product line comprises the common and variable requirements of all products of the product line. Due to the variability defined for a product line, the DRS may contain contradicting requirements. For example, it may contain requirements A and not(A) which can be included in different products. Checking the consistency of DRS in product line engineering is thus not straightforward. Variability information has to be incorporated into the consistency checks to ensure that contradicting requirements do not become part of the same product requirements specification. In this paper, we present a consistency checking technique for dynamic properties of DRS based on model checking techniques. We present a proof of correctness for the technique, sketch our tool environment, and report on the application of the approach to an industrial example.

Today, outsourcing and globally distributed development are common in software engineering industry. This situation raises demands for new forms of stakeholder participation and interaction in requirements elicitation. This poster describes an approach that enables stakeholders to collaboratively participate in requirements elicitation by providing web-based tool support. It combines approaches from research areas such as participatory design, social Web, and semantic collaboration.

A requirements specification for an individual software system should be consistent, i.e. free of contradictions. In product line engineering, the product line requirements specification comprises all the requirements common to all products of the product line as well as the variable requirements used to derive individual products from the product line. The set of requirements (common and all the variable ones) of a product line is typically inconsistent since variable requirements can contradict each other. This is not a problem as long as contradicting requirements are not included in a product derived from the product line. Thus, the set of requirements realized in each individual product has to be consistent. Employing techniques used in single system development to check the consistency of product line requirements will thus produce false positive results, since there can be contradiction in the product line requirements specification In this paper we first provide a concise definition of consistency for product line requirements specifications. Based on this definition, we define a formal framework for checking consistency of product line requirements specifications. Our framework supports consistency checks in the domain engineering process. In contrast to consistency checks in single system development, it tolerates certain types of inconsistencies caused by the variability of prod-uct line requirements.

The explicit definition of variability in software product lines is a key difference between the development of single software systems and software product line engineering. More and more companies maintain several software product lines which focus on different types of products, market segments, and/or domains. Those product lines typically share commonalities and variability. The companies thus face the problem of managing communality and variability across different product lines. In this paper, we identify essential requirements for the documentation of requirements variability across product lines. We propose a meta model for structuring the variability information, sketch a prototypical realisation for managing variability across product lines in DOORS, and illustrate the use of the meta model in a small example. We further report on experiences made with the proposed variability modelling approach.