TRACEBOK
Software Traceability Body of Knowledge

In software engeneering, traceability describes always requirements links. Requirements express needs and constraints of a software product and traceability allows to describe and to follow requiremens steps[15,22]. As side effect, traceability makes easier to verify and to validate requirements.

Requirements traceability may have two directions from requirement[13]:

• forward: from a requirement to its artefacts or elements (built from it).
• backward: from a requirement to its sources.

Figure 2.1 presents requirements tracing directions. Remark, from the figure, that backward direction answers the question Which source? and forward one answersWhich component?

Traceability may also be divided into two basic types (see Figure2.2):

• Pre-requirements specification traceability (pre-RS traceability): refers to those requirements life cycle aspects before it is designed.
• Pos-requirements specification traceability (pos-RS traceability): refers to those requirements life cycle aspects from the beginning of its specification.

Pre-RS and pos-RS traceabilities allow to have a traceability view based on software development life cycle, considering the beginning of development process with the users needs up to the artifacts creation from the requirements. Thus, pre-RS is used to show that a product meets stakeholder requirements from initial discussion and elucidation to the inclusion into the requirement document. On the other hand, pos-RS is used to requirement validation and to establish the impact analysis recovering traces from different development phases [23] [28].

 

Figure2.2 Pre and pos-requirements specification traceability [13]

 

Figure2.2 also shows the complexity from several iterations among traceability artifacts. Frequently, relationship between elements are many-to-many. From the users to RS and from RS to artifacts (see S0 and S1).

Another classification for traceability is with relation to context or elements to be traced. This classication consider the relationship level among the traced artifacts. It is called two dimensional traceability.

• Horizontal (or inter traceability): refers to relationship between different levels (or models) of abstraction: from requirements to implementation going through design. In this classification, for example, trace links are created between requirements and source codes.
• Vertical (or intra traceability): refers to relationship between the same levels (or model) of abstraction: between software components, related requirements, among others.

Two dimensional traceability is depicted in Figure 2.3 with the following models: requirements, analysis, design and code. Each model has a set of objects. For example, Design model has four objects: D1, D2, D3 and D4. Horizontal traceability is represented, in the figure, from R1 to A1 (Requirements and Analysis models), for example. In the other hand, trace between C1 and C2 in the Code model shows, in the figure, a vertical traceability.

 

Figure2.3 Rastreabilidade Vertical e Horizontal

 

The definition of traceability, traceability directions and dimensionality underline the basis of traceability.

Requeriment traceability may be applied in different tasks of software development. To apply traceability, Mader, in[18], proposed a life cycle. It is composed by three generic process: (i) defining traceability, (ii) create and maintaining traceability and (iii) using traceability. A generic traceability process model shows the essential activities used in the software traceability. This model is essential to guide the organizational traceability strategy. Figure 2.4 describes the four key activities of the generic traceability process model: traceability strategy , traceability creation, traceability maintenance, traceability use. This model was proposed by [6]. Next sections present, briefly, the activities present in Figure 2.4.

The most important activity in traceability is to plan a strategy. Traceability must be planned by establishing requirements such as granularity, categorization and storage artifacts. The strategy of linkages among artifacts is also important. A planning must have the approaches chosen for generating, classifying, representing and maintaining inter and intra-artifact. Good plannings are strategic for the traceability’s quality.

Traceability maintenance can result from a strategic requirement change or a trace maintenance. To guarantee the right results pointed by the traceability planning, the impact analysis have to be considered when the requirements changing. The changes have to be accommodated considering all trace structure. During the trace insertions or updating, the nature of the change must be analyzed to determine what updates are necessary. Traces can be maintained continuously or on-demand. When the trace links can be updated manually, the on-demand option is preferred since it is easier to perform. A trace is retired when it is no more necessary in software development.

Functional requirements (FR) are the most common type of requirement in a software product. Traceability of FR plays a crucial role in software development since they make software products easier to maintain and easier to understand the built components. Functional requirements knowledge area intends to help practitioners to manager trace links for functional requirements. Several approaches for FR are presented. All approaches are presented following the structure presented in Figure 1.2

Description This approach proposes the creation of traceability links between requirements and source code as the development progresses by incorporating artifacts from project management. The proposed approach is compatible with a iterative product software development (e.g. SCRUM), composed by sprints. The central artifact is the work item, as it connects the artifacts from the system model to artifacts from the code model. Developers create the links during the development phase, selecting a work item from his/her list of assigned work items and tell the system that starts the source code implementation. Other features or functional requirements are automatic captured by the system. 

Restriction of using This approach is based on MUSE (Management-based Unified Software Engineering). Source codes must be implemented in Eclipse IDE since it uses UNICASE tool to create automatically traceability links. 

Process support tools This approach works with UNICASE tool (Eclipse plugin). 

