Comprehensive Requirement Traceability Information, and Relations in Project Life-Cycle Vikas Shukla 1, 2 , Guillaume Auriol 1, 2 , Claude Baron 1, 2 , Xinwei Zhang 1, 2 1 CNRS; LAAS; 7 Avenue de Colonel Roche, F-31400 Toulouse cedex 4, France 2 Univ de Toulouse; INSA, LAAS; F-31400 Toulouse, France {vshukla, gauriol, cbaron, xzhang}@laas.fr Copyright © 2012 by Vikas Shukla, Guillaume Auriol, Claude Baron and X. Zhang Published and used by INCOSE with permission. Abstract. Proper management of requirement traceability information is vital for the project success. Often, it is debatable what to trace and how, without burdening the engineer with useless information. Requirement engineering in context of hardware intensive systems employs different techniques for traceability recovery, and management. In this paper, we have tried to address the problem of requirement traceability in context of hardware intensive systems’ requirement engineering. We have classified the information, which needs to be traced in eight categories, and distinguished their usage in various systems engineering activities throughout the project lifecycle. We have tried to specify the degree of granularity of information at various levels, and their relationships between various levels. We used SysML to present our approach through an example. Keywords: Requirement engineering, requirement traceability, relationships, SysML Introduction The requirement traceability is an indispensable for high quality systems design process. Various systems engineering norms like: ISO/IEC 15288 (ISO and IEC 2008), EIA-632 (EIA), IEEE-1220 (IEEE), or INCOSE Systems engineering handbook (INCOSE), demands it in one or other way in project life cycle. Although, seen as quality quotient requirement traceability serves too many other necessary activities: change impact analysis, verification and validation, configuration management etc. Gotel et al. (Gotel, 1994) define requirement traceability as “is the ability to describe and follow a requirement in both forward and backward direction in a software development life cycle”. Similarly, EIA-632 specifies that, requirement traceability is instituted for tracking requirements from the identification of acquirer and other stakeholder requirements to the system technical requirements, logical solution representations, physical solution representations, derived technical requirements, and specified requirements. Requirement traceability activity consists of three parts: traceability recovery, traceability maintenance, and traceability usage. Traceability recovery process is the filtering out the relationships and links that exist between the various artifacts based on the signature of various artifacts. Traceability recovery process takes in as input, a set of documents and artifacts, and gives an output of traceability matrix or traceability graph representing the existing relationships between various artifacts. There are various three types of traceability recovery techniques: manual, semi-automatic, and automatic. Traceability recovery technique acts as a crucial factor for the quality of traceability information available for the developed system. Manual traceability recovery can provide very high quality of traceability, but is plagued with scalability issues and other organizational problems. Semi-automatic and automatic techniques have technical limitations of precision and recall. The requirement engineering literature 1182