Software and Systems Traceability

This chapter seeks to provide a reference resource on traceability fundamentals. It defines the essential traceability terminology of trace, trace artifact, trace link, traceability and tracing, and is supplemented by an extensive glossary that has been developed and endorsed by members of the traceability community. This chapter also offers a model of a generic traceability process and describes the essential activities involved in the life cycle of a trace. This model has been used as a frame of reference for articulating the grand challenge of traceability, as reported in the chapter by Gotel et al. of this book. The chapter also describes the basic types of traceability and explains a number of key associated concepts.

Traceability can provide substantial benefits, but many software development projects fail to employ best practise in traceability. A major factor in this is the relatively high cost of traceability and the difficulty of assessing its long term financial benefits. We discuss techniques for implementing requirements traceability in such a way as to maximise the potential benefits whilst minimising the costs, but still ensuring that trace data collected meets the needs of the project. Finally we suggest a simple, practical cost analysis for developing an appropriate traceability strategy, underpinned by value-based software engineering principles.

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

The potential benefits of traceability are well known and documented, as well as the impracticability of recovering and maintaining traceability links manually. Indeed, the manual management of traceability information is an error prone and time consuming task. Consequently, despite the advantages that can be gained, explicit traceability is rarely established unless there is a regulatory reason for doing so. Extensive efforts have been brought forth to improve the explicit connection of software artifacts in the software engineering community (both research and commercial). Promising results have been achieved using Information Retrieval (IR) techniques for traceability recovery. IR-based traceability recovery methods propose a list of candidate traceability links based on the similarity between the text contained in the software artifacts. Software artifacts have different structures and the common element among many of them is the textual data, which most often captures the informal semantics of artifacts. For example, source code includes large volume of textual data in the form of comments and identifiers. In consequence, IR-based approaches are very well suited to address the traceability recovery problem. The conjecture is that artifacts with high textual similarity are good candidates to be traced to each other since they share several concepts. In this chapter we overview a general process of using IR-based methods for traceability link recovery and overview some of them in a greater detail: probabilistic, vector space, and Latent Semantic Indexing models. Finally, we discuss common approaches to measuring the performance of IR-based traceability recovery methods and the latest advances in techniques for the analysis of candidate links.

In requirement engineering, researchers have proposed various tractability recovery approaches. To the best of our knowledge, all traceability recovery approaches have low precision and recall. Our main claim in this chapter is that there exist factors that impact the traceability approaches’ inputs, in particular source document, target document, and experts’ opinion, that cause low precision and recall. In this chapter, we pursue four objectives: first, to identify and document factors that impact traceability recovery approaches’ inputs; second, to identify metrics/tools to measure/improve the quality of the inputs with respect to the identified factors, third, to provide precautions to control these factors, and, fourth, to empirically prove and quantify the effect of one of these factors–expert’s programming knowledge–on the traceability recovery approaches’ inputs. To achieve the first two objectives, we perform an incremental literature review of traceability recovery approaches and identify and document three key inputs and the seven factors impacting these inputs, out of 12 identified factors. We analyse the reported results in literature for the identified factors to address our third objective. We conduct an empirical study to assess the impact of expert’s programming knowledge, to address our fourth objective. We use the effort, number of correct answers, and time to measure the effect of expert’s programming knowledge on traceability recovery. We conclude that, in the literature, seven factors impacting the inputs of traceability recovery approaches have been identified, documented, and reported along with related metrics/tools and precautions. We suggest that practitioners should be wary of these seven factors and researchers should focus on the five others to improve traceability recovery approaches.

Software traceability is becoming an increasingly important facet of software engineering, especially as development projects become more distributed, decentralized, and dependent on third-party software. This chapter illustrates how traceability links can be automatically captured in situ, while software engineers perform their development tasks, through the use of specialized open hypermedia adapters and custom rules. Focusing on the mobile phone case study, we demonstrate how users can integrate their custom filters, heuristics, and relationship types, as well as their existing development tools, into our traceability system. We also show how our traceability link-capture technique can be incorporated with search tools and how traceability links can be effectively maintained. We provide practical usage scenarios and brief technical discussions for each of these capabilities.

In this chapter we present a rule-based framework to support automatic creation of trace relationships and identification of missing elements based on traceability rules. The framework supports documents generated during the development life cycle of object-oriented, product line, and agent-oriented systems. We have identified different types of trace relationships for these documents. The framework assumes traceability rules expressed in XQuery. The rules consider different aspects such as the semantics of the artifacts being compared, the types of trace relationships, and the grammatical roles and associations of words in textual parts of the artifacts. Prototype tools have been implemented to demonstrate and evaluate the work. Evaluation of the framework in terms of recall and precision measurements in several case studies are positive and encouraging.

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.

