Paul Grünbacher

Developing groupware for requirements negotiation: lessons learned

Defining requirements is a complex and difficult process, and defects in the process often lead to costly project failures. There is no complete and well-defined set of requirements waiting to be discovered in system development. Different stakeholders: users, customers, managers, domain experts, and developers, come to the project with diverse expectations and interests. Requirements emerge in a highly collaborative, interactive, and interdisciplinary negotiation process that involves heterogeneous stakeholders. At the University of Southern Californias Center for Software Engineering, we have developed a series of groupware implementations for the WinWin requirements negotiation approach. The WinWin approach involves having a systems success-critical stakeholders participate in a negotiation process so they can converge on a mutually satisfactory or win-win set of requirements. The WinWin groupware system, which has evolved over four generations, enables and facilitates heterogeneous stakeholder participation and collaboration. Each generation reflects an increase in our understanding of what is needed for successful WinWin groupware operations and technology support. The authors present the major lessons they learned during WinWins development.

Cool features and tough decisions: a comparison of variability modeling approaches

Variability modeling is essential for defining and managing the commonalities and variabilities in software product lines. Numerous variability modeling approaches exist today to support domain and application engineering activities. Most are based on feature modeling (FM) or decision modeling (DM), but so far no systematic comparison exists between these two classes of approaches. Over the last two decades many new features have been added to both FM and DM and it is tough to decide which approach to use for what purpose. This paper clarifies the relation between FM and DM. We aim to systematize the research field of variability modeling and to explore potential synergies. We compare multiple aspects of FM and DM ranging from historical origins and rationale, through syntactic and semantic richness, to tool support, identifying commonalities and differences. We hope that this effort will improve the understanding of the range of approaches to variability modeling by discussing the possible variations. This will provide insights to users considering adopting variability modeling in practice and to designers of new languages, such as the new OMG Common Variability Language.

The DOPLER meta-tool for decision-oriented variability modeling: a multiple case study

The variability of a product line is typically defined in models. However, many existing variability modeling approaches are rigid and don’t allow sufficient domain-specific adaptations. We have thus been developing a flexible and extensible approach for defining product line variability models. Its main purposes are to guide stakeholders through product derivation and to automatically generate product configurations. Our approach is supported by the DOPLER (Decision-Oriented Product Line Engineering for effective Reuse) meta-tool that allows modelers to specify the types of reusable assets, their attributes, and dependencies for their specific system and context. The aim of this paper is to investigate the suitability of our approach for different domains. More specifically, we explored two research questions regarding the implementation of variability and the utility of DOPLER for variability modeling in different domains. We conducted a multiple case study consisting of four cases in the domains of industrial automation systems and business software. In each of these case studies we analyzed variability implementation techniques. Experts from our industry partners then developed domain-specific meta-models, tool extensions, and variability models for their product lines using DOPLER. The four cases demonstrate the flexibility of the DOPLER approach and the extensibility and adaptability of the supporting meta tool.

Automating requirements traceability: Beyond the record & replay paradigm

Requirements traceability (RT) aims at defining relationships between stakeholder requirements and artifacts produced during the software development life-cycle. Although techniques for generating and validating RT are available, RT in practice often suffers from the enormous effort and complexity of creating and maintaining traces or from incomplete trace information that cannot assist engineers in real-world problems. In this paper we will present a tool-supported technique easing trace acquisition by generating trace information automatically. We will explain the approach using a video-on-demand system and show that the generated traces can be used in various engineering scenarios to solve RT-related problems.

Reconciling software requirements and architectures with intermediate models

Little guidance and few methods are available for the refinement of software requirements into an architecture satisfying those requirements. Part of the challenge stems from the fact that requirements and architectures use different terms and concepts to capture the model elements relevant to each. In this paper we will present CBSP, a lightweight approach intended to provide a systematic way of reconciling requirements and architectures using intermediate models. CBSP leverages a simple set of architectural concepts (components, connectors, overall systems, and their properties) to recast and refine the requirements into an intermediate model facilitating their mapping to architectures. Furthermore, the intermediate CBSP model eases capturing and maintaining arbitrarily complex relationships between requirements and architectural model elements, as well as among CBSP model elements. We have applied CBSP within the context of different requirements and architecture definition techniques. We leverage that experience in this paper to demonstrate the CBSP method and tool support using a large-scale example.

