Contributions published at Requirements Engineering (Martin Glinz)

null

Software traceability aims at preserving the understanding of software systems. Because traceability is expensive to implement, various tracing techniques focusing on particular tracing tasks have been developed during the last years. In order to assess these techniques, researchers use specialized problem sets not reusable by other researchers. As a result, there is almost no communication between researchers interested in different tracing tasks. As a traceability benchmark would solve this problems, a common traceability benchmark is presented in this thesis. Additionally, the thesis demonstrates that the field of software traceability can benefit from the presented benchmark.

When performed on a model, a set of operations (e.g., queries or model transformations) rarely uses all the information present in the model. Unintended underuse of a model can indicate various problems: the model may contain more detail than necessary or the operations may be immature or erroneous. Analyzing the footprints of the operations - i.e., the part of a model actually used by an operation - is a simple technique to diagnose and analyze such problems. In this report, we present the implementation of static and dynamic footprinting approaches for operations written in Kermeta. We also present the models and model operations used for the comparison of these approaches.

Keeping requirements specification up-to-date during the evolution of a software system is an expensive task. Consequently, specifications are usually not updated and rapidly become obsolete and unreliable. The goal of our research is to preserve the alignment between requirements and the implementation by supporting the maintenance of the specification. In this proposal, we explore the idea of using tests to automatically generate hints about the evolution of requirements. We discuss the main research questions that need to be addressed, and propose ideas to approach them.

Successful software products frequently evolve into software product lines, whether intentionally or not. In such cases, product managers have to be involved in creating and specifying the commonality and variability of the evolving software product line in order to continuously assure a winning business case. In this paper we introduce feature unweaving, a novel approach that allows a product manager to efficiently evolve an integrated graphical requirements model into a product line model: when he or she has identified variable elements, feature unweaving automatically extracts these elements and refactors them into a feature, using an aspect-oriented approach. Feature unweaving significantly reduces the required effort for variability specification, both on a clerical and intellectual level. Furthermore, variability constraints can be added to capture more knowledge about the features and their interdependencies. We evaluate and validate our approach with two case studies.

We argue for the creation and use of a very lightweight requirements modeling language as an alternative to textual and pictorial requirements specifications.

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 [9] [10] 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.

Companies in the software business often distribute requirements engineering responsibilities over several roles. Product management has overall product responsibility and performs early-phase market-driven requirements engineering. Product development implements the product and performs late-phase solution-oriented requirements engineering. Such shared responsibility provides advantages in the utilization of specific knowledge, skills, and resources, but leads to problems of mutual understanding and coordination. Earlier research proposed a negotiation process, handshaking with implementation proposals, that allows product management and development to achieve agreed requirements understanding. The process found acceptance in industry, but the relative advantages compared with traditional requirements hand-off and analysis had not been understood yet. This paper fills this gap by describing a case of measuring requirements and design volatility and an architect's requirements understanding during requirements hand-off, analysis, and negotiation.

Updating the requirements specification during software evolution is a manual and expensive task. Therefore, software engineers usually choose to apply modifications directly to the code and leave the requirements unchanged. This leads to the loss of the knowledge contained in the requirements documents and thus limits the evolvability of a software system. In this paper, we propose to employ the co-evolution of the code and its test suite to preserve or restore the alignment between implementation and requirements: when a change has been applied to the code, subsequent changes in the test suite as well as failing tests are analyzed and used to automatically generate hints about the affected requirements and how they should be changed. These hints support the engineer in maintaining the requirements specification and thus ease the further evolution of the software system.

[Context & motivation] Market-oriented development involves the collaboration of many stakeholders that do not necessarily directly interact with a given development project but still influence its results. These stakeholders are part of the requirements value chain for the concerned software product. [Question/problem] Understanding the structure and functioning of requirements value chains is essential for effective stakeholder management and requirements engineering within the software product’s ecosystem. [Principal ideas/results] The paper explores and exemplifies fundamental concepts that are needed to characterize and reason about requirements value chains. [Contribution] This characterization is used to describe the relevant knowledge landscape and to suggest research avenues for understanding the principles needed for managing requirements-based stakeholder collaboration.

While diagrams play a central role in the software lifecycle, computer-based modeling tools are often not used in practice. At least to some extent, this is due to their lack of exibility and support of recurring and tedious \model administration" tasks. Such tasks, like the rearrangement of existing model elements to provide the space required by a new element or the manual adjustment of lines after moving an element, distract the user from the actual modeling activities. In this paper, we present an approach to relieve the modeler from the painful manual placement of the labels accompanying the links in a diagram by handing this task over to the modeling tool. Additionally, we give a short overview over other modeling activities that come along with the creation and manipulation of a diagram but should be handled by the tool and not the user.

