Comprehensive Requirement Traceability Information, and Relations in Project Life-Cycle

Vikas Shukla1, 2, Guillaume Auriol1, 2, Claude Baron1, 2, Xinwei Zhang1, 2 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

identifies various traceability recovery techniques like based on: information retrieval (De Lucia, 2007), policy based (Murta, 2006) and many other types of traceability techniques. Traceability maintenance process is the mechanism, through which the existing traceability relationships between the artifacts are updated. Traceability maintenance is necessary and it increases the usability and dependability of the traceability information. There are various traceability maintenance schemes in literature (Cleland Huang, 2003; Drivalos-Matragkas 2010, Shukla 2011). The previous literature available about requirement traceability gives various data which should be stocked as traceability information (Hong, 2010). These data are linked to the artifacts and maintained throughout the life cycle for the traceability. We have contributed to the existing state of art by proposing a framework to link the traceability information at the various levels of project cycle. We have categorized the traceability data in eight categories. We have further classified them in sets, which are used for a particular dedicated activity (change impact analysis, configuration management etc.) later in the product life cycle. We have shown that, using these particular set of data can help to carry out activities like, change impact analysis, configuration management, etc., much rapidly by limiting the search domain. The paper is organized as follows. Next section presents the problem definition and highlights the relationship enigma between the various levels of project cycle. The following section discusses the relevant previous works. This is followed by the eight categories of traceability data, their classification in to various sets according to their suitable role. Next section presents a simple example using SysML. A discussion follows up about the various issues linked with the classification. Finally, we present the conclusion and prospective works.

Problem Definition
The literature of requirement engineering identifies traceability as essential activity for successful project development. Requirement traceability problem can be classified in to many categories. Gotel (Gotel, 1994) classify them into pre-requirement traceability and post-requirement traceability, Weiringa (Weiringa, 1995) identifies it as upward and downward traceability, Pinheiro (Pinheiro, 2003) classifies it into inter-requirement and extra-requirement traceability. The literature discusses profoundly about traceability but at the same time lacks about what should be traced and at what level. Most of the traceability literature considers the software intensive systems as the primary subject for study. In fact non-software intensive systems seem to be ignored. Hence, there is a lack of comprehensive knowledge about requirements traceability in context of hardware intensive systems (a major part of systems engineering projects). The relationship between the traces at various levels of project cycle is still not-specified. Requirements are traced in both directions upward and backward, at various levels. It is important to trace them in such a manner that, they are coherent globally. The problem is how to trace them in such a manner that, they are coherent with each other at various levels. At the same time it is usually not clear what should be traced at various levels; how to know that traceability at superior level is coherent with lower levels or not? The clarity about data at these levels provides a platform to system engineer to detect anomalies very easily at various levels. Requirements are traced in both directions upward and backward, at various levels. It is important to trace them in such a manner that, they are coherent globally. It is also important to know the granularity of information at various levels. How granular should be information at each level. Also, the relationship between the quantity, and granularity of information between two successive levels of a project cycle should be known. This is important as, it provides coherent view of development history of project. In other words, it tells only what is needed at a particular level and hides the unnecessary detail.

Figure 1. V-model of the Systems Engineering Process The second problem about the requirement traceability is about their usage. Whenever a product is developed, it is natural to have evolving requirements. A slight change in one system requirement can cause ripple effect in the entire system being developed. For carrying out such sorts of activities, system engineer should be aware of the interactions, and dependencies which exist in system. This type of activity is usually very tedious and requires resources. The result is that, vast amount of resources are spend to locate relatively small amount of information because of poor management of information. A better management of data can help to reduce this wastage of resources. Figure 1 above shows V-model of the systems engineering process considered in this work.

