Traceability (requirements management)

from Wikipedia, the free encyclopedia

In system and software development, traceability (also traceability or requirements traceability ) refers to the assignability of requirements to any artifacts over the entire development process and is therefore part of requirements management . Traceability is particularly relevant in the development of safety-critical systems, where standards and guidelines such as ISO 26262 , Automotive SPICE , and EN 50128 require the recording of requirements traceability in order to be able to prove that critical requirements have been appropriately implemented and validated.

Concepts and Terminology

Requirements traceability occurs when artifacts from a development process are linked using a trace link . Each trace link connects exactly one source artifact with one target artifact. The set of all trace links and linked artifacts of a development project form the edges and nodes of a graph , which can be analyzed and evaluated using methods of graph theory in order to evaluate the quality of the development project.

Which artifacts are linked in a project is defined in a Traceability Information Model (TIM) . A TIM is a metamodel that defines project-specific the trace link types to be recorded (e.g. trace between source code and test case) and the linked artifact types (e.g. requirement, component, test case). A TIM enables even with a large number of stakeholders in a development project to achieve consistent traceability quality and to make this testable.

Use of traceability information

The use of recorded traceability information supports numerous development activities:

  • Impact Analysis (English Impact Analysis.) Changes - changes a requirement to enter the trace left tells you what other artifacts with this in relationship. These can easily be checked and modified if necessary.
  • Coverage analysis (engl. Coverage Analysis) - unlinked requirements are an indication that the specified functionality has not been fully implemented. For the certification process of safety-critical systems in particular, it must be demonstrated that all (safety) requirements have been fully implemented and tested.
  • Project status analysis - the completeness of the traceability graph specified by TIM gives an overview of the status and progress of a development project. For example, requirements without a trace link or with linked source code , but without a test, are still in development.
  • Reuse of product components - with the help of trace links, requirements including all realizing artifacts can be summarized in units and used for different products.
  • Persistence of connections - knowledge about a development is often only anchored in the minds of individual people. Trace links store this knowledge and visualize connections between artifacts. Even when stakeholders leave a project, their knowledge is retained.
  • Test optimization - by linking requirements , source code , test cases and test results , after changes and errors, it is possible to quickly identify which tests need to be carried out and where identified errors are located.

Provides a more comprehensive overview of supported development activities and their relevance.

Traceability challenges

The consistent collection of traceability information is associated with several difficulties:

  • High acquisition costs - Today's development projects with a large number of artifacts require a large number of trace links and an enormous amount of effort to acquire them. For example, tens of thousands of requirements and the resulting large amounts of design artifacts , source code and test cases are common in development projects in the automotive industry .
  • Heterogeneous development tools - Different development artifacts such as requirements , software design , source code or test protocols are often created and managed with individual tools. Many tools are not interoperable and do not allow cross-tool traceability. Artifact data from heterogeneous tools must therefore be homogenized in a complex manner.
  • Complex analyzes - artifacts are often not linked directly, but indirectly via other artifacts. For traceability analyzes, it is above all paths (Trace Path) and subtrees in the trace graph that must be considered. An evaluation therefore requires potentially complex algorithms based on depth or breadth-first search.

Because of these challenges, the desired degree of traceability should be planned consciously and supported by means of suitable traceability software solutions.

Traceability in practice

Comprehensive studies document the effectiveness, but also the difficulties of collecting traceability information:

  • Traceability accelerates and improves development activities - A study with 71 test persons who carried out source code changes with and without traceability support shows clear advantages of traceability. Developers completed tasks with traceability support 24% faster and 50% more correctly.
  • More complete traceability helps avoid programming errors (bug, defect) - When analyzing development data from 24 medium-sized and large open source projects, a statistically significant correlation between the completeness of the recorded traceability information and the error rate of the developed source code was demonstrated. Components with more complete traceability exhibited fewer errors.
  • Achieving compliant traceability is difficult - An analysis of the submissions for the pre-market testing of software in medical devices to the US Food and Drug Administration (FDA) from 2013 identified significant gaps between submission and regulatory requirements in the area of ​​traceability. The time-consuming process of achieving standard-compliant traceability is referred to as “big freeze”. A big freeze often avoids further development, because renewed certification is associated with enormous effort.

Visualization of traceability information

One goal of traceability is to show the relationships between individual artifacts. As the number and complexity of the links increase, techniques for visualizing the trace links are required. Relevant information on the artifacts (e.g. what type it is, metadata on the life cycle and attributes) and their trace links (link type, i.e. which artifacts are linked to one another, metadata on the life cycle or the link strength) should also be mappable.