Quantitative prediction of quality properties (i.e. extra-functional properties such as performance, reliability, and cost) of software architectures during design supports a systematic software engineering approach. Designing architectures that exhibit a good trade-off between multiple quality criteria is hard, because even after a functional design has been created, many remaining degrees of freedom in the software architecture span a large, discontinuous design space. In current practice, software architects try to find solutions manually, which is time-consuming, can be error-prone and can lead to suboptimal designs. We propose an automated approach to search the design space for good solutions. Starting with a given initial architectural model, the approach iteratively modifies and evaluates architectural models. Our approach applies a multi-criteria genetic algorithm to software architectures modelled with the Palladio Component Model. It supports quantitative performance, reliability, and cost prediction and can be extended to other quantitative quality criteria of software architectures. We validate the applicability of our approach by applying it to an architecture model of a component-based business information system and analyse its quality criteria trade-offs by automatically investigating more than 1200 alternative design candidates.

Deriving products from a software product line is difficult, particularly when there are many constraints in the variability of the product line. Understanding the impact of variability binding decisions (i.e. of selecting or dismissing features) is a particular challenge: (i) the decisions taken must not violate any variability constraint, and (ii) the effects and consequences of every variability decision need to be understood well. This problem can be reduced significantly with good support both for variability specification and decision making. We have developed an extension of the \textsc{Adora} language and tool which is capable of modeling and visualizing both the functionality and the variability of a product line in a single model and provides automated reasoning on the variability space. In this paper we describe how our approach supports stepwise, incremental derivation of a product requirements specification from a product line specification. We visualize what has been derived so far, automatically re-evaluate the variability constraints and propagate the results as restrictions on the remaining product derivation options. We demonstrate our approach by showing a sequence of product derivation steps in an example from the industrial automation domain. We claim that our approach both improves the efficiency and quality of the derivation process.

Software product line engineering is a field of increasing importance in the area of software engineering. The goal is to exploit commonalities between software products and therefore increase the development efficiency and quality. Requirements engineering is central to systematically create the product line as a whole and to generate concrete product specifications. In research and industry there exist different concepts for such a requirements modeling. So far there exists no scientific evidence on the advantages and disadvantages of these concepts. This Bachelor thesis contributes to reduce this gap. An existing case study of a software product line was systematically modeled with different concepts in three modern tools. This modeling was then analyzed in detail, many different quantitative and qualitative measurements were taken and these were used to derive concrete strengths and weaknesses of the different concepts. The results will be useful for industry to guide decision processes for selecting a concrete modeling tool and also for tool developers to understand the potential and opportunities for improvement of the concepts and tools.

Despite all efforts in creating and disseminating requirements modeling languages, natural language is still the dominant language for writing requirements specifications in practice. Furthermore, when documenting early requirements, natural language (in combination with pictures) outperforms today’s requirements modeling languages. In this paper, we present a vision and research roadmap for an ultralightweight requirements modeling language which can be used as easily as natural language with pictures, but has a visual structure with some lightweight semantics that allow the visual expression of hierarchical structure, context, general relationship, flow, and influence, while all the details are specified in natural language, both form-based and free-text. Furthermore, it should be possible to evolve parts of such an ultralightweight model into classic models of structure and behavior with full-fledged semantics by incrementally adding more formal model elements and tightening the meaning of the already existing ones. We envisage that such a modeling language – when supported by appropriate tools – will (1) outperform natural language requirements specifications with respect to comprehensibility, changeability, analyzability and internal traceability, (2) be simpler and more straightforward to read and create than today’s heavyweight modeling languages, (3) provide an effi- cient and effective means for expressing requirements at an early stage.

This master’s thesis relates to the field of requirements engineering for software product lines. Compared to single-system modeling, the creation of product line models is more challenging. This work bases on the ADORA language, a graphical modeling language for requirements and architecture that also supports the modeling of software product lines. Whereas this modeling language is relatively easy for single system models, the modeling of variability is more complicated, as sophisticated weaving semantics Mei09 have to be applied. Additionally, the creation of variants in ADORA is very unhandy, as a lot of klicking has to be done by the modeler. In this thesis we introduce a new approach that simplifies the creation of a product line model, called Feature Unweaving. This feature unweaving function allows the user to select model elements that should be extracted into a variant. According to the selection, the function is then able to create a variant with correct weaving semantics automatically. The automation concentrates on the model elements that define the weaving semantics of a variant. The development of this function was based on two real-world exemplars. Additionally, we have analyzed and extended the current weaving semantics to make sure that they were feasible to model such real-world software product lines. In a last step, we evaluated the feature unweaving function on the basis of the real-world product line exemplars. During this evaluation, we could conclude that the unweaving function was able to extract all the variants that occurred in the exemplars. Furthermore, the process of feature extraction in ADORA could be made more efficient, less effort is required to create variants. Additionally, modelers that don’t have detailed knowledge about ADORA’s weaving semantics yet, can introduce variability into an ADORA model more easily, this makes the ADORA language more accessible.