Previous Works
The existing requirement engineering literature provides lots of work to mention which information should be traced. Ramesh et al. (1995, 1998, 2001) have identified six questions that the trace must answer about an artefact: what, who, where, how, when and why. What information is recorded by the artefact? Who has created or updated the artefact and documented the information? Where has the information come from? When has the artefact been created, modified, or evolved? Why has the artefact been created, modified or evolved? How the information is represented (formal or informal texts, graphics, etc.)? Sommerville et al (Sommerville and Sawyer 1997, 226-227) mention about six types of traceability information to be traced: requirements-sources traceability, requirements-rationale traceability, requirements-requirements traceability, requirements-architecture traceability, requirementdesign traceability, and requirement interface traceability. Although, they provide us various types of traceability information which should be maintained, they do not precisely what should be maintained. Sommerville with respect to software engineering (Sommerville 2011, 113) mentions three types of traceability information to be maintained: source traceability, intra-requirements traceability, and design traceability. Dick (Dick, 2002) advocated richer traceability relationships, making use of textual rationale and propositional logic in the construction of traceability arguments allowing deeper kinds of analysis. (Spanoudakis and Zisman, 2005) have defined software traceability with set of relationships between various software artefacts like: overlap, satisfiability, dependency, evolution, generalisation, conflict, rationalisation and contribution. They advocate defining and implementation of traceability in terms of these relationships but they have not mentioned the exact data which should be mapped to corresponding relationships. Pinheiro (Pinheiro, 2003), describes functional and non-functional tracing, advocating tracing analysis models, design models, process models, organisational models, reasons,

context, and decisions, etc. The various traceability recovery techniques based on information retrieval like, vector space models (VSM), latent semantic indexing (LSI), etc., can link the artefacts, but they lack the exact precision about the information and relationship between the artefacts. In the next section, we present an approach which derives motivation from the various previous works and tries to complete them in one or other aspect.

Comprehensive Traceability
The proposed approach for comprehensive traceability encompasses both the relations and data of the artefacts to be traced. The earlier approaches defined the traces either with the relationships with various types of relationships or associated them with certain data. In the context of project cycle, we try to define the traceability at various levels of project cycle and provide comprehensive relationships between the traceability information at two levels and the traceability itself. We would like to define the term artefact. In this paper we use the term artefact for an entity, which is produced during the course of project development, or is used during the development process or later and is important for success of project. Usually, requirements traceability can be implemented in two ways: forward or reverse direction. Forward trace implementation means, traceability is established to the artefacts progressively with project development. While, in reverse direction traceability is established with the artefacts once the system development is over. We prefer the first approach, forward traceability. In our approach requirements are traced to various artefacts in two steps. First, the requirements are traced to various system project stages and then they are traced between the various levels, providing a comprehensive traceability to each requirement. For facilitating this comprehensive traceability, we have defined eight fields that a trace should be composed of: Why, What, When, How, Where, Verify, Who, Relation. The terminology may seem similar to other works, but it is different from the other mentioned works.

Composition of Trace
As mentioned earlier the trace is identified by the following eight terms as shown in Figure 2. Each trace is unique and is comprised of the following eight blocks: Who, What; Why; Where; When; Verify; How; Relation. The value of these blocks can be single for some blocks and can be multiple for others. Each block has a unique role to play, which is important for successful accomplishment of requirement traceability in the system. The value of these blocks changes with the location in the project cycle. A trace in an upper stage of life cycle will have different types of parameters. A block at a higher level will contain more abstract information than a block at lower level. This allows visualizing the information which is necessary and hiding the unnecessary detail, depending on the type of user. Among all the blocks, Relation block is composite block. The subsets of these blocks are used to play different roles, to analyse various challenges faced by the system and development team during and after the project development. This is explained in next subsection. Who block provides the information about the primary origin of the stakeholders of the requirement. It can have single or multiple values. Why block provides the information about the rationale for existence of the corresponding requirement. This in hence, provides the pre-requirement traceability.

Figure 2. A Trace Block Where block provides the location of the implementation of the requirements in the system and hence provides fine grain traceability. What block provides the information about the role of the requirement, the function with which it is associated. When block, provides the temporal information about the implementation of the requirement in the system. How block provides the information about the mode of implementation of the requirement. It reveals the information about the realization of the requirement in system. Verify block provides the information about, how it can be proven that the associated requirement is successfully implemented in the corresponding system. Relation block provides the interesting feature for the requirement to stock it relationships with various existing requirements at the same level of project life cycle. As mentioned before, this block is a composite block, which contains a set of various types of relationships with the other existing requirements. The various requirements at same level are analyzed and the identified relations are suitably marked in the block. A relation block is shown in Figure 3.

Figure 3. A composite relation block The composite structure of a Relation block can contain various identified relationships. The major identified relationships are shown as above. A requirement may overlap, satisfy, depend, generalize, conflict, refine, rationalize or contribute other requirements (Spanoudakis and Zisman, 2005). There may be relationship or may not be among the various requirements. The same requirement may have more than one relationship with other requirement. Requirements at next level may directly inherit the Relationship block from the upper level. There can be two