How to apply this approach This approach is divided in four steps. The first one, developers select the assigned work item and start its implementation. During the implementation, the system captures the changes in source code, the feature and the functional requirement that developers look at during the implementation. After that, the developer finishes the implementation. The second one, the system presents the lists of changed code files and captured features and functional requirements. Developers validate and, if is necessary, additional features and functional requirements are added. In the third one, processes are documented using the commit message of new versions of the work item. The last one, traceability links are created by a new revision of CVS containing the selected code files and links to work item. Traceability system links selected features and functional requirements to work item (see Figure 3.1).

Description This approach is used as an extension to an existing traceability approach. It is presented like a framework model-driven approach to link business processes (BP), user interfaces (UI) models and requirements. The application of changes made on BP or on system UIs may have an impact on software requirements, which then requires updating related models in order to coherently enable changes. The goal of mapping software requirements with task models, as an extension to an existing traceability approach, is to guarantee that UIs are aligned with requirements. The approach enables mapping requirements with UI models and analyzes the impact of changes on models of business-driven enterprise applications. For large organizations, like industries and banks, that have complex business processes, which must be supported by thousands of user interfaces in their applications, is primordial the alignment of task models with requirements and the relation with the user interaction.

Description traceMaintainer is a tool that supports an approach for maintaining post-requirements traceability relations after changes made to traced model elements. This tool supports the (semi-)automated update of traceability relations between requirements, analysis and design models of software systems expressed in UML. 

Process support tools The approach is supported by a tool (traceMaintainer) for maintenance of post-requirements traceability relations after changes made to traced model elements. 

Restriction of using Software documentation should be expressed in UML to use the approach and traceMaintainer. Another restriction is the use of a CASE to model a software product. Figure 3.8 shows how models are connected with the tool solution through Event Generator and traceSTORE. 

How to apply this approach This approach works with associated CASE tools. The Figure 3.8 shows the add-in event generator and traceSTORE responsible for listening the model changes and for communicating with the Rule Engine. The next step to use the approach is to analyze the rules and make the eventual interferences to keep integrity updated.

Description In automotive and avionics software development the criticism of application imposes for safety critical applications, full traceability and verification and validation of requirements. This approach integrates multiple tools and heterogeneous models that capture either functional or non functional requirements. This approach is based in a three dimensional methodology triptych composed of three activities: (i) requirement management, (ii) solution definition, and (iii) V&V (verification and validation) usage. This approach is justified by the necessary separation of concerns that is required when a certifying process has to be used to certify a product. Each vertex is a multi level model-based flow. The DARWIN4Req traceability model is the central part of this architecture by interconnecting these three independent flows. 

Restriction of using This approach works only with DARWIN4Req metamodel. 

Process support tools There is no one solution tool for this approach. Initial requirements can be obtained from requirement tools such that DOORS. 

How to apply this approach This approach defines two steps to create the traceability: (i) requirement definition and (ii) traceability where the requirements are linked with the model elements including the V&V.

Creation Traceability requires to establish clear relationships between the requirements themselves to handle refinement and decomposition aspects at the different levels of the requirement modeling flow. A second kind of relation must be expressed between requirements and the other artifacts from the solution and V&V models.

Use By using the above mentioned relationships (derive, decompose, satisfy or verify), traceability helps to guarantee that the solution models cover all the requirements; and that the model at the different steps of the design process and the final product correctly fulfill these requirements. The correctness is established by applying the V&V methods and by reporting these results on verify and satisfy links.

Description This process-oriented approach achieves comprehensive traceability and supports the entire software development life cycle by focusing on both requirements traceability and process traceability. One tool was developed to achieve three main goals: (i) minimize overhead in trace definition and maintenance, (ii) preserve document integrity, and (iii) support SDLC (software development life cycle) activities. 

Restriction of using This approach is proposed in the end-to-end software traceability tool. The approach is limited to post-requirement specification traceability and mainly applies to tracing text-based artifacts. 

Process support tools Traceability tool (is not a commercial tool).

How to apply this approach The Figure 3.2 shows the end-to-end software traceability model. The following global artifacts types to trace: Marketing Requirements (MRQs), Use Cases (UCs), Functional Requirements (FRs), and Test Cases (TCs). MRQs are organized by Projects and UCs are organized by Features. Several Projects roll up to one Product. Each of the artifact types (MRQ, UC, FR, TC) links to a phase in the software development life cycle (indicated by dotted lines). The users of the system, shown at the bottom of the diagram, are distinguished by whether they produce trace information or not. Producers, i.e. groups responsible for entering trace information, are the Marketing Group, Architect Group, Project Managers, and Test Group. All users are consumers of trace information.

Description This is an approach for generating trace recommendations, and make them available to knowledgeable project stakeholders within the context of their daily work. The idea is to avoid searching missing trace links in the end of project by eliciting traceability decisions from informed stakeholders throughout the project. Trace recommendations allow to construct traceability links earlier in the project. The approach extends state-of-the art traceability practices for managing trace strategies and queries, and utilizes the Business Process Modeling Notation (BPMN) to model critical software engineering workflows that drive and control the proposed trace recommendations. Traceability environment is described in terms of five-layered model depicted in Figure 3.3.

