Samuel Fricker

Handshaking with Implementation Proposals: Negotiating Requirements Understanding

A bidirectional process for agreeing on product requirements proves effective in overcoming misunderstandings that arise in the traditional handoff of requirements specifications to development teams.

Software Product Management

Software organizations evolve and maintain software solutions with more than a single development project. The delta specifications and artifacts that result from each project make reuse difficult and challenge a company’s ability to innovate. Software product management is a growing discipline for understanding how to productize and align software with company strategy, how to evolve software, and how to coordinate product stakeholders. With product focus, in addition to project focus, planning accuracy can be improved, time-to-market reduced, product quality enhanced, and economic success sustained. This chapter provides an overview on software product management and discusses what today is known about this discipline.

A Lightweight Innovation Process for Software-Intensive Product Development

An innovation process using face-to-face screening and idea refinement with heterogeneous audition teams can enhance the longterm perspective of product planning and development.

Handshaking between software projects and stakeholders using implementation proposals

Handshaking between product management and R&D is key to the success of product development projects. Traditional requirements engineering processes build on good quality requirements specifications, which typically are not achievable in practical circumstances, especially not in distributed development where daily communication cannot easily be achieved to support the understanding of the specification and tacit knowledge cannot easily be spread. Projects thus risk misunderstanding requirements and are likely to deliver inadequate solutions. This paper presents an approach that uses downstream engineering artifacts, design decisions, to improve upstream information, a projects requirements. During its preliminary validation, the approach yielded promising results. It is well suited for distributed software projects, where the negotiation on requirements and solution design need to be made explicit and potential problems and misunderstandings caught at early stages.

Requirements Value Chains: Stakeholder Management and Requirements Engineering in Software Ecosystems

[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.

Goal-Oriented Requirements Communication in New Product Development

Product development organizations often distribute the responsibilities for requirements engineering over several roles. The collaboration of product management, concerned with market needs, and product development, concerned with the technological aspects of a product, is well established. Such shared responsibility provides advantages in the utilization of specific knowledge, skills, and resources. However, the collaboration leads to increased demands on coordination. Novel concepts and models need to be investigated to support such collaborative requirements engineering. In this paper we focus on requirements communication from product management to a development team by proposing and evaluating the model of goal-oriented requirements communication. The model explains how efficiency and effectiveness of requirements communication can be increased and allows the utilization of established requirements engineering knowledge in a new way to address the task of requirements communication.

On shared understanding in software engineering: an essay

Shared understanding is essential for efficient software engineering when the risk of unsatisfactory out-come and rework of project results shall be low. Today, however, shared understanding is used mostly in an unreflected, ad-hoc way. This affects the quality of the engineered software solutions and generates re-work once the quality problems are discovered. In this article, we investigate the role, value, and usage of shared understanding in software engineering. We contribute a reflected analysis of the problem, in particular of how to rely on shared understanding that is implicit, rather than explicit. After an overview of the state of the art we discuss forms and value of shared understanding in software engineering, survey enablers and obstacles, compile existing practices for dealing with shared understanding, and present a roadmap for improving knowledge and practice in this area.

Release planning with feature trees: industrial case

[Context and motivation] Requirements catalogues for software release planning are often not complete and homogeneous. Current release planning approaches, however, assume such commitment to detail --- at least implicitly. [Question/problem] We evaluate how to relax these expectations, while at the same time reducing release planning effort and increasing decision-making flexibility. [Principal ideas/results] Feature trees capture AND, OR, and REQUIRES relationships between requirements. Such requirements structuring can be used to hide incompleteness and to support abstraction. [Contribution] The paper describes how to utilize feature trees for planning the releases of an evolving software solution and evaluates the effects of the approach on effort, decision-making, and trust with an industrial case.

Comparison of Requirements Hand-off, Analysis, and Negotiation: Case Study

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.

KPIs for Software Ecosystems: A Systematic Mapping Study

To create value with a software ecosystem (SECO), a platform owner has to ensure that the SECO is healthy and sustainable. Key Performance Indicators (KPI) are used to assess whether and how well such objectives are met and what the platform owner can do to improve. This paper gives an overview of existing research on KPI-based SECO assessment using a systematic mapping of research publications. The study identified 34 relevant publications for which KPI research and KPI practice were extracted and mapped. It describes the strengths and gaps of the research published so far, and describes what KPI are measured, analyzed, and used for decision-making from the researcher’s point of view. For the researcher, the maps thus capture state-of-knowledge and can be used to plan further research. For practitioners, the generated map points to studies that describe how to use KPI for managing of a SECO.