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

1

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

These data are linked to the artifacts and maintained throughout the life cycle for the traceability. etc. Also. their classification in to various sets according to their suitable role. they are coherent with each other at various levels. How granular should be information at each level. The paper is organized as follows. 2006) and many other types of traceability techniques. 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. In other words. Next section presents a simple example using SysML. 2010). Gotel (Gotel. 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. Requirement traceability problem can be classified in to many categories. Traceability maintenance process is the mechanism. Requirements are traced in both directions upward and backward. configuration management etc. it provides coherent view of development history of project. they are coherent globally.. Most of the traceability literature considers the software intensive systems as the primary subject for study. The relationship between the traces at various levels of project cycle is still not-specified. The problem is how to trace them in such a manner that. Shukla 2011). Drivalos-Matragkas 2010. much rapidly by limiting the search domain. We have further classified them in sets. A discussion follows up about the various issues linked with the classification. The literature discusses profoundly about traceability but at the same time lacks about what should be traced and at what level. and granularity of information between two successive levels of a project cycle should be known. change impact analysis. Next section presents the problem definition and highlights the relationship enigma between the various levels of project cycle. using these particular set of data can help to carry out activities like. 2003. Problem Definition The literature of requirement engineering identifies traceability as essential activity for successful project development. the relationship between the quantity. . Pinheiro (Pinheiro. 2003) classifies it into inter-requirement and extra-requirement traceability. 1994) classify them into pre-requirement traceability and post-requirement traceability. we present the conclusion and prospective works. Finally. 1995) identifies it as upward and downward traceability. It is important to trace them in such a manner that. Weiringa (Weiringa. policy based (Murta. This is followed by the eight categories of traceability data. It is also important to know the granularity of information at various levels. There are various traceability maintenance schemes in literature (Cleland Huang. they are coherent globally.identifies various traceability recovery techniques like based on: information retrieval (De Lucia. Requirements are traced in both directions upward and backward. which are used for a particular dedicated activity (change impact analysis.) later in the product life cycle. at various levels. there is a lack of comprehensive knowledge about requirements traceability in context of hardware intensive systems (a major part of systems engineering projects). at various levels. through which the existing traceability relationships between the artifacts are updated. It is important to trace them in such a manner that. The following section discusses the relevant previous works. At the same time it is usually not clear what should be traced at various levels. The previous literature available about requirement traceability gives various data which should be stocked as traceability information (Hong. We have shown that. it tells only what is needed at a particular level and hides the unnecessary detail. In fact non-software intensive systems seem to be ignored. Hence. We have categorized the traceability data in eight categories. configuration management. Traceability maintenance is necessary and it increases the usability and dependability of the traceability information. 2007). This is important as.

and design traceability.)? Sommerville et al (Sommerville and Sawyer 1997. where. satisfiability. 226-227) mention about six types of traceability information to be traced: requirements-sources traceability. For carrying out such sorts of activities. generalisation. describes functional and non-functional tracing. they provide us various types of traceability information which should be maintained. evolution. vast amount of resources are spend to locate relatively small amount of information because of poor management of information. Dick (Dick. advocating tracing analysis models. conflict. A better management of data can help to reduce this wastage of resources. The result is that. intra-requirements traceability. when and why. Figure 1 above shows V-model of the systems engineering process considered in this work. Pinheiro (Pinheiro. modified. (1995. (Spanoudakis and Zisman. and dependencies which exist in system. V-model of the Systems Engineering Process The second problem about the requirement traceability is about their usage. system engineer should be aware of the interactions. or evolved? Why has the artefact been created. Ramesh et al. modified or evolved? How the information is represented (formal or informal texts. 2001) have identified six questions that the trace must answer about an artefact: what. 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. requirements-architecture traceability. Whenever a product is developed. organisational models. 2002) advocated richer traceability relationships. design models. requirement–design traceability. A slight change in one system requirement can cause ripple effect in the entire system being developed. and requirement –interface traceability. process models. they do not precisely what should be maintained. who. how. 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. requirements-rationale traceability. dependency. 1998. 113) mentions three types of traceability information to be maintained: source traceability. 2005) have defined software traceability with set of relationships between various software artefacts like: overlap.Figure 1. rationalisation and contribution. Although. 2003). Previous Works The existing requirement engineering literature provides lots of work to mention which information should be traced. Sommerville with respect to software engineering (Sommerville 2011. etc. . This type of activity is usually very tedious and requires resources. reasons. graphics. making use of textual rationale and propositional logic in the construction of traceability arguments allowing deeper kinds of analysis. requirements-requirements traceability. it is natural to have evolving requirements.

Among all the blocks. This in hence. but it is different from the other mentioned works. forward traceability. which is produced during the course of project development. latent semantic indexing (LSI). etc. Each trace is unique and is comprised of the following eight blocks: Who. The various traceability recovery techniques based on information retrieval like. A trace in an upper stage of life cycle will have different types of parameters. Usually. we have defined eight fields that a trace should be composed of: Why. First.. we present an approach which derives motivation from the various previous works and tries to complete them in one or other aspect. . In the context of project cycle. Relation. What. ‘Relation’ block is composite block. provides the pre-requirement traceability. Who block provides the information about the primary origin of the stakeholders of the requirement. What. In this paper we use the term artefact for an entity. This allows visualizing the information which is necessary and hiding the unnecessary detail. In the next section. The subsets of these blocks are used to play different roles. or is used during the development process or later and is important for success of project. For facilitating this comprehensive traceability. Why. Why block provides the information about the rationale for existence of the corresponding requirement. requirements traceability can be implemented in two ways: forward or reverse direction. can link the artefacts. but they lack the exact precision about the information and relationship between the artefacts. A block at a higher level will contain more abstract information than a block at lower level. The terminology may seem similar to other works. Where. Where. which is important for successful accomplishment of requirement traceability in the system. providing a comprehensive traceability to each requirement. vector space models (VSM). Each block has a unique role to play. Who. etc. and decisions. How. Relation. How.context. When. Verify. While. Forward trace implementation means. Verify. to analyse various challenges faced by the system and development team during and after the project development. We would like to define the term ‘artefact’. The value of these blocks can be single for some blocks and can be multiple for others. in reverse direction traceability is established with the artefacts once the system development is over. The value of these blocks changes with the location in the project cycle. The earlier approaches defined the traces either with the relationships with various types of relationships or associated them with certain data. the requirements are traced to various system project stages and then they are traced between the various levels. traceability is established to the artefacts progressively with project development. This is explained in next subsection. When. depending on the type of user. 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. Comprehensive Traceability The proposed approach for comprehensive traceability encompasses both the relations and data of the artefacts to be traced. We prefer the first approach. It can have single or multiple values. Composition of Trace As mentioned earlier the trace is identified by the following eight terms as shown in Figure 2. In our approach requirements are traced to various artefacts in two steps.

Figure 2. It reveals the information about the realization of the requirement in 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. provides the temporal information about the implementation of the requirement in the system. rationalize or contribute other requirements (Spanoudakis and Zisman. As mentioned before. How block provides the information about the mode of implementation of the requirement. depend. The same requirement may have more than one relationship with other requirement. A requirement may overlap. satisfy. A composite relation block The composite structure of a Relation block can contain various identified relationships. When block. A Trace Block Where block provides the location of the implementation of the requirements in the system and hence provides fine grain traceability. 2005). the function with which it is associated. What block provides the information about the role of the requirement. Requirements at next level may directly inherit the Relationship block from the upper level. A relation block is shown in Figure 3. this block is a composite block. Figure 3. There can be two . The major identified relationships are shown as above. There may be relationship or may not be among the various requirements. Verify block provides the information about. how it can be proven that the associated requirement is successfully implemented in the corresponding system. The various requirements at same level are analyzed and the identified relations are suitably marked in the block. refine. generalize. conflict. which contains a set of various types of relationships with the other existing requirements.

The ‘where’ and ‘how’ blocks at this stage occupy vague values. This section assumes only two types of requirements: Functional and Non-functional. This section presents the value of trace blocks at various levels in the V-Model. The ‘how’ block at this stage still occupies the vague values or null. it can help in various other systems activities like.refined requirements at the lower stage in conflict. ‘When’ block contains the abstract temporal information about the planned requirement implementation. 2012). while the qualitative or non-functional requirements of system can have relationships a prior. i. To determine these relationships there can be various possibilities. The ‘where’ blocks still occupies vague values. at this stage the exact functional requirements are not very precise. The value of the ‘what’ block at this level is singular entity. Hence. The values are filled later at other stages when the features are designed and decisions are made about the components in system. Functional requirements are the functionalities that are expected out of the systems. the refinement relations are analyzed for various user requirements and system requirement. The ‘who’ block contains the name of the user requirement which needs the functionality. . The ‘why’ block gathers the rationale behind the requirements. the user needs are recorded and ‘what’ block is filled with the key functionality associated with the corresponding user need. for example. ‘Why’ block values are retained throughout the v-model at various levels. in case of an auto-mobile ‘speed’ and ‘body weight’ can have a prior relationships of conflict and dependency. it can have multiple values. User Requirements elicitation. The ‘verify’ block contains the information about the planned validation tests for the system requirements. which the analyst assumes to locate in future. which is in proportion with the duration of project development. system upgradation or maintenance. change impact analysis. The ‘what’ block of each requirement should mention the name of operation that is expected from it. the ‘relationship’ blocks for them empty. The ‘who’ block value is multiple and contains the name of corresponding stakeholders responsible for the requirement. mostly qualitative requirements with ‘-ities’ as suffix. The ‘relationships’ at this level start to be organized. Hence. The ‘when’ blocks at the end of systems requirements phase contain the temporal information about the implementation of the operations.e.. it has multiple values. one can be the manual entry by the system engineer. Carefully designed axioms can help to establish the right set of relations among the various requirements. In the end of ‘user needs’ level. At the first level of V-Model. ‘who’ block is used to determine the various relationships. Eventually. As. as the non-functional requirements are also implemented as some functionality in the system they should be treated as functional requirements. this quality can be later used as for linking trace blocks throughout the life-cycle (Shukla. the other technique can be the axiomatic detection or rule based detection which is explained in next block. The more the number of relations can be found between the requirements. the ‘what’ block should have data about the functionality that is expected from the system. ‘Verify’ block contains the information about the planned validation test for the user requirement. The values can be left unfilled also. At the System requirements derivation level all the user requirements functional or non-functional are converted in to functional system requirements. Blocks with Respect to Various Levels in V-Model of Project Cycle We consider the standard V-Model of project cycle. while at upper stage they were at overlapping relationship. 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. they can only be filled at later stage. Non-Functional requirements are all the other requirements. configuration management. The ‘why’ block gathers the rationale behind the system requirement. as shown in Figure 1. which is similar to the higher level user requirement.

The data in various blocks should remain same as in detailed design stage in ‘who’. At this stage the selected concepts are explored and developed. contains the location of the component in the system. The ‘when’ block at this stage contains the precise temporal information about the implementation of the component. ‘how’. Design engineers start having presumptions about the location implementations of the system. following to this. 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 values in ‘when’.As. at this level we know the exact interactions of the components. the project is executed the. therefore the ‘who’ block in this level can have multiple values. it may also contain the temporal dependencies with the other components (requirements). So. at the architecture and analysis level. an approximate structure of the system is known by the end of this level. Similarly. ‘verify’ and ‘where’ blocks. The ‘who’ block contains the information of the various system level requirements which lead to the artifact. violation of temporal constraints of the implementation and their reasons. 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. These relationships are carried up to the higher levels of system requirements and user requirements. ‘How’ block at this level contain the precise information about the components and their working principles. 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 we have a system in which. the product is available in form of various sub-systems. ‘why’. the very precise location of the implementations of the requirements in the system. The ‘verify’ block at the end of this stage points to the various the sub-system tests. ‘verify’. 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. ‘how’. 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 ‘where’ block at the end of this stage contains. components at this stage start falling in to shape. ‘Why’ block at this stage contains the various rationales with which each component is linked. etc. ‘What’ block at this level contains the exact functionalities expected from the component. As. ‘when’. and ‘relationship’ block depend on the project execution plan. Once. The ‘relationships’ block contains the various relationships between the sub-systems at the end of this stage. Detail design step starts with detailed inputs from the architecture and analysis stage. The ‘what’ block contains the exact functionality of each component similar to the ‘what’ block at superior level. ‘what’. ‘why’. 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. system requirements and user requirements stage. This phase finally takes input from the detail design and other previous phases and executes the project implementation plan. 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. more fine work about requirements is carried out. The ‘where’ block. each system requirement is allocated to one or more sub-system. all the desired information is collected and stocked: the mistakes. At the end of the implementation phase. and ‘relationship’ . the ‘why’ block at this level can have various rationales linked to the artifact with various system requirements. the ‘who’. unit and integrated testing is carried out of the product. The implementation phase is carried based on the results obtained from detailed design. the various resource allocation strategies and the temporal relationships between them before execution of the project. ‘what’. ‘where’. The ‘relationships’ blocks for the components at this stage evolve as the interactions between the various components are known at this stage.

‘what’ block specifies the verification process and ‘why’ provides the rationale behind the system requirement. comfortable and easy to maintain Golf-car than the contemporary ones. we try to trace three requirements of a Golf-car. For ease of comprehension and usage. A SysML Example We present here a short example of requirement traceability management using SysML following our prescribed approach. the sub-systems verification has all the trace blocks in accordance with the analysis and architectural plan of the system. Some of the values in the trace blocks are left void owing to the initial state of the system. and ‘how’ contains the data about the procedure for verification. ‘Verify’ block shows the information about the validity of the validation process about the truthfulness and end user acceptance of validation plan. the user requirements are collected. ‘Where’ localizes every user requirement in the system. 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. ‘What’ block specifies the validation process and ‘why’ block provides the rationale behind the user requirement. Similarly. For the system verification plan. ‘How’ contains the information about the procedure of the validation plan of the user needs in system. The . the trace block contains the similar information as previous sub-system verification plan but at a more abstract level. or the temporal order of execution of the system validation plan. So. The end user needs a Golf–car. Requirement and traceability at user requirements level Each user requirement is associated with trace blocks linked using a comment in the requirement diagram. The ‘who’ block at the system validation plan point to various user needs (functional and non-functional). Figure 4. There can be ‘relationship’ between the validation plans of different requirements. ‘when’ and ‘relationship’ may not contain any value at this stage. He needs a more ecological.blocks at this level have practically the same information as of detailed design phase. refined and their interaction is known. ‘When’ trace block may have void value. We show the example using Omg-SysML (SysML) requirement diagrams drawn on Topcased Editor (Topcased). as shown in Figure 4. These values would be filled in at later stages once the all the functional and non-functional requirements are discovered. The three blocks ‘where’. The ‘who’ block should give the data about the system requirements and the verification strategy. The trace block for each requirement is shown as an associated comment in SysML requirement diagram called CAR_REQ. The trace blocks at system validation plan validate that each user requirement is implemented in to the system. ‘verify’ gives the information about verification model proving that verification model is valid.

We try to trace only one requirement throughout the life cycle. At the end of user requirements level. then the next step of project development is carried out. and Plan_Test_Maintain. owing to the space limitation. Architecture and Analysis Figure 6 shows the architecture and analysis traceability for the propulsion mechanism as . body and frame. and solar energy harvesting. Figure. If the client agrees to test cases. 5. Plan_Test_Comf. to validate the user requirements. the various validation test cases are planned. The client should accept the proposed test cases: Plan_Test_Pol. Ecological requirement at system level requirements Figure 5 shows the ecological requirement at the system level requirements.ecological user requirement is shown to be divided in to three parts: propulsion. Figure 6.

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

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

2001. when the different customers need different functionalities out of the system. The relationships between the various components and their interaction should be known. The second pattern involves with the tracing of the relationships between the various components of the system being developed. Prioritizing requirements can also be done using the ‘why’. some functionalities in the system. Spanudakis and zisman. The progress in project implementation and accountability is achieved using the above mentioned blocks. The various contemporary existing tools for requirement engineering which claim to provide fully automatic requirement traceability are based on information retrieval techniques. ‘what’. ‘who’. ‘verify’. Any artefact can be traced in both forward and backward direction. the traceability information in form of blocks can provide valuable input to the various CM tools..e. Our approach remains in conformance with the many existing systems engineering norms like EIA-632. To carry out these CM activities all the blocks ‘relationship’. The information retrieval based techniques require a prior existence of all the documentation to trace the various links i. The various functionalities are implemented as various components. ‘what’. Manual generation or system documentation is an important activity to define the various mode of utilization of system. Their different functional or non-functional product needs are addressed individually. ’where’. Discussion Our approach used the previously defined elements in literature (Ramesh et al. In the previously existing literature. These blocks can also help to rapidly analyze and measure the adequateness of the manuals or system documentation. First pattern involves the identification of the various data elements to be traced throughout the life cycle. 1998. The data blocks ‘relationships’. and ‘who’ blocks. and ‘relationship’ blocks are needed to create the proper manuals. ‘where’. ‘who’. ‘why’. ‘what’. Ramesh and Jarke.Configuration management (CM) is needed for large products. ISO/IEEE 15288. The roles of the trace blocks propose interesting aspects to rapidly carry out the various systems engineering activities. These blocks provide sufficient information to give the priority to the requirements using the functionality and rationales. it is a highly complex task to maintain the different configurations of the same system . and ‘how’ are needed to understand the system. 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. ‘why’. In our approach. Ramesh. which support modeling languages (UML. doing this activity necessitates proper understanding of sub-systems. ‘where’. ‘what’. Our approach provides the platform to find the interaction between the various system components. 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. two types of traceability patterns can be easily identified. 1995. 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. ‘what’. etc. Understanding system is necessary for end user from various perspectives to evaluate the system and to quickly assess the system. We have shown that our approach can be easily supported by many of the existing tools. it is a . Our approach considers that the non-functional requirements are implemented as by first converting them in to functional requirements. their constraints. The ‘who’. This can save valuable analyst time in predicting the system completion or failure or delays in system delivery. Measuring project progress can be done using the ‘why’. ‘when’ and ‘how’ are needed. ‘why’. 2005). SysML). which can be integrated to the same system. and hence as. As. ‘where’ and ‘when’ blocks.

ANSI/EIA 632. Electronic Industries Alliance (EIA). We gave the distinction between the requirement traceability for software intensive system and hardware intensive systems. 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.backward traceability approach. We identified trace blocks to have eight distinct types of values. Requirement traceability information remains a valuable entity for the enterprises involved in huge projects where new projects may find inspirations from the earlier projects. This aspect is discussed in next Section. we have not developed any tool. References ISO and IEC (International Organization for standardization and International Electrotechnical Commission). 1998). throughout the V-model of project development. for the current and future projects including the entire life cycle of the product. Each artefact can be traced to level just before and after the element. second step in backward direction ascending the V-Cycle. but we look forward to do it semi-automatically. We have seen that requirement traceability is iterative process. maintenance. Our approach on contrary is a two-step approach. Processes for engineering a system. etc. 2012). release management. product reuse. Conclusion and Future Work We presented in this paper a comprehensive approach for the requirement traceability for a systems engineering project. We used the existing literature for comprehensive requirement traceability. which can transform raw data in to very precise trace blocks. like defined in earlier works (Spanaudakis et al. Systems and Software Engineering – Systems life cycle processes. The fully reliable automation of comprehensive traceability in a systems engineering project remains a challenging activity yet for the requirement engineering. Arlington. descending the V-Cycle. VA. 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. We plan to design an algorithm which can automatically determine the relationships between the various requirements. One of the drawbacks of our approach is its manual creation of trace blocks. We have shown that the different set of requirement traceability block can be used for different product management activities: configuration management. change impact management. Currently. system comprehension. 2008. EIA. ISO/IEC 15288:2008. and ultimately lowers resource consumption. The relationship definition aspect of our approach can use mathematical axioms. The information retrieval based traceability recovery policies still have issues with complete recall and a satisfactory precision. This is envisaged in near future to integrate in our tool called ISDT (Shukla. with suitable human involvement. . first step with the development in forward direction. system upgradation. This allows formation of chains of relationship and hence traces providing coherent traceability of artefact from rationale till system validation. A semi-automatic approach is better choice for carrying out requirement traceability. A carefully carried out requirement traceability activity is a huge source of knowledge for the entire enterprise. Such a use of set of trace blocks eases these tedious jobs. which can provide the traceability. Requirement traceability information remains valuable even after the project ends and the product is removed from the service.. as the required data is easily available.

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

3: Recent Advancements. He is currently. its management. G. V. She received her PhD degree in automation and industrial informatics in 1995 from INSA-Toulouse.. . “ Rule-based generation of requirments traceability relations. pp. Barcelona.. He joined INSA-T in 2005 to resume his teaching career. a French graduate school of Aeronautics. World Scientific publishing Co. implementation and validation. Software Traceability: A Roadmap. 19-23 March 2012. He is a member and an activity leader of AFIS (Affiliation to INCOSE). He is equally associated with LAAS-CNRS to carry out research work. 2005. www. G. Shukla. pp. and real time systems. and Zisman. Shukla..topcased. Auriol. He received his PhD degree in the year 2004 from the Institut National des Sciences Appliquées de Toulouse (INSA-Toulouse). C.Spanoudakis.G. Spanoudakis. Vol. A.” Accessed November 7. His PhD topic is about. “The Open-Source Toolkit for Critical Systems. Beyond this his main interests lie in the area of computer networks and embedded systems. A. (ED) Chang S.” The Journal of Systems and Softwares. 72 (2004). in 2001. In handbook of Software Engineering and knowledge Engineering. Apart from this she is also interested in requirement engineering. Zisman. She is professor at Department of electrical and computer engineering at Institut National des Sciences Appliquées de Toulouse. and Baron. Pérez-Minana . “A Graph-Based Requirement Traceability Maintenance Model. C. V. 2011.K. and Decision-Making. France.E. and Krause. 2004. Her areas of interest are dependable computing. Topcased.” In the proceedings of the sixth IEEE International Systems Conference. P. G. 2011.E degree in industrial informatics in the year 1992 from Institut National des Sciences Appliquées de Toulouse (INSA-Toulouse). embedded systems. He is associated with LAAS-CNRS to carry out his research in systems engineering.E degree from ENSICA-Toulouse. He is teaching assistant at Department of electrical and computer engineering at Institut National des Sciences Appliquées de Toulouse.E degree in computer engineering in the year 2010 from INSA-Toulouse. Auriol. Claude Baron received her M. 23-28 October 2011..org Biography Vikas Shukla is a PhD candidate at the department of electrical and computer engineering of the Institut National des Sciences Appliquées de Toulouse (INSA-Toulouse).2011.161-165. Multi-view Modeling. Guillaume Auriol received the M.. 105-127. associate professor at Department of electrical and computer engineering of Institut National des Sciences Appliquées de Toulouse (INSA-Toulouse). Beyond system modeling his main interests lie in the area of requirement engineering and decision engineering. He received his M. Canada.. Vancouver.. 2012. Comprehensive approach for modeling the conception of a complex system. “Integrated Requirement Traceability. Spain.” Proceedings of the sixth international conference on software engineering advances (ICSEA 2011). and Baron.

Sign up to vote on this title
UsefulNot useful