Description This approach allows to capture traces in a non-intrusive way from decisions to architecture design and implementation. Tracing links are built during architecture design and implementation process based on analysis of artifact modifications. These traces are added to a semi-formally proposed architecture model. This approach works from fine-grained tracing to single elements of an architecture model and it has been integrated to LISA toolkit. It basically works as follows: (i) user sets the context of his/her work by selecting decisions made during his/her working (these decisions are named active decisions), (ii) user starts performing his/her daily work, during this phase modification events are created and logged, i.e., short descriptions of the elements that are manipulated during this phase, and (iii) when user finishes working on a decision, he/she needs to review the captured tracing sets. 

Process support tools This approach is integrated with LISA toolkit that is based on LISA Model: an architecture description meta-model. The integration is made by constructing a listener in Eclipse Java Development Tools. In this case, this approach works only on Java based solution. 

Restriction of using This approach can be used only with Java-based applications, review process must be part of design and implementation process and not all capturing can be performed automatically. 

How to apply this approach Initially, developers decide the context of work by selecting the decisions to work on with. In this moment, new decisions my be also created. After setting the context and one or more active decisions, developers begin with architecture design and implementation activities, i.e., design decisions are made. In next step, developers implement classes and interface for decisions made. During this step, modification events are created and logged in background. All architecture and elements affected by an event are shown as child elements of the event. After developers finish working on an active decision, the captured tracing targets must be reviewed. Developers can remove incorrect or unnecessary tracing targets. Finally, traces are created and added as part of the architecture model. 

Creation The developer must register all active decisions and how they are implemented.

Use During the process of implement an active decision, developer must verify whether all modification events logged are correct and necessary. As a result, the traces are visualized in architecture diagrams and in source code editors as well.

Description This approach propose the use of STRADA (Scenario-based TRAce Detection and Analysis) tool that helps software engineers explore traces links to source code through testing. Two capabilities are listed: (i) Scenario-based Trace Capture, a tool that observes what code is being accessed during testing and creates a trace dependency, and (ii) Trace Analysis, a tool that helps the engineers to identify and resolve uncertainties. 

Process support tools The approach is supported by STRADA. 

Restriction of using The tool is currently restricted to Java-based systems because the Trace Capture component uses a Java profiler included in Eclipse. However, the approach is not restricted to this language and would also work if integrated with profilers for other languages. 

How to apply this approach To apply this approach is necessary to run tests in a target application. The result is the trace dependency generated by the link between the code accessed during the testing of a feature. After that, it is necessary to identify and resolve uncertainties. The traces created by testing needs to pass by a review. The trace analysis component allows to visualize the current knowledge on feature-to-code mapping in form of a trace matrix. 

Creation The links creations depends on the test realization. Then it is necessary an analysis to guarantee the quality of the traces. 

Use The use of the links is possible visualizing the knowledge on feature-to-code mapping in form of a trace matrix.

Description This approach implements traceability based on graph theory: components are nodes of the graph and their relationships are arcs. So, all artifacts are stored as nodes and the trace links as arcs. Developers build software products using UML methodology and there is an API of a UML Tool (e.g., Enterprise Architect) to convert UML models into TGraphs. TGraphs are graphs that describe components of UML models and their relationship. To construct TGraphs, this approach proposes the traceability reference schema (TRS). TRS is construct using an extension of UML: grUML. Figure3.4 depicts how the graph are built. There is an entity (class) that represents traceable components: Stakeholder, Requirement (specialized in FunctionalRequirement and NonFunctionalRequirement), ArchitectureElement, DesignElement, TestCase, CodeElement and DocumentionElement. These entities describe all traceable elements of this approach. On other hand, relationships can be: isResponsibleFor, ConflictsWith, Refines, DependsOn, Fulfills, Realizes, Implements, Tests and Documents. A grUML model is stored as a TGraph. Objects stored in TGraphs are queried using GReQL. Therefore, the suite proposed in this approach allows to extract automatically components and their trace links from UML models and to query stored objects.

Description This is an approach to support architectural design decisions (ADD) evolution. It provides a generic, ADD notation-independent approach that starting from a model based specification of ADDs, enables to identify the impact of a changing design decision on other ADDs and the impact of the same on requirements and architectural descriptions. The approach proposes a metamodel for evolving ADDs. The metamodel is generic and flexible enough to manage requirements and architectures described in any notation. The proposed metamodel enables explicit representation of relationship among ADDs. The metamodel also enables bidirectional traceability links between ADDs, requirements and architectural elements which will help in analyzing the impact of evolution on the corresponding artifacts. Finally, the approach enables inter-decision and extra-decision validation to check the presence of inconsistencies that may occur during evolution.

Figure 3.5 gives an overview of the approach to support architectural design decisions evolution. The ADD model represents all the design decisions identified during the design process. Decisions are linked to requirements specification and a set of software architecture (SA) descriptions.

Non-functional requirements (NFR - also called quality requirements) are generally more difficult to express in a quantifiable manner and they are hard to be verified for individuals components. Create tracing links for non-functional requirements is also a challenger since tracing requirement specifications toward the designing and vice-versa requires a lot of attention of developers. The Non-Functional Requirements Traceability knowledge area intends to help practitioners to manage NFR trace links. Here, approaches are presented (following the structure from Figure 1.2) in a such way that practitioners can find alternatives for traceability of non-functional requirements.

