Project managers aim at keeping track of interdependencies between various artifacts of the software development lifecycle, to find out potential requirements conflicts, to better understand the impact of change requests, and to fulfill process quality standards, such as CMMI requirements. While there are many methods and techniques on how to technically store requirements traces, the economic issues of dealing with requirements tracing complexity remain open. In practice tracing is typically not an explicit systematic process, but occurs rather ad hoc with considerable hidden tracing-related quality costs. This paper reports a case study on value-based requirements tracing (VBRT) that systematically supports project managers in tailoring requirements tracing precision and effort based on the parameters stakeholder value, requirements risk/volatility, and tracing costs. Main results of the case study were: (a) VBRT took around 35% effort of full requirements tracing; (b) more risky or volatile requirements warranted more detailed tracing because of their higher change probability.

Many software development standards mandate establishing trace links among software artifacts such as requirements, architectural elements, or source code. However, for typical real-world systems it is currently too expensive and error prone to generate highly detailed trace links. We previously developed an approach to semi-automatically generate trace links and analyzed cost-benefit trade-offs in this context. We consider it as imperative to include value considerations into planning the generation of trace dependencies. This paper discusses three key trade-off decisions for planning the trace generation process: (a) the level of detail of traces among artifacts; (b) the value of the artifacts that are traced; and (c) the points in time of trace generation (early vs. late). We present cost-benefit considerations, empirical data, and argue for a pragmatic value-based planning approach.

Abstract.Requirements managers aim at keeping the set of requirements consistent and up to date throughout the project by conducting the following tasks: requirements categorization, requirements conflict analysis, and requirements tracing. However, the manual conduct of these tasks takes significant effort and is error-prone. In this paper we propose to use semantic technology as foundation for automating the requirements management tasks and introduce the ontology-based reporting approach OntRep. We evaluate the effectiveness and effort the OntRep approach based on a real-world industrial empirical study with professional Austrian IT project managers. Major results were that OntRep provides reasonable capabilities for the automated categorization of requirements, was when compared to a manual approach considerably more effective to identify conflicts, and produced less false positives with similar effort.

Major software development standards mandate the establishment of trace links among software artifacts such as requirements, architectural elements, or source code without explicitly stating the required level of detail of these links. However, the level of detail vastly affects the cost and quality of trace link generation and important applications of trace analysis such as conflict analysis, consistency checking, or change impact analysis. In this paper, we explore these cost-quality trade-offs with three case study systems from different contexts -the open-source ArgoUML modeling tool, an industrial route-planning system, and a movie player. We report the cost-quality trade-off of automated trace generation with the Trace Analyzer approach and discuss its expected impact onto several applications that consume its trace information. In the study we explore simple techniques to predict and manipulate the cost-benefit trade-off with threshold-based filtering. We found that (a) 80% of the benefit comes from only 20% of the cost and (b) weak trace links are predominantly false trace links and can be efficiently eliminated through thresholds.

Traceability from requirements to code is mandated by numerous software development standards. These standards, however, are not explicit about the appropriate level of quality of trace links. From a technical perspective, trace quality should meet the needs of the intended trace utilizations. Unfortunately, long-term trace utilizations are typically unknown at the time of trace acquisition which represents a dilemma for many companies. This chapter suggests ways to balance the cost and benefits of requirements traceability. We present data from three case studies demonstrating that trace acquisition requires broad coverage but can tolerate imprecision. With this trade-off our lessons learned suggest a traceability strategy that (1) provides trace links more quickly, (2) refines trace links according to user-defined value considerations, and (3) supports the later refinement of trace links in case the initial value consideration has changed over time. The scope of our work considers the entire life cycle of traceability instead of just the creation of trace links.