Orlena Gotel

An analysis of the requirements traceability problem

Investigates and discusses the underlying nature of the requirements traceability problem. Our work is based on empirical studies, involving over 100 practitioners, and an evaluation of current support. We introduce the distinction between pre-requirements specification (pre-RS) traceability and post-requirements specification (post-RS) traceability to demonstrate why an all-encompassing solution to the problem is unlikely, and to provide a framework through which to understand its multifaceted nature. We report how the majority of the problems attributed to poor requirements traceability are due to inadequate pre-RS traceability and show the fundamental need for improvements. We present an analysis of the main barriers confronting such improvements in practice, identify relevant areas in which advances have been (or can be) made, and make recommendations for research.<<ETX>>

Extended requirements traceability: results of an industrial case study

Contribution structures offer a way to model the network of people who have participated in the requirements engineering process. They further provide the opportunity to extend conventional forms of artifact-based requirements traceability with the traceability of contributing personnel. We describe a case study that investigated the modelling and use of contribution structures in an industrial project. In particular, we demonstrate how they made it possible to answer previously unanswerable questions about the human source(s) of requirements. In so doing, we argue that this information addresses problems currently attributed to inadequate requirements traceability.

Contribution structures [Requirements artifacts]

The invisibility of the individuals and groups that gave rise to requirements artifacts has been identified as a primary reason for the persistence of requirements traceability problems. The paper presents an approach based on modelling the dynamic contribution structures underlying requirements artifacts, which addresses this issue. It shows how these structures can be defined, using information about the agents who have contributed to artifact production, in conjunction with details of the numerous traceability relations that hold within and between artifacts themselves. It further outlines how the approach can be implemented, demonstrates the potential it provides for personnel-based requirements traceability, and discusses issues pertinent to its uptake.

Towards automated traceability maintenance

Traceability relations support stakeholders in understanding the dependencies between artifacts created during the development of a software system and thus enable many development-related tasks. To ensure that the anticipated benefits of these tasks can be realized, it is necessary to have an up-to-date set of traceability relations between the established artifacts. This goal requires the creation of traceability relations during the initial development process. Furthermore, the goal also requires the maintenance of traceability relations over time as the software system evolves in order to prevent their decay. In this paper, an approach is discussed that supports the (semi-) automated update of traceability relations between requirements, analysis and design models of software systems expressed in the UML. This is made possible by analyzing change events that have been captured while working within a third-party UML modeling tool. Within the captured flow of events, development activities comprised of several events are recognized. These are matched with predefined rules that direct the update of impacted traceability relations. The overall approach is supported by a prototype tool and empirical results on the effectiveness of tool-supported traceability maintenance are provided.

Acquiring Tool Support for Traceability

“Which traceability tool?” is a question that many organisations can spend time and resources considering. It has long been a perception that a tool, once acquired and installed on a project, can address all of its traceability-related needs. However, the purchase or development of a tool to support traceability can be a costly decision. Not only can the tool become shelf-ware, organisations can get burdened with expensive support contracts, disproportionate effort can get misdirected towards learning to use the tool and configuring it to address particular needs, and inappropriate use can lead to erroneous decisions. Acquiring a tool to support traceability is no trivial matter and it needs to be undertaken as part of a broader process improvement initiative. This chapter presents a seven-step guide for the practitioner to make decisions about tools to support their particular traceability needs from within the wider context of a new or improved requirements management system.

Out of the labyrinth: Leveraging other disciplines for requirements traceability

Imagine a world in which luggage never comes, Fido remains lost, forgeries cannot be distinguished from the genuine, a gallon of petrol in one gas station is not equivalent to a gallon in another, tainted peanut products cannot be recalled and disease runs rife. Without the ability to trace, one may anticipate such a world. Tracing is one of the oldest skills possessed by the human race and was vital to the survival of early hunters. Over millennia, mankind has adapted this skill to other areas, ranging from metrology to epidemiology. Software systems engineering is a relatively new discipline that employs tracing, but it appears to exhibit some unique characteristics. This paper examines tracing and its underlying concepts across a number of disciplines to highlight the specific challenges associated with tracing requirements. It draws upon these disciplines to illustrate how existing practices could be leveraged, and to clarify a priority for research and practice.

traceMaintainer - Automated Traceability Maintenance

traceMaintainer is a tool that maintains post-requirements traceability amongst the elements of structural UML models. The maintenance of traceability relations is based upon predefined rules. Each rule recognizes a development activity applied to a model element. traceMaintainer carries out associated traceability updates in the background after an activity has been completed, requiring minimal manual effort and limited interaction with the developer. Currently, traceMaintainer can be used with two commercial software development (CASE) tools to update the traceability relations stored within them, while the underlying approach extends further to maintaining traceability within a heterogeneous and distributed environment of tools.

Revisiting requirements production

Key information relating to requirements production is either lost or unrecoverable as a consequence of conventional requirements engineering practices. This includes, most significantly, information about the individuals and groups from whom requirements were originally elicited and by whom they were subsequently refined. An approach is outlined of rendering such information traceable, which anchors requirements and development information in the contribution structure from which it arose, and enables the workings of the requirements production process to be revisited in later phases of development. It is demonstrated how the use of the approach can prevent the premature freezing of requirements elicitation and allows us to establish the consequences of organisational change.

Ready-to-Use Traceability on Evolving Projects

This chapter focuses on traceability-related challenges in evolving projects and on tasks that are beyond the initial creation of traces. It revolves around two major activities in the traceability life cycle: (1) defining the traceability that is required on a project and (2) keeping the traceability ready-to-use by maintaining previously established trace links as the project evolves. The chapter provides a step by step process for designing a goal-oriented traceability strategy on a project and discusses the problem of traceability decay. It describes a particular approach to the (semi-)automated maintenance of traceability to address this problem and highlights a number of outstanding research challenges in the area.

The role of flow charts in the early automation of applied mathematics

The rapid spread of computers into almost all fields of commercial, intellectual, and social activity has obscured a great deal: the role of mathematicians in the early history of computing, the uses of early machines, the techniques developed by mathematicians to aid their use and the impact of automation on mathematics itself. Fortunately archives in both the United Kingdom and the United States have preserved some evidence of how mathematicians developed the techniques necessary to exploit early machines.