Modeling

Description This approach considers traceability of safety requirements in the context of model-driven development of teleoperated services robots. The combination of the software development approaches make it possible to construct systems using techniques for automatically identifying, managing, and mitigating risks. This traceability approach was proposed to guarantee the interaction between the teleoperated services robots and both the human and the environment. The methodology presented in this approach proposes the fusion of different standards. The four steps are summarized as follows:

Step 1 - Identify hazards: includes identification of the possible causes of the failure (hardware, software, or human), the tasks in which it can happen, and the reaction to the occurrence of the hazard.

Step 2 - Identify risks: Identify the possible risks of the system, classify them according to the impact they have on the system and the environment, and link them to the hazards identified in the first step.

Step 3 - Specify safety requirements: extract the system safety requirements from the results of the previous steps.

Step 4 - Make safe designs: the design of the systems software architecture must consider the safety requirements, avoid failures that spread through the whole system, and be periodically reviewed when new hazards are identified. 

Process support tool There is an implemented tool responsible for the traceability report. For the other steps of the approach, there is no supported tools.

Restriction of using The use is restrict for software development using MDD (Model Driven Development).

How to apply this approach A general schematic of the artifacts and tools is used in the proposed process. There are two clearly differentiated parts: 1) the part relating to management of safety requirements (Traceability Management) and 2) the part integrated in the application software modeling process and code generation (V3CMM Framework). The process works as follows: first, user starts modeling the safety requirements or reusing requirements that have been defined previously. After, user must then develop an architecture solution (a V3CMM model) that meets the safety requirements. The traceability matches between safety requirements and the elements of architecture design that satisfy them must be noted in the model called “Traceability Model #1” following the metamodel proposed in this approach. These annotations are created manually and are used as inputs for the tool created to support this approach.

Creation To create traces, it is necessary to follow the proposed metamodel structure as shown in Figure 4.1. The Link element of the metamodel is defined by: (i) An Element Model (source), which references an element of the safety-based requirements metamodel and (ii) An Element Model (target), which references an element of the V3CMM.

Description This approach propose an optimized traceability analysis method which is based on the means-ends and whole-part concept of the approach for cognitive systems engineering to trace these safety requirements. The safety requirements of a system and its components ( hardware, software, and humans) are enforced or implemented through a means-ends life cycle. The approach works with a concept presented in Figure 4.2, where a whole-part relation presents a hierarchical decomposition of a physical system. In a means-ends abstraction, each level represents a different model of the same system (aggregation of components). At any point in the hierarchy, the information at one level acts as the goals (the ends) with respect to the model at the next lower level (the means). Thus, in a means-ends abstraction, the current level specifies what (to do), the level below describes how (to do), and the level above why (to do). Any information (what) can also be considered as a goal (why) for information at a lower level, as well as a means (how) for other information at a higher level.

Description This approach includes a traceability information model, a methodology to establish traceability, and mechanisms to use traceability for extracting slices of models relevant to a particular (behavioral) safety requirement. Safety critical systems in domains such as avionics, automotive, maritime and energy, the software control modules, integrated with hardware devices and continuously interact with the environment are candidates to use this approach. There are difficulties in the software safety certification process that arise from poor traceability. The focus has been on ensuring that both the design and the links between the requirements and the design are “precise” enough to allow for systematic design inspections. 

Process support tools The SafeSlice tool was developed to support the approach. SafeSlice has been implemented as a plugin for Enterprise Architect.

Restriction of using In this approach, requirements are expressed as (unrestricted) natural language statements and the design is expressed using the Systems Modeling Language (SysML). Moreover, the slicing technique is used to facilitate design safety inspection by enabling engineers to focus on the aspects of the design that are relevant to safety. This approach does not consider other categories of requirements, such as performance, availability, and security, which can have safety implications.

How to apply this approach To apply this approach, there are two phases.

Phase I is composed by three steps: (i) system context diagram: to specify the boundary between the system and its context, (ii) system-level requirement diagram: address the entire system, and can relate to both hardware and software, and (iii) use case diagram capturing system top-level functions: represent the functionality of the software part of a system from an external point of view.

Phase II is composed by six steps: (iv) and (v) Structural diagrams: composed by a system decomposition and communication interfaces, describe the structure of a system using SysML Block Definition Diagrams (BDDs) and Internal Block Diagrams (IBDs), (vi) and (vii) Behavioral diagrams: use sequence/activity diagrams to represent inter-block scenarios, and state machine diagrams to represent intra-block state-based specifications. (viii) and (ix) Establish traceability: establish traceability links from the system-level requirements down to the design diagrams adapting and using the SysML traceability links. The traceability links specify which parts of the design contribute to the satisfaction of each requirement. The methodology sequence of steps can be seen in Figure 4.3.