refined requirements at the lower stage in conflict, while at upper stage they were at overlapping relationship. To determine these relationships there can be various possibilities, one can be the manual entry by the system engineer, the other technique can be the axiomatic detection or rule based detection which is explained in next block. Carefully designed axioms can help to establish the right set of relations among the various requirements. The more the number of relations can be found between the requirements, the better it is for the system. A sufficiently good number of relations can provide the developer the useful information about the interaction between the various requirements. Hence, it can help in various other systems activities like, change impact analysis, configuration management, system upgradation or maintenance.

Blocks with Respect to Various Levels in V-Model of Project Cycle

We consider the standard V-Model of project cycle, as shown in Figure 1. This section assumes only two types of requirements: Functional and Non-functional. Functional requirements are the functionalities that are expected out of the systems. Non-Functional requirements are all the other requirements, mostly qualitative requirements with -ities as suffix. This section presents the value of trace blocks at various levels in the V-Model. At the first level of V-Model, i.e., User Requirements elicitation, the what block should have data about the functionality that is expected from the system. Eventually, as the non-functional requirements are also implemented as some functionality in the system they should be treated as functional requirements. In the end of user needs level, the user needs are recorded and what block is filled with the key functionality associated with the corresponding user need. The value of the what block at this level is singular entity. The who block value is multiple and contains the name of corresponding stakeholders responsible for the requirement. The why block gathers the rationale behind the requirements, it has multiple values. Why block values are retained throughout the v-model at various levels. Hence, this quality can be later used as for linking trace blocks throughout the life-cycle (Shukla, 2012). The where and how blocks at this stage occupy vague values, which the analyst assumes to locate in future. The values can be left unfilled also. The values are filled later at other stages when the features are designed and decisions are made about the components in system. Verify block contains the information about the planned validation test for the user requirement. When block contains the abstract temporal information about the planned requirement implementation, which is in proportion with the duration of project development. As, at this stage the exact functional requirements are not very precise, the relationship blocks for them empty, while the qualitative or non-functional requirements of system can have relationships a prior, for example, in case of an auto-mobile speed and body weight can have a prior relationships of conflict and dependency. At the System requirements derivation level all the user requirements functional or non-functional are converted in to functional system requirements. The what block of each requirement should mention the name of operation that is expected from it. The who block contains the name of the user requirement which needs the functionality. The why block gathers the rationale behind the system requirement, which is similar to the higher level user requirement, it can have multiple values. The how block at this stage still occupies the vague values or null, they can only be filled at later stage. The where blocks still occupies vague values. The when blocks at the end of systems requirements phase contain the temporal information about the implementation of the operations. The verify block contains the information about the planned validation tests for the system requirements. The relationships at this level start to be organized, the refinement relations are analyzed for various user requirements and system requirement, who block is used to determine the various relationships.

As, at the architecture and analysis level, more fine work about requirements is carried out, various solutions and concepts are proposed for various implementations of requirements. At this stage every artifact introduced or produced during the development process is identified with corresponding requirements, therefore the who block in this level can have multiple values. The who block contains the information of the various system level requirements which lead to the artifact. Similarly, the why block at this level can have various rationales linked to the artifact with various system requirements. What block at this level contains the exact functionalities expected from the component. As, components at this stage start falling in to shape, an approximate structure of the system is known by the end of this level. Design engineers start having presumptions about the location implementations of the system. The where block, contains the location of the component in the system. The verify block at the end of this stage points to the various the sub-system tests. The relationships block contains the various relationships between the sub-systems at the end of this stage. These relationships are carried up to the higher levels of system requirements and user requirements, and the vague values of the relationships at these levels are replaced by the more suitable values determined by the analysis at architecture and analysis level. At the end of this level the concept selection for various sub-systems component is made and decision-making information is stocked as why in various system component levels. Detail design step starts with detailed inputs from the architecture and analysis stage, the who block at this stage should contain the information about the refined requirement from the systems requirement stage and the information about the selected concepts at analysis and architecture stage. At this stage the selected concepts are explored and developed. Why block at this stage contains the various rationales with which each component is linked, at this level we know the exact interactions of the components. The what block contains the exact functionality of each component similar to the what block at superior level. How block at this level contain the precise information about the components and their working principles. The verify block contains the information about the unit and integration tests of the corresponding components which are planned together with the detailed design. The relationships blocks for the components at this stage evolve as the interactions between the various components are known at this stage; they are filled with respect to various other interacting components (requirements) and are also propagated to the higher-level verify blocks of analysis and architectural stage, system requirements and user requirements stage. The where block at the end of this stage contains, the very precise location of the implementations of the requirements in the system. The when block at this stage contains the precise temporal information about the implementation of the component, it may also contain the temporal dependencies with the other components (requirements). At the end of detailed design the systems engineer has all the necessary data and valid simulation results to go ahead finally with the selected concept. The implementation phase is carried based on the results obtained from detailed design. This phase finally takes input from the detail design and other previous phases and executes the project implementation plan. The data in various blocks should remain same as in detailed design stage in who, what, why, verify and where blocks. The values in when, how, and relationship block depend on the project execution plan, the various resource allocation strategies and the temporal relationships between them before execution of the project. Once, the project is executed the, all the desired information is collected and stocked: the mistakes, violation of temporal constraints of the implementation and their reasons, etc. At the end of the implementation phase, the product is available in form of various sub-systems, following to this, unit and integrated testing is carried out of the product. At this stage we have a system in which, each system requirement is allocated to one or more sub-system. So, the who, what, why, verify, where, when, how, and relationship

