In projects with requirements-related troubles the reason is often plainly that too little effort has been spent on requirements engineering (RE). Our varied industrial experience repeatedly showed, however, that even in projects with plenty of RE-budget and -efforts spent numerous problems are often found during acceptance testing that can still be traced back to incomplete or even missing requirements. How is that possible? After observing this repeatedly throughout more than eight years of industrial experience we performed a careful, in-depth qualitative analysis on the underlying root causes that lead us to the hypothesis we present in this paper: requirements engineers often tacitly lay a strong focus on one particular perspective in textbased requirements documentation, while the others typically remain un- or underspecified. Thus, incompleteness arises. In this paper we summarise our observations and present a solution idea that more explicitly considers the different perspectives during the RE process. This can significantly increase requirements completeness, lead to an improved overall balancing of RE efforts and, hence, also lead to higher chances for project success.

The design of the variability of a software product line is crucial to its success and evolution. Meaningful variable features need to be elicited, analyzed, documented and validated when an existing software or reference system evolves into a software product line. These variable features are the main discriminators between individual products and they need to reflect the needs of a large variety of stakeholders adequately. In this paper we present a novel approach, called feature unweaving, that supports the identification and extraction of variable features from a given graphical software requirements model. We have extended our aspect-oriented software product line modeling tool such that it supports feature unweaving: it takes a set of model elements that a domain requirements engineer considers to constitute a variable feature and automatically refactors the model into a semantically equivalent one in which the model elements belonging to this feature are grouped into an aspect. This allows the identification and modeling of variable features in an incremental style. It also substantially reduces both the intellectual and clerical effort required for constructing the variable parts of a software product line requirements model.

Graphical models are omnipresent in the software engineering field, but most current graphical modeling languages do not scale with the increasing size and complexity of today’s systems. The navigation in the diagrams becomes a major problem especially if different aspects of the system are scattered over multiple, only loosely coupled diagrams. In this paper we present the hierarchical navigation capabilities of the Adora modeling tool. The user of this tool can freely control the level of detail in different parts of the model to reduce the size and complexity of the diagrams being displayed. Our fisheye visualization technique makes it possible to integrate all modeling aspects (structure, data, behavior, etc.) in one coherent model while keeping the size and complexity of the diagrams within reasonable limits.