The large number and heterogeneity of documents generated during the development of product line systems may cause difficulties to identify common and variable aspects among applications, and to reuse core assets that are available under the product line. The commonalities and variabilities in software product line increases the traceability difficulty. Approaches related in this knowledge area present alternative solutions for traceability in software product line development. The presentation is organized following the structure from Figure 1.2.

Description This approach focuses on tracing variability between a requirement and architecture in a product line. The approach affirms that variability is done in all generic artifacts as variation points and variation points may consequently appear in various generic artifacts and at any level of abstraction. The proposed metamodel makes an explicit capture and appropriate manage traceability between variation points at different level of abstraction. This approach proposes tracing variability between requirement and architecture in a product line. The OMG (Object Management Group) adopted Reusable Asset Specification (RAS), an open standard that can be used to manage any set of development artifacts. This approach is defined in two domains. Domain Requirement Metamodel: the primary responsibility is to define artifact constituents to specify the domain requirements models in a specific domain. The Figure 5.1 presents the objects Asset, Solution and Artifact inherited from RAS. The other objects are proposed to create the traceability environment.

At the same way, Figure 5.2 shows the same objects from Figure 5.1 as RAS objects. Others are proposed to create the traceability environment. Primary responsibility of domain architecture metamodel is to define artifact constituents for specifying domain architecture models in a specific domain.

Figure5.2 Metamodel of domain architecture

 

Figure 5.3 shows a variability trace metamodel where trace relationships between domain requirements and domain architecture are defined. The trace relationships from the domain requirements to the domain architecture are divided into the following two types: (i) trace for variations in artifact constituents and (ii) trace for variations in artifact models. The variations of domain models depend on the variations of artifact constituents. 

Process Support tools There is no supported tool for this approach.

Figure5.3 Variability trace metamodel

 

necessary to create an environment with the presented descriptions.

 

How to apply this approach To apply this concepts is necessary to create an environment to apply the proposed variability trace metamodel. Actually, there is no support tool. Create a tool to support the metamodel in an alternative.

Creation To create the traces is necessary to identify and register the objects used to construct the product in product line context. Every relation between different artifacts should be registered. After that, the informations are ready to be used. 

Use The use of the traces in this approach is realized by the trace matrix. The matrix are conceived from the metamodels informations (artifacts constituents and model).

Description The main goal of this approach is to establish a framework for automated formal identification of the traceability between feature model and architecture model. Feature modeling is a method for describing commonalities and variabilities in software product line. Software architecture of a program or computing system is the structure or structures of the system. This approach uses the technique Formal Concept Analysis (FCA) to identify feature and architecture model. FCA is a theory of data analysis which identifies conceptual structures among data sets. The approach consists of three steps (as shown in Figure 5.4):

Description This approach proposes a tool called XTraQue that implements an automatic generation of traceability relations between elements of documents created during the development of product line systems. Documents are generated within domain analysis and design (feature-based) and object-oriented methodologies. Feature-based and objetc-oriented are inplemented using an extension of FORM methodology. The proposed reference model contains nine different types of traceability relations: satisfiability, dependency, overlaps, evolution, implements, refinement, containment, similar, and different. Those relations are applied in for eight types of documents divided into two groups: product line information and product member information. The first group is composed by feature, subsystem, process, and module models. The second one is composed by use cases, class, statechart, and sequence diagrams. Documents are represented by XML documents and rules are represented by XQuery definitions. XTraQue supports five functionalities: (i) specification of the documents to be traced, (ii) specification of the types of relations to be created, (iii) generation of direct and indirect traceability relations based on the input given in (i) and (ii), (iv) visualisation of the documents containing traceability relations generated in (iii), and (v) testing of new traceability rules. The functionality (i) allows users to select and to establish traceability relations between documents of two specific product members, documents at the level of product line and one specific product member, and documents at the level of product line and two specific product members. XTraQue also intends that traceability relations have semantic meanings and directions instead of being simple links between different elements. The extension proposed in XQuery allows to represent traceability rules and the use of rules that take into consideration (i) semantic of the documents being compared, (ii) various types of traceability relations in the product line domain, (iii) grammatical roles of the words in the textual parts of the documents, and (iv) synonyms and distance of words being compared in a text. 

Supported tool XTraQue is based on documents generated by an extension of FORM methodology. 

Restriction of using The approach assumes that for each line of software system being developed, there is a single instance of feature and subsystem models, but there may exist various instances of process and module models and various instances of documents in the product member level (i.e. use cases, class, statechart, and sequence diagrams). Moreover, product line systems have to be developed using a proposed extension of FORM and feature-based and object-oriented methodologies.

How to apply this approach Users must use FORM methodology altogether with feature-based and object-oriented methodology. Trace links are built automatically from documents generated by these methodology

Creation The users choose documents to be traced: all the documents related to the product line and product members, or specific documents to be traced based on type of documents, particular document names, or types of traceability relations. 

Use The XML documents containing traceability information are visualized by XTraQue. XTraQue still allows creation of new traceability rules and the execution of these rules in order to verify their correctness. When a new corrected rule is created, user can insert it in the document containing all the traceability rules.