blocks at this level have practically the same information as of detailed design phase. Similarly, the sub-systems verification has all the trace blocks in accordance with the analysis and architectural plan of the system. The three blocks where, when and relationship may not contain any value at this stage. They should identify the exact component with the very precise system requirements and the verification process as per the verification strategy used by the team. The who block should give the data about the system requirements and the verification strategy, what block specifies the verification process and why provides the rationale behind the system requirement, and how contains the data about the procedure for verification, verify gives the information about verification model proving that verification model is valid. For the system verification plan, the trace block contains the similar information as previous sub-system verification plan but at a more abstract level. The trace blocks at system validation plan validate that each user requirement is implemented in to the system. The who block at the system validation plan point to various user needs (functional and non-functional). What block specifies the validation process and why block provides the rationale behind the user requirement. How contains the information about the procedure of the validation plan of the user needs in system. Where localizes every user requirement in the system. There can be relationship between the validation plans of different requirements. Verify block shows the information about the validity of the validation process about the truthfulness and end user acceptance of validation plan. When trace block may have void value, or the temporal order of execution of the system validation plan.

A SysML Example
We present here a short example of requirement traceability management using SysML following our prescribed approach. For ease of comprehension and usage, we try to trace three requirements of a Golf-car. We show the example using Omg-SysML (SysML) requirement diagrams drawn on Topcased Editor (Topcased). The end user needs a Golfcar. He needs a more ecological, comfortable and easy to maintain Golf-car than the contemporary ones. So, the user requirements are collected, as shown in Figure 4. The trace block for each requirement is shown as an associated comment in SysML requirement diagram called CAR_REQ.

Figure 4. Requirement and traceability at user requirements level Each user requirement is associated with trace blocks linked using a comment in the requirement diagram. Some of the values in the trace blocks are left void owing to the initial state of the system. These values would be filled in at later stages once the all the functional and non-functional requirements are discovered, refined and their interaction is known. The

ecological user requirement is shown to be divided in to three parts: propulsion, body and frame, and solar energy harvesting. At the end of user requirements level, the various validation test cases are planned, to validate the user requirements. If the client agrees to test cases, then the next step of project development is carried out. The client should accept the proposed test cases: Plan_Test_Pol, Plan_Test_Comf, and Plan_Test_Maintain.

Figure. 5. Ecological requirement at system level requirements Figure 5 shows the ecological requirement at the system level requirements. We try to trace only one requirement throughout the life cycle, owing to the space limitation.

Figure 6. Architecture and Analysis Figure 6 shows the architecture and analysis traceability for the propulsion mechanism as

shown above. Various concepts are proposed for the propulsion like: electric motor, petrol engine, and diesel or gas engine. Figure 7 shows the detail design of propulsion mechanism with the electric motor being selected as the final concept. The detail analysis of the propulsion interaction mechanism is shown in Figure 8. We do not show the complete traceability owing to limited space constraints.

Figure 7. Detail Design Propulsion

Figure 8. Detail design propulsion interaction mechanism

Figure 9, below shows the system validation traceability mechanism using use case diagram.

Figure 9 System validation

Roles of the Trace Block in Other Activities

