Adapting traceability environments to project-specific needs

R equirements traceability is defined as the ability to describe and follow the life of a requirement, in both a forward and backward direction. It implies the life of each requirement can be understood from its origin, through its development and specification, to its subsequent deployment and use, and through periods of ongoing refinement and iteration [6]. Requirements traceability is a prerequisite for effective system maintenance and consistent change integration [2]. Neglecting traceability or capturing insufficient and/or unstructured traces leads to a decrease in system quality, causes revisions, and thus, increases project costs and time. It results in a loss of knowledge if individuals leave the project, leads to wrong decisions, misunderstanding, and miscommunications [8, 11]. Recent empirical research shows that systems management practice is progressing from the initial simple compliance verification schemata to very sophisticated models and policies for requirements traceability (see Ramesh in this section as well as [6, 8, 11, 12]). Table 1 gives an indication of the richness of advanced traceability schemes. However, the same studies also point out that full capture of all conceivable traces according to these advanced models is neither desirable nor feasible when considering project cost and time. If requirements traceability is not customized it can lead to an unwieldy mass of unstructured and unusable data that will hardly ever be used [6, 9]. The adaptation of trace capture and usage to project-specific needs is thus a prerequisite for successfully establishing traceability within a project and for achieving a positive cost-benefit ratio. The traces to be captured are influenced by factors like project schedule and project budget [11], by the contract, the development standards applied, existing laws, or the expected trace usage. A number of examples, drawn from focus group data of the study reported by Ramesh, are sketched in the sidebar “Examples of Project-Specific Trace Capture and Usage.” The increasing use of commercial requirements traceability environments by industry reflects that traceability is recognized as a critical success factor. A vendor survey of commercial requirements traceability environments performed by :

[1]  Raymond McCall,et al.  Making argumentation serve design , 1991 .

[2]  Raymond McCall,et al.  Making Argumentation Serve Design , 1996, Hum. Comput. Interact..

[3]  Matthias Jarke,et al.  Towards Method-Driven Trace Capture , 1997, CAiSE.

[4]  Bashar Nuseibeh,et al.  Software process modelling and technology , 1994 .

[5]  Sjaak Brinkkemper,et al.  Method engineering : principles of method construction and tool support : proceedings of the IFIP TC8, WG8.1/8.2 Working Conference on Method Engineering, 26-28 August 1996, Atlanta, USA , 1996 .

[6]  W. Edwards Deming,et al.  Out of the Crisis , 1982 .

[7]  Klaus Pohl,et al.  Process-Centered Requirements Engineering , 1996 .

[8]  Balasubramaniam Ramesh,et al.  Requirements traceability: Theory and practice , 1997, Ann. Softw. Eng..

[9]  Balasubramaniam Ramesh,et al.  Implementing requirements traceability: a case study , 1995, Proceedings of 1995 IEEE International Symposium on Requirements Engineering (RE'95).

[10]  Klaus Pohl,et al.  A contextual approach for process-integrated tools , 1997, ESEC '97/FSE-5.

[11]  Jeff Conklin Design rationale and maintainability , 1989, [1989] Proceedings of the Twenty-Second Annual Hawaii International Conference on System Sciences. Volume II: Software Track.

[12]  Jan Stage,et al.  Method Engineering. Principles of Method Construction and Tool Support , 1996 .

[13]  Thomas R. Gruber,et al.  Generative Design Rationale: Beyond the Record and Replay Paradigm , 1996, Design Rationale.