This glossary is proposed to support the use of this body of knowledge. The selected terms contribute with the comprehension of the traceability concepts and with the presented approaches in this document. Gotel et al. [12] propose a glossary with terms and concepts used in traceability. The terms presented in this document is an adaptation of the concerned terms for the selected approaches.

Automated traceability:The potential for automated tracing.
Automated tracing: When traceability is established via automated techniques, methods and tools.
Backward tracing: Tracing follows antecedent steps in a developmental path, which is not necessarily a chronological path, such as backward from code through design to requirements.
Bidirectional tracing: When tracing can be undertaken in both forward and backward direction.
Candidate trace link: A potential, as yet unverified, trace link.
Forward tracing: The tracing follows subsequent steps in a developmental path, which is not necessarily a chronological path, such as forward from requirements through design to code.
Horizontal tracing: Tracing artifacts at the same level of abstraction. Horizontal tracing employs both forward tracing and backward tracing.
Manual tracing: When traceability is established manually.
Post-requirements (specification) traceability: Comprises those traces derived from or grounded in the requirements, and hence the traceability describes the requirements deployment process.
Pre-requirements (specification) traceability: Comprises all those traces that show the derivation of the requirements from their original sources, and hence the traceability describes the requirements production process.
Requirements management: The activity concerned with the effective control of documenting, analyzing, tracing, prioritizing and agreeing on requirements and then controlling change and communicating to relevant stakeholders
Requirements traceability: process that allows to ensure the continuous concordance between stakeholders requirements and the artifacts produced along software development process.
Software traceability: extends the definition of requirements traceability to encompass and interrelate any uniquely identifiable software engineering artifact to any other.
Systems traceability: extends the definition of requirements traceability to encompass and interrelate any uniquely identifiable systems engineering artifact to a broad range of systems-level components, such as people, processes and hardware models.
Target artifact: The artifact at the destination of a trace.
Trace (Noun): A specified triplet of elements comprising: a source artifact, a target artifact and a trace link associating the two artifacts. Where more than two artifacts are associated by a trace link, such as the aggregation of two artifacts linked to a third artifact, the aggregated artifacts are treated as a single artifact.
Trace (Verb): The act of following a trace link from a source artifact to a target artifact (primary trace link direction) or vice-versa (reverse trace link direction).
Trace artifact: A traceable unit (e.g., a single requirement, a cluster of requirements, a UML class, a UML class operation, a Java class or even a person). A trace artifact is one of the trace elements and is qualified as either a source artifact or as a target artifact when it participates in a trace. The size of the traceable unit defines the granularity of the related trace.
Trace creation: The activity of creating a single trace, associating two artifacts via a trace link. The trace link may be created manually, automatically using tools or semi-automatically using some combination of tool and manual input.
Trace element: Used to refer to one of the trace triplet: source artifact, target artifact or trace link.
Trace generation: A particular approach to trace creation that implies trace links are created automatically or semi-automatically using tools.
Trace granularity: The level of detail at which a trace is recorded and performed. The granularity of a trace is defined by the granularity of the source artifact and the target artifact.
Trace life cycle: A conceptual model that describes the series of activities involved in the life of a single trace, from initial conception, through creation, maintenance and use, through to eventual retirement.
Trace link: A specified association between a pair of artifacts, one comprising the source artifact and one comprising the target artifact.
Trace maintenance: activities associated with updating a single pre-existing trace.
Trace query: A term often used in the process of generating or vetting trace links, where one high level element is regarded as the trace query for searching into an artifact collection to find trace links (as distinguished from traceability-related queries).
Trace recall: A commonly used metric in automated tracing that applies to rep- resent the fraction of relevant trace links that are retrieved. It is computed as:Recall = (RelevantLinks ∩ RetrievedLinks) \ RelevantLinks.
Trace relation: All the trace links created between two sets of specified trace artifact types. The trace relation is the instantiation of the trace relationship and hence is a collection of traces. For example, the trace relation would be the actual trace links that associate the instances of requirements artifacts with the instances of test case artifacts on a project. The trace relation is commonly recorded within a traceability matrix.
Trace relationship: An abstract definition of a permissible trace relation on a project (i.e., source artifact type, target artifact type and trace link types), as typically expressed within a traceability information model (TIM). Note that the trace links of the instances of the two artifact types may not necessarily have the same trace link type.
Trace retrieval: A particular approach to trace creation where information retrieval methods are used to dynamically create a trace link. This approach can be used for both trace capture and trace recovery.
Trace precision: A commonly used metric in automated tracing that applies to represent the fraction of retrieved trace links that are relevant. It is computed as:Precision = (RelevantLinks∩RetrievedLinks)\ RetrievedLinks.
Traceability: Ability to track software artifacts from its creation to its retirement.
Traceability information model (TIM): A graph defining the permissible trace artifact types, the permissible trace link types and the permissible trace relationships on a project, in order to address the anticipated traceability-related queries and traceability-enabled activities and tasks. The TIM is an abstract expression of the intended traceability for a project.
Traceability lifecycle: A conceptual model that describes the series of activities associated with a full end-to-end traceability process.
Traceability link: A term often used in place of trace link. Arguably, while traceability link captures the enabling role of the link for traceability purposes, trace link emphasizes the fact that the link is a primary element of a trace.
Traceability maintenance: Those activities associated with updating preexisting traces in the face of trace evolution, and establishing new traces where needed, to keep the traceability relevant and up to date.
Traceability management: Those activities associated with providing the control necessary to keep the stakeholder and system requirements for traceability and the traceability solution up to date during the life of a project. Traceability management is a fundamental part of traceability strategy.
Traceability matrix: A matrix recording the traces comprising a trace relation, showing which pairs of trace artifacts are associated via trace links.
Traceability method: A prescription of how to perform a collection of traceability practices, integrating traceability techniques with guidance as to their application and sequencing.
Traceability network: A traceability graph in which the directionality of the trace links is expressed (i.e., the artifacts are depicted as ordered pairs) and where the trace links are potentially weighted in some manner.
Traceability planning: Those activities associated with determining the stakeholder and system requirements for traceability and designing a suitable traceability solution. Traceability planning is a fundamental part of traceability strategy.
Traceability policy: Agreed principles and guidelines for establishing and using traceability in practice.
Traceability practices: Those actions and activities associated with planning, managing, creating, maintaining and using traceability.
Traceability process: The particular series of activities to be employed to establish traceability and render it usable for a particular project, along with a description of the responsibilities and resourcing required to undertake them, as well as their inputs and outputs. The traceability process defines how to undertake traceability strategy, traceability creation, traceability maintenance and traceability use.
Traceability strategy: Those decisions made in order to determine the stakeholder and system requirements for traceability and to design a suitable traceability solution, and for providing the control necessary to keep these requirements and solutions relevant and effective during the life of a project. Traceability strategy comprises traceability planning and traceability management activities.
Traceability technique: A prescription of how to perform a single traceability practice, such as traceability creation, along with a description of how to represent its traceability work products.
Traceability tool:Any instrument or device that serves to assist or automate any part of the traceability process.
Traceable:The potential for artifacts to be accessed and retrieved by following trace links.
Tracking: The term commonly applies to the act or process of following requirements and depends upon requirements traceability.
Traced: The artifacts that have been accessed by tracing, and so by having followed trace links.
Tracing: The activity of either establishing or using traces.
Tracking: The act or process of following requirements and depends upon requirements traceability.
Vertical tracing: Tracing artifacts at differing levels of abstraction so as to accommodate lifecycle-wide or end-to-end traceability, such as from requirements to code. Vertical tracing employs both forward tracing and backward tracing.