The roles of various trace blocks can be defined to solve many other activities during the project life cycle or later during deployment: change impact analysis, configuration management, product upgrades or updates, maintenance, component reuse, etc. Usually, there is vast amount of information, which needs to be properly analyzed before carrying out these activities. A classification of such information helps to carry out these tasks rapidly. Change impact analysis (CIA) is an activity carried out to measure the ripple effect on the system, brought by some changes in the existing components of the system or because of some system upgrades. The trace table elements can be used to calculate this change impact analysis very efficiently. Primarily, only the relationship, who, what, why, and how blocks of a component need to be analyzed to calculate the CIA brought, instead of searching through the length and width of the documents. System upgrade or update involves the activities which enhance the functional or non-functional capacity/capability of the system. This is usually carried out after the delivery of the product. Usually, involved with the large size products, for which enhancing capacity of the system is much cheaper than buying a new system with desired capability, for example aircrafts, ships, or buildings. System upgrading is very close to CIA, so trace block involving CIA are needed and additionally where block. Product reuse of a component involves studying only the why, how, and what block of a component in the traceability information. The information gathered provides the functionality of the system and its procedure and the various reasons for its usage or recycling. This can also be very helpful in finding the reusable components in the system. Maintenance process involves the activities, which intend to avoid the system degradation or activities which restore the degraded system state to the ideal or near ideal state, so that all the functionalities expected from the systems can be delivered to user. Maintenance process of a component needs minimally the relationship, what, and how blocks.

Configuration management (CM) is needed for large products, when the different customers need different functionalities out of the system. Their different functional or non-functional product needs are addressed individually. The various functionalities are implemented as various components, which can be integrated to the same system. To carry out these CM activities all the blocks relationship, who, what, why, where, verify, when and how are needed. As, it is a highly complex task to maintain the different configurations of the same system , the traceability information in form of blocks can provide valuable input to the various CM tools. Understanding system is necessary for end user from various perspectives to evaluate the system and to quickly assess the system. The data blocks relationships, what, why, where, and how are needed to understand the system. Prioritizing requirements can also be done using the why, what, and who blocks. These blocks provide sufficient information to give the priority to the requirements using the functionality and rationales. Measuring project progress can be done using the why, what, who, where and when blocks. The progress in project implementation and accountability is achieved using the above mentioned blocks. This can save valuable analyst time in predicting the system completion or failure or delays in system delivery. Manual generation or system documentation is an important activity to define the various mode of utilization of system, doing this activity necessitates proper understanding of sub-systems, their constraints, etc. The relationships between the various components and their interaction should be known. The who, what, why, where, and relationship blocks are needed to create the proper manuals. These blocks can also help to rapidly analyze and measure the adequateness of the manuals or system documentation.

Discussion
Our approach used the previously defined elements in literature (Ramesh et al., 1995; Ramesh, 1998, Ramesh and Jarke, 2001; Spanudakis and zisman, 2005). In the previously existing literature, two types of traceability patterns can be easily identified. First pattern involves the identification of the various data elements to be traced throughout the life cycle. The second pattern involves with the tracing of the relationships between the various components of the system being developed. In our approach, we have tried to amalgamate the two previous approaches and gave a mechanism for traceability at various levels of V-model of project life cycle. Our approach remains in conformance with the many existing systems engineering norms like EIA-632, ISO/IEEE 15288. We have shown that our approach can be easily supported by many of the existing tools, which support modeling languages (UML, SysML). Implementation of our technique in a fully automatic manner based on information retrieval seems rather difficult owing to the many technical issues linked with requirement elicitation and analysis phase. The roles of the trace blocks propose interesting aspects to rapidly carry out the various systems engineering activities. Our approach provides the platform to find the interaction between the various system components. Any artefact can be traced in both forward and backward direction. Our approach considers that the non-functional requirements are implemented as by first converting them in to functional requirements, and hence as, some functionalities in the system. The various contemporary existing tools for requirement engineering which claim to provide fully automatic requirement traceability are based on information retrieval techniques. They may claim to trace links between two components but still it takes efforts to determine the types of relationship existing between the two entities. The information retrieval based techniques require a prior existence of all the documentation to trace the various links i.e. it is a

