TRACEBOK
Software Traceability Body of Knowledge

Version 1.0

  • INTRODUCTION TRACEBOK GUIDE
    1. 1.1 - Document Structure
    2. 1.2 - Users and Uses
    3. 1.3 - Knowledge Areas
    4. 1.4 - Classification Approaches
  • INTRODUCTION TRACEBOK GUIDE

    Traceability supports software management, software evolution and validation. When changes are made in a software product, traceability is fundamental to analyze changes impact, besides, it helps on the understanding, capturing, tracking and verification of software artifacts and their relationships and dependencies with other artefacts during the software life-cycle[10]. With this in mind, a guide has an important role to help practitioners to understand and apply traceability in their daily software development tasks.

    The Guide of Software Traceability Body of Knowledge (TraceBok Guide) is established with the following objectives:

    1. To provide a comprehensive and integrative view of the software traceability for professionals and organizations; and
    2. To present and to explain software traceability approaches to support software development cycle.

    This guide is developed to gather concepts and approaches of software traceability.

    This release was proposed based on systematic review about software traceability concepts approaches. As a result, knowledge areas are proposed to serve as guide to professionals and organizations. This guide is validated by a community of domain experts.

    1.1 - Document Structure

    This document is structured as follows: this chapter introduces TraceBok presenting the knowledge areas (KA) and the approaches associated to each KA. Chapter 2 presents the first KA, called Traceability Life Cycle. This KA represents the base for traceability concepts and for the other KA. In Chapter 3, it is presented Functional Requirement Traceability knowledge area that groups functional requirement traceability approaches. Chapter 4 presents Non-Functional Requirements Traceability knowledge area that groups non-functional requirements traceability approaches. The following chapter (Chapter 5) presents Software Product Line Traceability that groups software product line traceability approaches. Finally, Glossary is organized in a chapter to present the most frequent traceability term used during the software process development life cycle.

    References presents the references used in this body of knowledge.

    1.2 - Users and Uses

    This guide was organized to improve the software traceability comprehension. Different groups of users may benefit from this guide. Table 1.1 shows the potential users and common uses of this guide. 

     

    Table1.1 Users and Uses

    User Uses
    Software develope

    A source for software development traceability approaches study.

    A guide for helping to choose approaches that fit their needs.

     

    Projetc manager

    A guide for helping managers establish strategies for the use of traceability in organizations.

    Academic people The guide is useful to organize concepts and contents.

    A source for traceability researches.

    1.3 - Knowledge Areas

    TraceBok is organized in Knowledge Areas (KA). Knowledge areas provide a guide to some of the major traceability purpose and practices. The proposed knowledge areas were defined from reviews of the most using traceability approaches found in the literature and organizations. Figure 1.1 depicts the organization of TraceBok KA.

     

    Figure1.1 TraceBok - Knowlegde Areas Organization

    The first knowledge area - Traceability Life Cycle - intends to support the other KA. It is defined to present the basic concepts and the traceability life cycle. Furthermore, this KA aims to elucidate (i) the main traceability concepts, and (ii) the organization of the process and its part of traceability life cycle. All approaches presented in this BoK follow the concepts in Traceability Life Cycle knowledge area.

    The other proposed KA aim to gather the traceability approaches in categories oriented to user needs. Therefore, approaches found for traceability are grouped in three KAs: Functional Requirements, Non-Functional Requirements and Product Line Traceability. Each approach is described in such way that practitioners can evaluate whether or not the approach fits traceability requirements for their application.

    Notice that knowledge areas are not intended to represent phases in traceability. The objective is to organize available literature approaches according common characteristics. Thus, this BoK gather approaches by traceability uses and objectives.

    1.4 - Classification Approaches

    The Tracebok objective is to bring the concepts and the possibilities of traceability use for the product software developers. Thus, approaches were selected from the literature and validate to justify the selection. Validation was conducted by interviewing traceability practitioners. To simplify the use of the content in this BoK, approaches were organized in knowledge areas with the distinct objectives. Some approaches attend more than one knowledge area. In this case, they are presented in one of the knowledge area and they are referenced in the others.

    Approaches are organized as follows:

    • Functional requirements since most traceability approaches deal with this kind of requirements.
    • Non-functional requirements since they have specific characteristics for traceability, such that: non-functional requirements come in many different shapes and sizes, and there is therefore no single traceability technique that can be applied in every case [5].
    • Software product line since traceability for this area is more complex encompassing several development layers.

     

    Approaches are presented in such way that it is possible to identify its applicability in traceability tasks. They are described as follows: description, process support tool, restriction of using and how to apply this approach that is divided into create and use. Figure 1.2 shows the content of each approach.

     

    Figure1.2 Approaches content
     

    The Bok is not conceived as a methodology for the traceability implementation. Instead, it allows to identify how to use traceability with relation to the practitioners specific needs.

    Table 1.2 presents the proposed classification of the selected approaches.

     

    Table1.2 Approaches classification







    ID

    Description


    Source

     Classification







    #FRT01 Requirement and Source Code Traceability [7] Functional







    #FRT02 Requirements Traceability in an Heterogeneous Model-based Design Process [8] Functional and Non-Functional







    #FRT03 End-to-end Software Traceability [1] Functional







    #FRT04 Pushing Timely Trace Recommendations to Project Stakeholders [4] Functional







    #FRT05 Capturing (semi)automatically traceability relationship from requirements and design decision to architecture and implementation [2] Functional







    #FRT06 Traceability in secure and dependable software development [30] Functional







    #FRT07 A Tool for Scenario-based Feature-to-Code Trace Detection and Analysis [9] Functional







    #FRT08 Graph-based traceability [26] Functional







    #FRT09 Architectural Design Decisions Evolution through Model Driven Engineering [19] Functional







    #FRT10 Supporting Requirements in a Traceability Approach between Business Process and User Interfaces [27] Functional







    #FRT11 Generation and Validation of Traces between Requirements and Architecture [11] Functional







    #FRT12 Semi-automated Traceability Maintenance - traceMaintainer [17] Functional







    #NFRT01 Full Traceability of Non-Functional Requirements within Model-Driven Development [29] Non Functional







    #NFRT02 Introducing Safety Requirements Traceability Support in MDD of Robotic Applications [24] Non Functional







    #NFRT03    Means-ends and whole-part traceability analysis of safety requirements [16] Non Functional







    #NFRT04 A SysML-based approach to traceability management and design slicing in support of safety certification [21] Non Functional







    #SPLT01 A Metamodeling Approach to Tracing Variability between Requirements and Architecture in SPL [20] Software Product Line Traceability







    #SPLT02 Traceability in Software Product Line using Formal Concept Analysis [25] Software Product Line Traceability







    #SPLT03 XTraQue: traceability for product line systems [14] Software Product Line Traceability
  • TRACEABILITY LIFE CYCLE
    1. 2.1 - Basic Concepts
    2. 2.2 - Traceability Life Cycle
    3. 2.2.1 - Traceability Strategy
    4. 2.2.2 - Traceability Creation
    5. 2.2.3 - Traceability Use
    6. 2.2.4 - Traceability Maintenance
  • TRACEABILITY LIFE CYCLE

    2.1 - Basic Concepts

    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?

     

    Figure2.1 Forward and backward traceability.
     

    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 Sand 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: D1D2Dand D4. Horizontal traceability is represented, in the figure, from Rto A(Requirements and Analysis models), for example. In the other hand, trace between Cand Cin 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.

    2.2 - Traceability Life Cycle

    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.

     

    Figure2.4 Generic Traceability Process Model

    2.2.1 - Traceability Strategy

    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.

    2.2.2 - Traceability Creation

    Based on the traceability planning, traceability elements have to be created, represented and stored. When the traces already exists they have to be captured. After that, the validation against the planning is used to guarantee trace accuracy of the links.

    2.2.3 - Traceability Use

    Trace links are created or captured to help developers to manage software maintenance to avoid losing information and to measure changes impacts. During a trace link using changes in the trace may happen and this change must be managed to keep trace link accuracy. 

    2.2.4 - Traceability Maintenance

    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 TRACEABILITY
    1. 3.1 - #FRT01 - Requirement and Source Code Traceability
    2. 3.10 - #FRT10 - Supporting Requirements in a Traceability Approach between Business Process and User Interfaces
    3. 3.11 - #FRT11 - Generation and Validation of Traces between Requirements and Architecture
    4. 3.12 - #FRT12 - Semi-automated Traceability Maintenance - traceMaintainer
    5. 3.2 - #FRT02 - Requirements Traceability in an Heterogeneous Model-based Design Process
    6. 3.3 - #FRT03 - End-to-end Software Traceability
    7. 3.4 - #FRT04 - Pushing Timely Trace Recommendations to Project Stakeholders
    8. 3.5 - #FRT05 - Capturing (semi)automatically traceability relationships from requirements and design decisions to architecture and implementation
    9. 3.6 - #FRT06 - Traceability in secure and dependable software development
    10. 3.7 - #FRT07 - Exploring traces links to source code through testing
    11. 3.8 - #FRT08 - Graph-based traceability
    12. 3.9 - #FRT09 - Architectural Design Decisions Evolution through Model Driven Engineering
  • FUNCTIONAL REQUIREMENTS TRACEABILITY

    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

    3.1 - #FRT01 - Requirement and Source Code Traceability

    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).

    Figure3.1 Process of Capturing, Validating and Creating Traceability Links
     

    Creation To create traceability links, this approach define three model levels (like a class model): (i) system model, contains features and functional requirements; (ii) project model, contains sprints, work items, and developer; and (iii) code model, contains source code file and revision.

    Use The use of the links are supposed to answer some questions like: What is the program supposed to do? Why was this code implemented this way? What have my co-workers been doing? Which code is involved in the implementation of this feature? To move this feature into this code, what else needs to be moved? What will be the impact of this change? Links can be retrieved through the search from any artifact.

    3.10 - #FRT10 - Supporting Requirements in a Traceability Approach between Business Process and User Interfaces

    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.

    Figure3.6 Requirements traceability with models
     

    In this solution (Figure 3.6), when changes are made on BP models, they may impact on requirements or on task models, or even in both simultaneously. Whenever there are impacts in one of them, the other one is alerted with a warning of possible needs for update. In addition, changes on task models have impacts on UIs. On another scenario, when changes are made first on UIs, the impact is on task models, which in their turn impact BP models and also alerts requirements for possible updates. 

    Process support tools This framework has no support tool. 

    Restriction of using This approach is proposed as a complement to other approaches for traceability requirements. 

    How to apply this approach Developers set the approach elements organizing the traceability rules. Reviews in the business processes resulting from new policies impacts in new UIs for the newly created tasks.

    Creation To define the user interaction, a task model is used to describe how tasks can be performed to reach the users’ goals when interacting with the system. These activities contain essential information to conceive all UIs, a means by which users interact with the system. 

    Use Business process and user interfaces changes start the analysis of traceability impact. After that, settings are made to keep the updated model. The change in the business process would generate changes on the UIs related solely to the creation of new screens.

    3.11 - #FRT11 - Generation and Validation of Traces between Requirements and Architecture

    Description This approach provides traces establishment by using semantics of traces between requirements and architecture (R&A). The tool provides the following: (i) generation/validation of traces by using requirements relations and/or verification of architecture, and (ii) generation/validation of requirements relations by using traces. The tool uses the semantics of traces together with requirements relations and verification results for generating and validating traces. Generating traces is the activity of deducing traces between requirements and architecture based solely on verification of architecture and/or the requirements relations. Alternatively, the software architect can provide an initial set of traces as input. Validating traces is the activity of identifying the traces which do not obey trace semantics. This approach is supported by a tool where the main feature is trace generation and validation. The Figure 3.7 presents the tool structure with the inputs and outputs elements.

    Figure3.7 Overview of the tool
     

    The tool checks if the requirements are satisfied by the architecture. This is done by reformulating the requirements in terms of logical formulas over the architecture. 

    Process support tools A tool was developed with the following features: (i) Verification of Architecture for Functional Requirements, (ii) Generation of Traces and (iii) Validation of Traces. The tool uses Maude, a formal language based on equational and rewriting logic, and MDE technologies such as Eclipse EMF and ATL. 

    Restriction of using Maintenance of traces is not covered in this approach. In case of changes in the requirements or in the architecture, some of the traces will be invalid and incomplete. 

    How to apply this approach This approach is supported by a tool. The tool uses the semantics of traces together with requirements relations and verification results for generating and validating traces.

    Creation The first step is to verify the architecture to identify the links to functional requirements. After that, generating traces aims at deducing traces between requirements and architecture based solely on verification of architecture and/or the requirements relations in the requirements model. The verification result, and therefore the traces, depends on the reformulation of the requirement to be checked. Finally, validation aims at identifying the traces which do not obey the trace semantics. The tool uses the semantics of requirements relations together with the trace semantics to validate traces which are already generated or assigned by the architect. Checking is performed according to the constraints derived from the semantics of traces and requirements relations. 

    Use This approach generates a set of informations composed by a model of requirements (produces the reformulated requirements as output), model of traces (using model transformations) and error model (produces the invalid assigned traces). After Identify the output models, eventually mistakes can be manually corrected.

     

    3.12 - #FRT12 - Semi-automated Traceability Maintenance - traceMaintainer

    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.

    Figure3.8 Overview of traceMaintainer components
     

    Creation traceMaintainer create traces by analyzing elementary change events that have been captured while working within a third-party UML modeling tool. Within the captured flow of events, development activities comprised of several events are recognized. These development activities are expressed as predefined rules. Once recognized, the corresponding rule gives a directive to update impacted traceability relations to restore consistency. 

    Use There are two information generated by the traceMaintainer that separate the incoming and outgoing traceability relations involved in the update context. Existing or potential new traceability relation, where the user can decide to keep or delete existing relations on the source elements. For the evolved elements, the user can decide to create or discard the relation. A decision on the proposed relations without preselected determined actions is required to be able to complete the update, while a change of a preselected action is made possible in other cases but not required.

    3.2 - #FRT02 - Requirements Traceability in an Heterogeneous Model-based Design Process

    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.

    3.3 - #FRT03 - End-to-end Software Traceability

    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.

    Figure3.2 End-To-End Software Traceability Model
     

    Creation The users have to register all artifacts traces.

    Use As users perform their tasks, they access globally traced artifacts via the workflow. This allows a close proximity between tasks and related artifacts. Users may also directly access the artifacts outside the workflow.

    3.4 - #FRT04 - Pushing Timely Trace Recommendations to Project Stakeholders

    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.

    Figure3.3 Five-Layered Trace Recommendation Architecture
     

    The approach works as follows (see Figure3.3 ):

    • The first 3 layers are based on existing technologies for traceability.
      • Layer 1 stores conceptual artifacts, such as requirements, design, and code, as well as traceability links.
      • Layer 2 represents a Traceability Information Model (TIM) and is modeled as a UML class diagram.
      • Layer 3 provides facilities for modeling and executing trace queries. In this layer, several traceability query languages can be used: Trace Query Language (TQL), Visual Trace Modeling Language (VTML), among others.
    • Layers 4 and 5 embody algorithms, workflows, and processes to the model. These elements utilize the services provided by lower-level layers to push timely trace recommendations to project stakeholders.
    Restriction of using The approach is partially supported by tools. Traceability links are recommended following the layers presented above. The main restriction of this approach is the difficulty to set the working environment (i.e., all five layers). Different approaches and concepts should be grouped to construct the base of the traceability. After that, it is possible to implement workflows and triggers that enable trace link recommendations. 

    Process support tools
     This approach can use different tools (like Poirot, RETRO and ADAMS) to input a source artifacts, such as requirement, and perform a search to identify a set of potentially related target artifacts. Although, there is no tool to support the entire approach. 

    How to apply this approach To apply the trace recommendation is necessary to follow the concepts presented in Figure 3.3. The objective is to generate and to push timely trace recommendations to developers in order to construct traceability links earlier in the project. 

    Creation To create links is necessary to configure all three layers to build the working model. After that, the two top layers must be built to allow the workflows to generate the recommendations from the implemented triggers.

    Use The use is possible from the recommendations proposed by the traceability structure. Each artifacts creation, deletion or modification triggers the generation of trace recommendations. During the generation process, it is possible to identify and correct traceability problems.

    3.5 - #FRT05 - Capturing (semi)automatically traceability relationships from requirements and design decisions to architecture and implementation

    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.

    3.6 - #FRT06 - Traceability in secure and dependable software development

    Description This approach aims to maintain truly traceability links i.e., the high level of accuracy and change resilience of the links. Secure and dependable software development needs high accurancy and, thus, inaccurate traceability links may be transformed by developers into a point to be explored by malicious attackers. Most of traceability techniques may not recover accurate requirements traceability links that preserve the semantics of traced elements (design to element implementation and vice-versa). Therefore, rediscovering traceability links whenever changes happen must be accurate. To avoid inaccurate links after refactoring a program, the proposed tool is implemented on top of Language Toolkit (LTK) refactoring plugin. LTK is used with Java Development Toolkit (JDT) in Eclipse IDE. The tool, during the refactoring steps, logs all changes made in the program through a declarative specification language. Indeed, LTK writes a XML document that is transformed into the proposed specification language. There is a deamon that monitors whether there is any change to the traceability repository: when changes in artifacts are committed, a run of the tool is triggered to update the traceability links, if it is necessary.

    Process support tools The proposed tool must be run on top of LTK refactoring plugin. Although, LTK supports language beyond Java, this tools is integrated with JDT to work properly. The plugin CruiseControl orchestrate the integration of the proposed tool and Eclipse IDE. A secure extension of UML (called, UMLsec) is used to design the application and establish traceability links among design and element implementations. 

    Restriction of using The tool works on top of LTK plugin under JDT using Eclipse IDE. Thus, the application must be developed in JAVA in Eclipse IDE configured with LTK. CruiseControl must be installed as well. UMLSec must be used in design phase and the proposed approach works with refactoring tasks. 

    How to apply this approach This approach is applied, mainly, in secure and dependable software development since it keeps high accuracy among traceability links. To apply it, users must configure Eclipse IDE to run JDT, LTK and CruiseControl.

    Creation Functional and Security requeriments must be linked with the source code and security aspects of the application. This linking is done through UML Design and UMLsec, respectively. Eclipse IDE must be configured to support the proposed tool (i.e., Eclipse refactoring engine). 

    Use The developer must have Eclipse configured to work with the proposed tool and all steps are automated. There exist two command buttons to the Eclipse GUI, one of them performs all refactoring steps automatically, while the other brings up a dialogue for each step to preview the effects of refactoring.

     

    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.

    3.8 - #FRT08 - Graph-based traceability

    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.

    Figure3.4 Traceability Reference Schema Model
    Process support tools This approach is based on MOLA Tool (MOdel transformation LAnguage). MOLA is a graphic tool based on UML. The graphs environment in implement with JGraLab graph repository. Graphs are queried using GReQL graph query engine.
     
    Restriction of using MOLA cannot deal with graph edges as first-class citizens It means that developers must model binary traceability relationships as vertex classes. The traceability graph repository is very simple, relying on complete reexecution of transformations and demanding manual work from the developers, consequently hurting scalability. 
    How to apply this approach
     Developers must use UML to model the software product. All tools proposed by the approach must be installed and configured: MOLA, tools for UML and grUML, the proposed API for extraction entities and relationship from UML diagrams and JGraLab graph repository.

    Creation Trace links are created form UML diagrams by executing the proposed API. 

    Use After entities and relationship extraction from UML diagrams are stored in the graph repository, all traceability information can be retrieved for visualization and other utilizations. Developers, using graph query language, may find three pattern problems: existence (there must exist a path between two entities so the query cannot return null), reachable entities (given a trace link, the query must return all reachable entities in that trace) and slice (given two entities, queries must return subsets of trace links belonging to the main trace link). These patterns help practitioner to find and to solve traceability problems. 

    3.9 - #FRT09 - Architectural Design Decisions Evolution through Model Driven Engineering

    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.

    Figure3.5 Overview of the proposed approach
     

    Traceability is realized as a set of tracing links from requirements to ADDs and from ADDs to SA descriptions (see the dotted lines in Figure3.5). Tracing links are contained into special models (wmreq and wmSA in shown in Figure3.5). 

    Process support tools The process is supported by a prototype. It was conceived to realize the approach as an Eclipse1 plugin that relies on the Atlas Model Management Architecture (AMMA). 

    Restriction of using This is an approach to support the architectural design decisions evolutions. The main restriction is to create and use the Requirements, SA and ADD models during the software conception phase. 

    How to apply this approach Design decisions must be considered first-class elements when architecting software systems, and they have to be explicitly documented and supported. The strong relationship that design decisions share with requirements and other artifacts needs to be taken into consideration while supporting evolution. Applying this approach, decisions and evolutions are registered, evolutions impact are analyzed and decisions are taken about the software evolution.

    Creation Traceability is realized as a set of tracing links from requirements to ADDs and from ADDs to SA descriptions. Decisions are registered and the trace links are created. The decisions evolutions are analyzed and are presented to the designer that make decisions about the changes. 

    Use The impact of such an evolution can be divided into three main steps (show in Figure 3.5). (1) Evolution identification: all the evolved ADD elements must be timely identified and must be presented to the designer; (2) Inter-decisions analysis: the portion of ADD model which depends on the initial evolved ADD elements identified and their consistency must be checked; (3) Extra-decisions analysis: all requirements and architectural elements depending on the evolved ADD elements are identified and checked against consistency. The changes are checked by the tool and solved by the designer.

  • NON-FUNCTIONAL REQUIREMENTS TRACEABILITY
    1. 4.1 - #NFRT01 - Full Traceability of Non-Functional Requirements within Domain-Specific Modeling
    2. 4.2 - #NFRT02 - Safety Requirements Traceability Support in MDD of Robotic Applications
    3. 4.3 - #NFRT03 - Means-ends and whole-part traceability analysis of safety requirements
    4. 4.4 - #NFRT04 - A SysML-based approach to traceability management and design slicing in support of safety certification
  • NON-FUNCTIONAL REQUIREMENTS TRACEABILITY

    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.

    4.1 - #NFRT01 - Full Traceability of Non-Functional Requirements within Domain-Specific Modeling

    Modeling

    Description This approach intends to manager trace links among non-functional requirements. It is based on NFR framework that tackles the difficult to manage non-functional requirements by decomposing them into sets of smaller subgoals. NFR+ Framework extends NFR framework by adding traceability management. MetaEdit+ is a implementation of NFR+ Framework. The idea in this approach is from non-functional requirements create smaller and quantifiable requirements (called softgoals) that are linked by softgoal interdependency graphs (SIG). Quantifiable requirements are non-functional requirements that can be evaluate. For example, instead of a requirement be The user cannot wait long for his/her request, it should be The user must wait at most 5 seconds for his/her request. In the SIG, developers have to inform, among others, values for every decomposed requirement. Thus, non-functional requirements are decomposed and SIGs are built from this decomposition. SIG may have connection to other SIGs and trace links are created from the SIGs and the interconnection of the SIGs. MetaEdit+ may work with Open Source Requirement Management Tool (OSRMT) by exchanging XML documents. Individual model types are proposed to make easier to manage to softgoals. These models are called catalogs and there exists four of them: (i) type catalog that stores knowledge of a softgoal, (ii) method catalog that shows the possible operationalizations for softgoals (e.g., programs), (iii) correlation catalog that contains information on the implicit interdependencies among softgoals (e.g., a softgoal can hurt another one, it means, the way a non-functional requirement is implemented may harm another non-functional requirement), and (iv) contribution catalog that is a special SIG graph defining the outcome of pairs of child labels and contributions. The three first catalogs are proposed in the original framework (NFR) and the last one is part of the proposed extension. Contribution catalog allows developers to identify the contribution symbols for each part of a softgoal. Notice that a softgoal and its parts are represented by nodes in SIG and arcs that connect these nodes may be labeled with the kind of contribution connected nodes have to each other. This approach provides the traceability of non-functional requirements from early user requirements to implementation and testing, and backwards. 

    Process support tools MetaEdit+ is implemented in Java and the graphs are implemented in Python. The user may configure MetaEdit+ to work with OSRMT. 

    Restriction of using This approach must be used within domain-specific modelling since it needs an initial project model to set MetaEdit+.

    How to apply this approach The product must be designed using Domain-Specific Modeling and non-functional requirements must be decomposed into quantifiable softgoals.

    Creation All functional requirements may be managed by OSRMT and MetaEdit+ manages only non-functional ones. Both tools are integrated by XML documents. Developers import and export requirements from and to both tools. 

    Use Non-functional requirements may be managed automatically: when the tool find an inconsistency in the graphs, it requires developers to fix the problem. The approach is a bridge between requirements and meta-case tools, thus, developers must use both technologies with MetaEdit+.

    4.2 - #NFRT02 - Safety Requirements Traceability Support in MDD of Robotic Applications

    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.

    Figure4.1 Traceability metamodel
     
    Use Once the traceability is generated, a report with the traced elements can be obtained using the Safety-Requirements-Trace-Tool (SRTT). This report analyzes the different models level to generate the informations and it was developed whit the tool that support the approach. With this report, designers can examine the way in which a requirement has been taken into account in the automatic code generation process and receive information on the solution adopted, which in some cases will be a design pattern.

    4.3 - #NFRT03 - Means-ends and whole-part traceability analysis of safety requirements

    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.

    Figure4.2 Approach concepts
     
     

    In the proposed approach, during the development, the why information such as the system goals, constraints, and safety requirements are incorporated into the next level of means-ends hierarchy with the whywhathow relationships in order to develop the system artifacts until the physical products have been developed. In the safety analysis part, the traditional cause-event techniques like FMEA, HAZOP, and FTA are also conducted with the same why-what-how relationships through out a lifecycle. The approach also acknowledges the complementary relation between a system development and a safety analysis.

    Process support tools The approach is supported by two tools: TRACE (Traceability of Requirements for Analysable Computerised Environments) and NuSRS (Nuclear software requirements specification). NuSRS is a tool for supporting a specification and verification of software requirements for a digital plant protection system in nuclear power plants. 

    Restriction of using Approach restrictions are the nature of the traceability aim. In this case, traceability analysis of safety requirements. Also the tools are restricted since they are constructed specially for this approach.

    How to apply this approach This approach is conceived to use TRACE and NuSCR tools. To apply this approach is necessary to use TRACE to link all the nodes in the NuSCR requirement specification with other information like the design specification and safety analysis result. The traceability analysis tool, TRACE, can be used to link the artifacts from the system development and the safety analysis. And also the requirements specification tool, NuSRS, can be used to elicit, spedify, and enforce the requirements including the safety constraints.

    Creation TRACE can be used to link all the nodes in the NuSCR requirement specification with other information like the design specification and safety analysis results. The link between TRACE and NuSCR enables the traceability in two dimensions, means-end (goal and system safety objectives, system requirements, components requirements, component design and component product) and whole-part (system, human, software and hardware). To create the links, during the system specification, the engineers make the links between the objects in two dimensions. 

    Use Results can be obtained by reading the tools registered links. The safety analysis is the main result given by the tools.

    4.4 - #NFRT04 - A SysML-based approach to traceability management and design slicing in support of safety certification

    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.

    Figure4.3 Methodology for model-driven development of control systems
     

    Creation The links creation are taken by the tool. 

    Use This approach has the intention to help the safety certifications. In this way, the use of the traces generated during the system conception will happen during the inspections.

  • SOFTWARE PRODUCT LINE TRACEABILITY
    1. 5.1 - #SPLT01 - A Metamodeling Approach to Tracing Variability between Requirements and Architecture in SPL
    2. 5.2 - #SPLT02 - Traceability in Software Product Line using Formal Concept Analysis
    3. 5.3 - #SPLT03 - A rule-based traceability approach for product line systems
  • SOFTWARE PRODUCT LINE TRACEABILITY

    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.

    5.1 - #SPLT01 - A Metamodeling Approach to Tracing Variability between Requirements and Architecture in SPL

    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.

    Figure5.1 Metamodel of domain requirement
     

    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).

    5.2 - #SPLT02 - Traceability in Software Product Line using Formal Concept Analysis

    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):

    Figure5.4 Traceability Identification Approach
     

    The first step consist of extracting functional decomposition from feature description and architecture description. The second step is building concept lattice using FCA tool. The final step is analyzing concept lattice to identify mapping elements. 

    Process supporte tools There is no related tool that work with this approach.

    Restriction of using This approach is applicable for software development based on functional decomposition. Also is necessary to develop feature model and architecture model. Another restriction is a missing tool for automate this approach. 

    How to apply this approach This approach is a concept proposed to create a lattice to identify the traces between feature model and architecture model in product line. To apply this approach is necessary to support the concepts by a tool or tools.

    Creation The creation of the traces is presented in Figure 5.4. To create traces is necessary to identify the relations between feature and architecture models. This step can be automated using the extraction algorithms, however, the approach does not present these algorithms. The traces are derived from the first step information. To finalize the creation of traces is still necessary to analyze the lattice concepts. This step answers some questions about feature and architecture elements identified: (i) They exactly have same functional decomposition? (ii) the feature element is implemented by the architecture element?, and (iii) the feature element is implemented by several architecture elements? 

    Use To identify mapping relationship, the meaning of concept lattice representation have to be interpreted. A mechanism for retrieving the traceability is not available in this approach.

    5.3 - #SPLT03 - A rule-based traceability approach for product line systems

    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.

  • GLOSSARY
  • GLOSSARY

    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 = (RelevantLinksRetrievedLinks)\ 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.

  • REFERENCES
  • REFERENCES

    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.

    Back to Top