1. HazelineU. Asuncion, Frédéric Fran cois, and RichardN. Taylor. An end-to-end industrial software traceability tool. In Proceedings of the the 6th joint meeting of the European software engineering conference and the ACM SIGSOFT symposium on The foundations of software engineering, ESEC-FSE ’07, pages 115–124, New York, NY, USA, 2007. ACM. 

2. G.Buchgeher and R.Weinreich. Automatic tracing of decisions to architecture and implementation. In Software Architecture (WICSA), 2011 9th Working IEEE/IFIP Conference on, pages 46–55, 2011. 

3. Lawrence Chung, BNixon, EYu, and JMylopoulos. Non-functional requirements in software engineering. Kluwer Academic Publishing, 2000. 

4. J.Cleland-Huang, P.Mader, M.Mirakhorli, and S.Amornborvornwong. Breaking the big-bang practice of traceability: Pushing timely trace recommendations to project stakeholders. In Requirements Engineering Conference (RE), 2012 20th IEEE International, pages 231–240, 2012. 

5. J.Cleland-Huang and D.Schmelzer. Dynamically tracing non-functional requirements through design pattern invariants. In Workshop on Traceability in Emerging Forms of Software Engineering, October 2003. 

6. Jane Cleland-Huang, Orlena Gotel, and Andrea Zisman. Software and Systems Traceability. Springer London, 2012. 

7. Alexander Delater and Barbara Paech. Analyzing the tracing of requirements and source code during software development. In Proceedings of the 19th international conference on Requirements Engineering: Foundation for Software Quality, REFSQ’13, pages 308–314, Berlin, Heidelberg, 2013. Springer-Verlag. 

8. Hubert Dubois, Marie-Agnes Peraldi-Frati, and Fadoi Lakhal. A model for requirements traceability in a heterogeneous model-based design process: Application to automotive embedded systems. In Proceedings of the 2010 15th IEEE International Conference on Engineering of Complex Computer Systems, ICECCS ’10, pages 233–242, Washington, DC, USA, 2010. IEEE Computer Society. 

9. Alexander Egyed, Gernot Binder, and Paul Grunbacher. Strada: A tool for scenario-based feature-to-code trace detection and analysis. In Companion to the proceedings of the 29th International Conference on Software Engineering, ICSE COMPANION ’07, pages 41–42, Washington, DC, USA, 2007. IEEE Computer Society. 

10. I.Galvao and A.Goknil. Survey of traceability approaches in model-driven engineering. In Enterprise Distributed Object Computing Conference, 2007. EDOC 2007. 11th IEEE International, pages 313–313, 2007. 