Common visualizations are traceability matrices , graphs , lists and hyperlinks .

  • Traceability Matrix - A traceability matrix is ​​a tabular representation in which the artifacts of one type (e.g. requirements) are shown in columns and the artifacts of another type in lines (e.g. source text). Cells visualize the linking (value) or non-linking (empty cell) of two artifacts. Matrices can easily provide an overview of all trace links and are therefore particularly suitable for management tasks. But with high numbers of artifacts, matrices also become confusing.
  • Traceability Graph - A traceability graph visualizes artifacts as nodes and trace links as edges. Graphs are particularly suitable for development tasks and enable an exploratory overview of links to be obtained. Graphs are characterized by a high level of understandability of the information shown. By navigating through the graphs, it is easy to identify where links and artifacts are missing.
  • Lists - Lists represent each trace link as an entry consisting of the source artifact, target artifact and associated attributes. Lists are particularly suitable when actions are to be carried out on several artifacts at the same time and facilitate filtering and sorting. However, compared to the other two visualizations, lists are perceived as less suitable for carrying out project management, development or test tasks.
  • Hyperlinks - Hyperlinks between artifacts allow easy and fast navigation between linked artifacts. Hyperlinks make it possible to navigate between artefacts in their natural environment and at the same time view context information there. Hyperlinks have the disadvantage that it is difficult to get an overview of all the links in a project.

Visualizations can be combined to counteract the respective disadvantages.

technical realization

Manually

Traceability is achieved manually in that trace links are recorded manually or with the aid of tools in a data structure, e.g. B. as a spreadsheet in Microsoft Excel . Although widespread, this procedure is complex, error-prone and leads to statements of poor quality.

Tool-based

Tool-supported traceability requires that development information that is distributed across various tools can be homogenized and summarized. There are the following approaches:

  • Homogenization of the tool landscape using ALM tools - ALM tool chains homogeneously cover the entire software and system development process and manage all artifacts in a database. The advantage of this approach is that, due to the homogenization, the linking of artifacts can be easily managed and evaluated. The disadvantage here is that an ALM tool chain has to be implemented as a whole and that individual tools in this chain can only be exchanged with difficulty. There is a threat of a “big freeze” (see above) for the tool chain.
  • Homogenization of the data as quasi-requirements - requirements management tools offer comprehensive traceability functionalities between requirements. In order to link other artifacts of the development process, tools like IBM Rational DOORS offer the possibility to import external artifacts as "quasi-requirements" (e.g. Matlab models as so-called surrogates). This process is supported by many tools established on the market. Disadvantages are the different adapters and converters which are required for each artifact type and which have to be consistent in version and data format. In contrast to an ALM tool chain, you have to ensure the consistency of the adapters and converters individually.
  • Homogenization of the data by means of a dedicated traceability tool - The approach of dedicated traceability tools is to extract relevant information from the artifacts of a development process and to bring it together in a uniform traceability model. The extraction from the tools takes place via adapters, which can be created for any, including proprietary, tools. Dedicated traceability tools combine the advantages of the two aforementioned approaches: the consistency of the adapters and converters is ensured by the provider of the traceability tool, while the flexibility of the tool chain is ensured by adaptable interfaces in the tool itself. Due to the flexibility of these tools, when defining the traceability information model, not only must the artifact types and their links be defined, but the technical connection to the corresponding tool must also be configured.

Dedicated traceability tools

Capra

Capra is a dedicated traceability management tool that enables the creation, administration, visualization and analysis of traceability links between models in different DSMLs, programming languages ​​and other artifacts such as tasks and tests within Eclipse . Capra emerged from the EUREKA / ITEA research project AMALTHEA4public. The tool is available as open source under EPL .

Reqtify

Reqtify is an easy-to-use, interactive application to manage requirements. It enables traceability and impact analyzes over the entire life cycle in hardware and software development. Reqtify is a commercial tool from Claytex.

Reqchecker

Reqchecker is free software. It works like Reqtify and adds playback functionality. The HMI is in German.

YAKINDU traceability

YAKINDU Traceability enables uncomplicated and adaptable traceability management - for example, to meet standards such as ISO 26262 . YAKINDU Traceability is a commercial product from itemis and, like Capra, originated in the EUREKA research project AMALTHEA.

Tool selection

The decision for a traceability solution is not a trivial one, since the supposedly simple and inexpensive solutions often turn out to be inadequate and not maintainable in the course of development. Therefore the decision for a tool should be the result of a systematic analysis.

literature

  • Cleland-Huang, Gotel, Zisman: Software and Systems Traceability, London, Dordrecht, Heidelberg, New York 2012, ISBN 978-1-4471-2238-8 .
  • Mary Beth Chrissis: CMMI Top10 Interpretation Issues. (PDF; 2.6 MB) CarnegieMellon Software Engineering Institute, Pittsburgh 2004, pp. 8–9.
  • Chris Rupp: Requirements engineering and management . 4th edition. Hanser, Munich, Vienna 2007, ISBN 3-446-40509-7 , pp. 409-442 .
  • Karl E. Wiegers, Joy Beatty: Software Requirements, Microsoft Press, Redmond, Washington 3rd Edition 2013, ISBN 978-0-7356-7966-5 .