backward traceability approach. Our approach on contrary is a two-step approach, first step with the development in forward direction, descending the V-Cycle; second step in backward direction ascending the V-Cycle. Each artefact can be traced to level just before and after the element. This allows formation of chains of relationship and hence traces providing coherent traceability of artefact from rationale till system validation. The relationship definition aspect of our approach can use mathematical axioms, like defined in earlier works (Spanaudakis et al., 2004) or they can be also implemented as the result of analysis carried out during the architecture and analysis phase and during the details design phase. One of the drawbacks of our approach is its manual creation of trace blocks, but we look forward to do it semi-automatically. This aspect is discussed in next Section.

Conclusion and Future Work

We presented in this paper a comprehensive approach for the requirement traceability for a systems engineering project. We gave the distinction between the requirement traceability for software intensive system and hardware intensive systems. We used the existing literature for comprehensive requirement traceability. We identified trace blocks to have eight distinct types of values, which can provide the traceability, throughout the V-model of project development. We provided a platform to link these trace blocks with various relationships to the artefacts generated throughout the life-cycle and the requirements. We have seen that a comprehensive and reliable traceability link establishment is a two way process: forward and backward. Requirement traceability information remains a valuable entity for the enterprises involved in huge projects where new projects may find inspirations from the earlier projects. Requirement traceability information remains valuable even after the project ends and the product is removed from the service. We have shown that the different set of requirement traceability block can be used for different product management activities: configuration management, change impact management, maintenance, system upgradation, product reuse, release management, system comprehension, etc. Such a use of set of trace blocks eases these tedious jobs, as the required data is easily available, and ultimately lowers resource consumption. The fully reliable automation of comprehensive traceability in a systems engineering project remains a challenging activity yet for the requirement engineering. The information retrieval based traceability recovery policies still have issues with complete recall and a satisfactory precision. We have seen that requirement traceability is iterative process. A semi-automatic approach is better choice for carrying out requirement traceability, with suitable human involvement. A carefully carried out requirement traceability activity is a huge source of knowledge for the entire enterprise, for the current and future projects including the entire life cycle of the product. We plan to design an algorithm which can automatically determine the relationships between the various requirements. Currently, we have not developed any tool, which can transform raw data in to very precise trace blocks. This is envisaged in near future to integrate in our tool called ISDT (Shukla, 2012).

References
ISO and IEC (International Organization for standardization and International Electrotechnical Commission). 2008. ISO/IEC 15288:2008. Systems and Software Engineering Systems life cycle processes. Electronic Industries Alliance (EIA), ANSI/EIA 632, Processes for engineering a system, EIA, Arlington, VA, 1998).