11. Arda Goknil, Ivan Kurtev, and Klaas vanden Berg. Tool support for generation and validation of traces between requirements and architecture. In Proceedings of the 6th ECMFA Traceability Workshop, ECMFA-TW ’10, pages 39–46, New York, NY, USA, 2010. ACM. 

12. O.Gotel, J.Cleland-HuangandA. Zisman, J.Huffman Hayes, A.Dekhtyar, P.Mäder, A.Egyed, P.Grünbacher, G.Antoniol, and J.Maletic. Glossary of traceability terms (v1.0). In Software and Systems Traceability, pages 413—424. Springer, 2012. 

13. O.C.Z. Gotel and A.C.W. Finkelstein. An analysis of the requirements traceability problem. In Requirements Engineering – 1994 – Proceedings of the First International Conference on, pages 94–101, 1994. 

14. Waraporn Jirapanthong and Andrea Zisman. Xtraque: traceability for product line systems. Software & Systems Modeling, 8(1):117–144, 2009. 

15. Gerald Kotonya and I.Sommerville. Requirements engineering: processes and techniques. Worldwide series in computer science. J. Wiley, 1998. 

16. Jang-Soo Lee, Vikash Katta, Eun-Kyoung Jee, and Christian Raspotnig. Means-ends and whole-part traceability analysis of safety requirements. Journal of Systems and Software, 83(9):1612–1621, 2010. 

17. P.Mader, O.Gotel, and I.Philippow. Semi-automated traceability maintenance: An architectural overview of tracemaintainer. In Software Engineering - Companion Volume, 2009. ICSE-Companion 2009. 31st International Conference on, pages 425–426, 2009. 

18. Patrick Mäder and Orlena Gotel. Towards automated traceability maintenance. Journal of Systems and Software, 85(10):2205–2227, 2012. 

19. Ivano Malavolta, Henry Muccini, and V.Smrithi Rekha. Supporting architectural design decisions evolution through model driven engineering. In Proceedings of the Third international conference on Software engineering for resilient systems, SERENE’11, pages 63–77, Berlin, Heidelberg, 2011. Springer-Verlag. 

20. Mikyeong Moon, HeungSeok Chae, Taewoo Nam, and Keunhyuk Yeom. A metamodeling approach to tracing variability between requirements and architecture in software product lines. In Proceedings of the 7th IEEE International Conference on Computer and Information Technology, CIT ’07, pages 927–933, Washington, DC, USA, 2007. IEEE Computer Society. 

21. Shiva Nejati, Mehrdad Sabetzadeh, Davide Falessi, Lionel Briand, and Thierry Coq. A sysml-based approach to traceability management and design slicing in support of safety certification: Framework, tool support, and case studies. Information and Software Technology, 54(6):569–590, 2012. 

22. S.L. Pfleeger. Engenharia de Software - Teoria e Prática. Prentice Hall - São Paulo, 2nd edition, 2004. 

23. G.Regan, F.McCaffery, K.McDaid, and D.Flood. The barriers to traceability and their potential solutions: Towards a reference framework. In Software Engineering and Advanced Applications (SEAA), 2012 38th EUROMICRO Conference on, pages 319–322, 2012. 

24. P.Sanchez, D.Alonso, F.Rosique, B.Alvarez, and J.A. Pastor. Introducing safety requirements traceability support in model-driven development of robotic applications.Computers, IEEE Transactions on, 60(8):1059–1071, 2011. 

25. TonnyKurniadi Satyananda, Danhyung Lee, Sungwon Kang, and SajidIbrahim Hashmi. Identifying traceability between feature model and software architecture in software product line using formal concept analysis. In Proceedings of the The 2007 International Conference Computational Science and its Applications, ICCSA ’07, pages 380–388, Washington, DC, USA, 2007. IEEE Computer Society. 

26. Hannes Schwarz, Jürgen Ebert, and Andreas Winter. Graph-based traceability: a comprehensive approach. Software & Systems Modeling, 9(4):473–492, 2010. 

27. Kênia Sousa, Hildeberto Mendonça, Jean Vanderdonckt, and MarceloS. Pimenta. Supporting requirements in a traceability approach between business process and user interfaces. In Proceedings of the VIII Brazilian Symposium on Human Factors in Computing Systems, IHC 08, pages 272–275, Porto Alegre, Brazil, Brazil, 2008. 

28. Stefan Winkler and Jens Pilgrim. A survey of traceability in requirements engineering and model-driven development. Software and Systems Modeling, 9(4):529–565, 2010. 

29. Anton Yrjönen and Janne Merilinna. Tooling for the full traceability of non-functional requirements within model-driven development. In Proceedings of the 6th ECMFA Traceability Workshop, ECMFA-TW ’10, pages 15–22, New York, NY, USA, 2010. ACM. 

30. Yijun Yu, Jan Jurjens, and J.Mylopoulos. Traceability for the maintenance of secure software. In Software Maintenance, 2008. ICSM 2008. IEEE International Conference on, pages 297–306, 2008.