Towards requirements traceability models

Abstract

Requirements traceability is intended to ensure continued alignment between stakeholder requirements and system evolution. To be useful, traces must be organized according to some modeling framework. Indeed, several such frameworks have been proposed, mostly based on theoretical considerations or analysis of other literature. This paper, in contrast, follows an empirical approach. Focus groups and interviews conducted in 26 major software development organizations demonstrate a wide range of traceability practices with distinct low-end and high-end users of traceability. From these observations, reference models comprising the most important kinds of traceability links for various development tasks have been synthesized. The resulting models have been validated in case studies and are incorporated in a number of commercial traceability tools. The discussion of the link types and their usage in practice has implications for the design of next-generation traceability methods and tools.

A survey of architecture design rationale

“…These reasons are analogous to those concerning requirements traceability documentation in immature software development organizations (Ramesh and Jarke, 2001). Since the sample population is not specific to an industry or capability maturity level, the results may indeed reflect the general architecture design practice.…”

Requirements engineering in automotive development-experiences and challenges

“…Introducing explicit traceability promises big savings [14], [15]. But in order to pay back, introducing explicit traceability requires a careful tradeoff analysis.…”

A comparative study of architecture knowledge management tools

“…AK representations also vary greatly using formal model (Shaw et al, 1995), textual documentation (Tyree and Akerman, 2005), graphs (Lee and Lai, 1996) to represent relationships or using defined links within a knowledge repository (Conklin and Begeman, 1988 Fig. 2, the consumer of architectural knowledge needs the ability to trace AK through different types of interrelated AK entities, for instance between requirements and design, or between design and implementation (Hughes and Martin, 1998;Ramesh and Jarke, 2001). An evaluation of such relationships allow a user to assess how AK tools support architects in the architecture life-cycle to perform functions such as tracing related architectural knowledge and performing change impact analysis (Bratthall et al, 2000 (Jackson, 1995), or record the ASRs and scenarios in the analysis (Clements et al, 2002;Bengtsson and Bosch, 1998 by providing knowledge such as design patterns (Harrison et al, 2007), architectural tactics (Bass et al, 2003), previous architectural solutions and design rationale (Lee and Lai, 1996;Conklin and Burgess-Yakemovic, 1996), and alternative design solutions (Maclean et al, 1996).…”