Supporting Product Derivation by Adapting and Augmenting Variability Models

Product derivation is the process of constructing products from the core assets in a product line. Guidance and support are needed to increase efficiency and to deal with the complexity of product derivation. Research has, however, devoted comparatively little attention to this process. In this paper we describe an approach for supporting product derivation. We show that variability models need to be prepared for concrete projects before they can be effectively utilized in the derivation process. Project-specific information and sales knowledge should be added and irrelevant variability should be pruned. We also present tool support and illustrate the approach using examples from ongoing research collaboration.

Requirements for product derivation support: Results from a systematic literature review and an expert survey

Context: An increasing number of publications in product line engineering address product derivation, i.e., the process of building products from reusable assets. Despite its importance, there is still no consensus regarding the requirements for product derivation support. Objective: Our aim is to identify and validate requirements for tool-supported product derivation. Method: We identify the requirements through a systematic literature review and validate them with an expert survey. Results: We discuss the resulting requirements and provide implementation examples from existing product derivation approaches. Conclusions: We conclude that key requirements are emerging in the research literature and are also considered relevant by experts in the field.

A comparison of decision modeling approaches in product lines

It has been shown that product line engineering can significantly improve the productivity, quality and time-to-market of software development by leveraging extensive reuse. Variability models are currently the most advanced approach to define, document and manage the commonalities and variabilities of reusable artifacts such as software components, requirements, test cases, etc. These models provide the basis for automating the derivation of new products and are thus the key artifact to leverage the flexibility and adaptability of systems in a product line. Among the existing approaches to variability modeling feature modeling and decision modeling have gained most importance. A significant amount of research exists on comparing and analyzing different feature modeling approaches. However, despite their significant role in product line research and practical applications, only little effort has been devoted to compare and analyze decision modeling approaches. In order to address this shortcoming and to provide a basis for more structured research on decision modeling in the future, we present a comparative analysis of representative approaches. We identify their major modeling concepts and present an analysis of their commonalities and variabilities.

Surfacing tacit knowledge in requirements negotiation: experiences using EasyWinWin

Defects in the requirements definition process often lead to costly project failures. One eminent problem is that it can be difficult to take deliberate advantage of important tacit knowledge of success-critical stakeholders. People know more that they can ever tell. Implicit stakeholder goals, hidden assumptions, unshared expectations often result in severe problems in the later stages of software development. We present a set of collaborative techniques that support a team of success-critical stakeholders in surfacing tacit knowledge during systems development projects. We discuss these techniques in the context of the EasyWinWin requirements negotiation methodology and illustrate our approach with examples from real-world negotiations.

Reconciling software requirements and architectures: the CBSP approach

Little guidance and few methods are available to refine a set of software requirements into an architecture satisfying those requirements. Part of the challenge stems from the fact that requirements and architectures leverage different terms and concepts to capture the artifacts relevant to each. We present CBSP (Component-Bus-System- Property), a lightweight approach intended to provide a systematic way of reconciling requirements and architectures. CBSP leverages a simple set of architectural concepts (components, connectors, overall systems, and their properties) to recast the requirements in a way that facilitates their straightforward mapping to architectures. Furthermore, the approach allows us to capture and maintain arbitrarily complex relationships between requirements and architectural artifacts, as well as across different CBSP artifacts. We have extensively applied CBSP within the context of particular requirements and architecture definition techniques, EasyWinWin and C2. We leverage that experience to demonstrate the CBSP method and tool support using a large-scale example that highlights the transition from an EasyWinWin requirements negotiation into a C2-style architectural model.