Individual evidence

  1. ↑ Gothel, Finkenstein: An analysis of the requirements traceability trouble . In: Proceedings of the 1st IEEE International Conference on Requirements Engineering . Colorado Springs, CO, USA 1994, p. 94 ff .
  2. ↑ a b P. Rempel, P. Mäder: A quality model for the systematic assessment of requirements traceability . In: 2015 IEEE 23rd International Requirements Engineering Conference (RE) . August 1, 2015, p. 176–185 , doi : 10.1109 / RE.2015.7320420 ( ieee.org [accessed December 18, 2016]).
  3. ↑ P. Mader, O. Gotel, I. Philippow: Getting back to basics: Promoting the use of a traceability information model in practice . In: 2009 ICSE Workshop on Traceability in Emerging Forms of Software Engineering . May 1, 2009, p. 21-25 , doi : 10.1109 / TEFSE.2009.5069578 ( ieee.org [accessed December 18, 2016]).
  4. ↑ a b Orlena Gothel, Jane Cleland-Huang, Jane Huffman Hayes, Andrea Zisman, Alexander Egyed: Traceability Fundamentals . In: Software and Systems Traceability . Springer London, 2012, ISBN 978-1-4471-2238-8 , pp. 3–22 , doi : 10.1007 / 978-1-4471-2239-5_1 ( springer.com [accessed December 18, 2016]).
  5. ^ Karl Wiegers, Joy Beatty: Software Requirements . Ed .: Microsoft. tape 3 .
  6. ↑ Karl Wiegers: Requirements Traceability: Links in the Requirements Chain, Part January 16, 2013, accessed December 13, 2016 (English).
  7. ↑ Elke Bouillon, Patrick Mäder, Ilka Philippow: A Survey on Usage Scenarios for Requirements Traceability in Practice . In: Requirements Engineering: Foundation for Software Quality (=  Lecture Notes in Computer Science ). No. 7830 . Springer Berlin Heidelberg, 2013, ISBN 978-3-642-37421-0 , p. 158–173 , doi : 10.1007 / 978-3-642-37422-7_12 ( springer.com [accessed December 18, 2016]).
  8. ↑ a b Alexander Egyed, Paul Grünbacher, Matthias Heindl, Stefan Biffl: Value-Based Requirements Traceability: Lessons Learned . In: Design Requirements Engineering: A Ten-Year Perspective (=  Lecture Notes in Business Information Processing ). No. 14 . Springer Berlin Heidelberg, 2009, ISBN 978-3-540-92965-9 , pp. 240-257 , doi : 10.1007 / 978-3-540-92966-6_14 ( springer.com [accessed December 18, 2016]).
  9. ^ Houdek: Managing Large Scale Specification Projects . In: 19th Intl. Working Conference on Requirements Engineering: Foundation for Software Quality . Essen, Germany 2013 ( refsq.org [PDF]).
  10. ↑ Patrick Mäder, Alexander Egyed: Do developers benefit from requirements traceability when evolving and maintaining a software system? In: Empirical Software Engineering . tape 20 , no. 2 , June 22, 2014, ISSN  1382-3256 , p. 413-441 , doi : 10.1007 / s10664-014-9314-z ( springer.com [accessed December 18, 2016]).
  11. ↑ P. Rempel, P. Mäder: Preventing Defects: The Impact of Requirements Traceability Completeness on Software Quality . In: IEEE Transactions on Software Engineering . PP, no. 99 , January 1, 2016, ISSN  0098-5589 , p. 1–1 , doi : 10.1109 / TSE.2016.2622264 ( ieee.org [accessed December 18, 2016]).
  12. ^ A b P. Mäder, PL Jones, Y. Zhang, J. Cleland-Huang: Strategic Traceability for Safety-Critical Projects . In: IEEE software . tape 30 , no. 3 , May 1, 2013, ISSN  0740-7459 , p. 58-66 , doi : 10.1109 / MS.2013.60 ( ieee.org [accessed December 12, 2016]).
  13. ↑ About Open-DO. In: www.open-do.org. Retrieved December 12, 2016 .
  14. ↑ a b c d e f Yang Li, Walid Maalej: Which Traceability Visualization Is Suitable in This Context? A Comparative Study. In: Lecture Notes in Computer Science . 7195th edition. Requirements engineering: Foundation for Software Quality. 2012, p. 194-210 .
  15. ↑ Know the traceability requirements and implement them efficiently with ALM . In: All-Electronics.de . November 25, 2015 ( all-electronics.de [accessed December 12, 2016]).
  16. ↑ IBM Rational DOORS Traceability - MATLAB & Simulink. (No longer available online.) In: de.mathworks.com. Archived from the original on May 22, 2016 ; Retrieved December 19, 2016 . Info: The archive link was inserted automatically and has not yet been checked. Please check the original and archive link according to the instructions and then remove this notice. @1@ 2Template: Webachiv / IABot / de.mathworks.com
  17. ^ Eclipse Foundation: Eclipse Capra . In: projects.eclipse.org . July 28, 2016 ( eclipse.org [accessed July 6, 2017]).
  18. ↑ Reqchecker
  19. ↑ YAKINDU traceability. itemis AG, accessed on February 4, 2020 (English).
  20. ↑ Orlena Gothel, Patrick Maeder: Acquiring tool support for traceability . In: Software and Systems Traceability . Springer London, 2012, ISBN 978-1-4471-2238-8 , pp. 43-68 , doi : 10.1007 / 978-1-4471-2239-5_3 ( springer.com [accessed December 18, 2016]).