Software product lines typically are large-scale systems that are maintained and evolved over many years. New customer requirements, technology changes, and internal enhancements lead to continuous changes of product line artifacts. Managing these changes represents a key issue during evolution and traceability is success-critical for this process. In this chapter we discuss traceability challenges from a product line perspective and propose an approach that supports trace acquisition in product lines. The approach builds on our highly extensible EvoKing framework for the continuous tracking of changes in Eclipse workspaces. It supports both prospective and retrospective tracing at multiple levels of granularity. We demonstrate our approach using the mobile phone product line example.

Model-Driven Engineering (MDE) employs models and model transformations as first-class citizens throughout the whole software development life cycle. Support for automated traceability is necessary because models in MDE usually have inherent dependencies between each other, which must be visible. Furthermore, software evolves which implies to also maintain traceability. In this chapter, we present an efficient and scalable traceability maintenance approach. It uses formal rules to specify conditions for maintaining traceability links. We also show the constitution of our rules and how we improved them, in comparison to a previous approach. Based on this formalism, we present two maintenance strategies. We show an initial (batch) strategy that is applied in case that no change information is available. The second strategy is incremental and therefore scalable. The incremental strategy is applied when change information is available. We explain our approach and evaluate the efficiency and scalability of our approach by means of the mobile phone product line case study presented in this book.

This chapter focuses on semi-automated tracing and the challenges and opportunities that it presents to traceability researchers and practitioners The chapter compares three tracing scenarios: manual, fully automated, and semi-automated. Related work in the area of semi-automated tracing is examined. In addition, the chapter presents a discussion of research questions that must be addressed in order to enhance our understanding of what constitutes the “best” automated tracing methods.

Agile methods are becoming an increasingly mainstream approach to software development. They are characterized by short iterations with frequent deliverables, test-driven development, lightweight documentation, and frequent interactions with the customer. Perhaps unsurprisingly, traceability is often seen as unnecessary and therefore unwanted in agile projects. This is due to the perceived overhead of creating and maintaining traceability links and the assumption that agile developers have sufficient understanding of a project to implement a change without the support of previously defined traceability links. This chapter explores the challenges, benefits, techniques, and processes of tracing across a broad spectrum of agile projects.

This chapter focuses on traceability in the final phases of the software life cycle: between the development and run-time phases. Between these phases, an abstraction gap exists: the various high level abstractions used during development are lost in the run-time environment. This often makes inspection of the complex, synthetic run-time structure impossible. We present results in the context of the debugging of aspect oriented software development. The compilation process of aspect oriented programs is inherently complex and create a large abstraction gap. In this chapter, we describe an approach for the development of debugging tools that bridge can use tracing information to bridge the abstraction gap.

Non-functional requirements, describing quality concerns such as performance, security, and availability, often exhibit complex interdependencies and trade-offs and have broad-reaching impacts across the architectural design of a software intensive system. This creates significant challenges for tracing NFRs, as traceability links can quickly proliferate and the traceability effort can be costly and impractical. As a result, many organizations do not even attempt to trace NFRs; however this means that functional changes are often implemented with very little understanding of how system qualities are affected by the change. The challenge, from a traceability perspective, is to develop effective techniques which simplify the task of creating and maintaining NFR-related traceability links, while still providing effective support for critical tasks such as impact analysis, requirements validation, and architectural preservation. In this chapter we first describe and evaluate existing methods for tracing NFRs and then propose a new pattern-based approach which leverages software architectural techniques to achieve NFR traceability. We illustrate our approach with examples from the mobile phone case study.

Software traceability is central to medical device software development and essential for regulatory approval. In order to comply with the regulatory requirements of the medical device industry it is essential to have clear linkages and traceability from requirements – including risks – through the different stages of the software development and maintenance life cycles. The regulatory bodies request that medical device software development organizations clearly demonstrate how they follow a software development life cycle without mandating a particular life cycle. However, due to the traceability requirements of the industry most medical device companies adopt the V-model. Within this chapter we will discuss the importance of traceability to medical device software development, the current state of practice within the industry in relation to traceability and how we feel that traceability could be improved within the industry. The chapter also describes the development and implementation of a medical device traceability software process assessment method (Med-Trace) in two medical device software development organizations. We include these two case studies as one involved a medical device SME based in Ireland and the other a medical device SME based in the UK as we want to illustrate that Med-Trace can be applied within different countries.

This chapter offers a vision for traceability in software and systems engineering and outlines eight challenges that need to be addressed in order to achieve it. One of these challenges is referred to as the grand challenge of traceability because making traceability ubiquitous in software and systems development (traceability challenge eight) demands progress with all seven other challenges. A model of a generic traceability process is used as a framework through which the goals and requirements of each challenge are expressed. For each requirement, the current status of the traceability research and practice is summarised, and areas of promise are highlighted. This systematic analysis is used to articulate eight major research themes for the traceability community, along with a number of underlying research topics and positive adoption practices for industry. This work is a snapshot of an ongoing and collaborative effort between traceability researchers and practitioners within the Center of Excellence for Software Traceability. It is intended to form a structured agenda for traceability research and practice, a basis for classifying research contributions and a means to track progress in the field.