Institute of Electrical and Electronics Engineers (IEEE), IEEE 1220, IEEE trial-use standard for application and management of the systems engineering process, IEEE, New York, 1994). INCOSE. 2010. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities. Version 3.2. Revised by M. Krueger, D. Walden, and R. D. Hamelin. San Diego, CA (US): INCOSE. Gotel, O.C.Z., and Finkelstein, C.W., An analysis of the requirements traceability problem, Proceedings of the First International Conference on Requirement Engineering (ICRE 1994), pp. 94-101, 18-22 Apr-1994, doi: 10.1109/ICRE.1994.292398. Cleland-Huang, J., Chang , C.K., Christensen , M., Event-based traceability for managing evolutionary change, IEEE transactions on software engineering, vol.29, no.9, pp. 796- 810, Sept. 2003, doi: 10.1109/TSE.2003.1232285. Drivalos-Matragkas. N., Kolovos. D.S., Paige. R. F., and K.J. Fernandes., A state-based approach to traceability maintenance, Proceedings of the 6th ECMFA Traceability Workshop (ECMFA-TW '2010). ACM, New York, NY, USA, pp. 23-30. doi=10.1145/1814392.1814396. Hong, Y; Kim, M; Lee, S-W., Requirements Management Tool with Evolving Traceability for Heterogeneous Artifacts in the Entire Life Cycle, Proceedings of the Eighth ACIS International Conference on Software Engineering Research, Management and Applications (SERA 2010), pp. 248-255, 24-26 May 2010 doi:10.1109/SERA.2010.39. Dick, J., 2002. "Rich traceability", In Proceedings of Automated Software Engineering, Edinburgh, Scotland. De.Lucia, A., Fausto, F., Rocco, O., and Genoveffa, T., Recovering traceability links in software artifact management systems using information retrieval methods, ACM Trans. Softw. Eng. Methodol. 16, 4, Article 13 (September 2007). doi=10.1145/1276933.1276934. Murta, L.G.P.,van der Hoek, A., Werner, C.M.L., ArchTrace: Policy-Based Support for Managing Evolving Architecture-to-Implementation Traceability Links, Proceedings of the 21st IEEE/ACM International Conference on Automated Software Engineering (ASE '06), pp. 135-144, 18-22 Sept. 2006 doi: 10.1109/ASE.2006.16. Wieringa, R .J. An introduction to requirement traceability. Technical report IR-389, faculty of Mathematics and Computer Science, University of Vrije , Amsterdam, September 1995. Pinheiro, F.A.C.2003. Requirements traceability. In Sampaio do PradoLeite, J.C., Doorn, J.H. (eds.) Perspectives on Software Requirements, pp. 93113. Springer, Berlin (2003). Ramesh, B.1998. Factors influencing requirements traceability practice. Commun. ACM 41, 12 (December 1998), 37-44. DOI=10.1145/290133.290147 Ramesh, B. and Jarke, M. 2001. Towards reference models for requirements traceability. IEEE Transactions on Software Engineering. 27(1), 58-93. Ramesh, B., Powers, T., Stubbs, C. and Edwards. M. 1995. Implementing requirements traceability: a case study. In Proceedings of the Second IEEE International Symposium on Requirements Engineering (RE '95). IEEE Computer Society, Washington, DC, USA. SysML.2011. OMG Systems Modeling Language. Accessed November 7, 2011. www. omgsysml.org Sommerville, I. and Sawyer, P. 1997. Requirements Engineering: A good practice guide (1st edition). John Wiley & Sons, Inc., New York, USA. Sommerville, I. 2011. Software Engineering (9th Edition). Pearson.

Spanoudakis,G., Zisman, A., Prez-Minana .E. and Krause. P. 2004. Rule-based generation of requirments traceability relations. The Journal of Systems and Softwares. 72 (2004). pp. 105-127. Spanoudakis, G. and Zisman, A. 2005. Software Traceability: A Roadmap. In handbook of Software Engineering and knowledge Engineering, Vol. 3: Recent Advancements, (ED) Chang S.K., World Scientific publishing Co. Shukla, V., Auriol, G., and Baron, C. 2011. A Graph-Based Requirement Traceability Maintenance Model, Proceedings of the sixth international conference on software engineering advances (ICSEA 2011), pp.161-165, 23-28 October 2011, Barcelona, Spain. Shukla, V., Auriol, G., and Baron, C. 2012. Integrated Requirement Traceability, Multi-view Modeling, and Decision-Making. In the proceedings of the sixth IEEE International Systems Conference, 19-23 March 2012, Vancouver, Canada. Topcased.2011. The Open-Source Toolkit for Critical Systems. Accessed November 7, 2011. www.topcased.org

Biography
Vikas Shukla is a PhD candidate at the department of electrical and computer engineering of the Institut National des Sciences Appliques de Toulouse (INSA-Toulouse). He received his M.E degree in computer engineering in the year 2010 from INSA-Toulouse. His PhD topic is about, Comprehensive approach for modeling the conception of a complex system, its management, implementation and validation. Beyond system modeling his main interests lie in the area of requirement engineering and decision engineering. He is teaching assistant at Department of electrical and computer engineering at Institut National des Sciences Appliques de Toulouse. He is equally associated with LAAS-CNRS to carry out research work. Guillaume Auriol received the M.E degree from ENSICA-Toulouse, a French graduate school of Aeronautics, in 2001. He received his PhD degree in the year 2004 from the Institut National des Sciences Appliques de Toulouse (INSA-Toulouse). He joined INSA-T in 2005 to resume his teaching career. He is a member and an activity leader of AFIS (Affiliation to INCOSE). He is currently, associate professor at Department of electrical and computer engineering of Institut National des Sciences Appliques de Toulouse (INSA-Toulouse), France. He is associated with LAAS-CNRS to carry out his research in systems engineering. Beyond this his main interests lie in the area of computer networks and embedded systems. Claude Baron received her M.E degree in industrial informatics in the year 1992 from Institut National des Sciences Appliques de Toulouse (INSA-Toulouse). She received her PhD degree in automation and industrial informatics in 1995 from INSA-Toulouse. She is professor at Department of electrical and computer engineering at Institut National des Sciences Appliques de Toulouse. Her areas of interest are dependable computing, embedded systems, and real time systems. Apart from this she is also interested in requirement engineering.