Requirements traceability is a sub-discipline of requirements management within software development and systems engineering. Traceability as a general term is defined by the IEEE Systems and Software Engineering Vocabulary[1] as (1) the degree to which a relationship can be established between two or more products of the development process, especially products having a predecessor-successor or primary-subordinate relationship to one another;[2] (2) the identification and documentation of derivation paths (upward) and allocation or flowdown paths (downward) of work products in the work product hierarchy;[3] (3) the degree to which each element in a software development product establishes its reason for existing; and (4) discernible association among two or more logical entities, such as requirements, system elements, verifications, or tasks.

Requirements traceability in particular, is defined as "the ability to describe and follow the life of a requirement in both a forwards and backwards direction (i.e., from its origins, through its development and specification, to its subsequent deployment and use, and through periods of ongoing refinement and iteration in any of these phases)".[4][5] In the requirements engineering field, traceability is about understanding how high-level requirements – objectives, goals, aims, aspirations, expectations, business needs – are transformed into development ready, low-level requirements. It is therefore primarily concerned with satisfying relationships between layers of information (aka artifacts).[6] However, traceability may document relationships between many kinds of development artifacts, such as requirements, specification statements, designs, tests, models and developed components.[7] For example, it is common practice to capture verification relationships to demonstrate that a requirement is verified by a certain test artifact.

Traceability is especially relevant when developing safety-critical systems and therefore prescribed by safety guidelines, such as DO178C, ISO 26262, and IEC61508. A common requirement of these guidelines is that critical requirements must be verified and that this verification must be demonstrated through traceability.[8]

Tracing towards and beyond the requirements

Pre-requirements traceability.[4] Requirements come from different sources, like the business person ordering the product, the marketing manager and the actual user. These people all have different requirements of the product. Using requirements traceability, an implemented feature can be traced back to the person or group that wanted it during the requirements elicitation. This can be used during the development process to prioritize the requirement, determining how valuable the requirement is to a specific user. It can also be used after the deployment to see why certain unused features found during user studies were required in the first place.

Post-requirements traceability.[4] Not only the requirements themselves should be traced but also the requirements relationship with all the artifacts associated with it, such as models, analysis results, test cases, test procedures, test results and documentation of all kinds. Even people and user groups associated with requirements should be traceable. Requirements are realized into design artifacts, implementation, and finally, verified. Artifacts tied to the latter stages should be traced back to the requirements as well. This is typically done via a requirements traceability matrix.

Establishing traceability beyond requirements into design, implementation, and verification artifacts can become difficult.[9] When implementing software requirements for instance, the requirements may be in a requirements management tool, while the design artifacts may be in a design tool . Furthermore, implementation artifacts will likely be in the form of source files, links to which can be established in various ways at various scopes. Verification artifacts such as those generated by internal tests or formal verification tools.

Repository or tool stack integration can present a significant challenge to maintaining traceability in a dynamic system.

Usage of traceability information

The usage of traceability, especially when tracing beyond requirements to all artifacts located in the tool chain, can bring several benefits:[10][11]

A more complete overview of development activities supported by traceability and their relevance is given in.[12]

Practical use of traceability information

Extensive studies document the effectiveness, but also the difficulties of capturing traceability information:

Visualization of traceability information

One goal of traceability is to visualize the relationship between artifacts. As the number and complexity of trace links increases, techniques for traceability visualization are necessary. A visualization can include information about the artifacts (e.g. artifact type, metadata, attributes) and links (e.g. link type, metadata, link strength).[16]

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

Visualizations can be combined to overcome their specific limitations.

Technical realization

Manual traceability

Traceability is realized by capturing traces either entirely manual or tool supported, e.g. as spreadsheet in Microsoft Excel. Though widely applied, this process is cumbersome, error-prone, and often leads to traceability information that is of insufficient quality due to the various involved development tools and the typically very high number of artifacts to be traced.[18]

Tool-supported traceability

Tool-supported traceability requires that development information that is distributed across a whole chain of development tools to be homogenized and aggregated. The following approaches exist for reaching this state:

Homogenization of the software tool environment via an ALM tool – ALM tool chains cover the software development life-cycle and manage all artifacts of the software development process. Many companies have chosen a best-of-breed approach with task management, code management and numerous test automation tools. Companies that choose a best-of-breed approach solve the traceability challenge with requirements management (RM) tools that provide a complete traceability model and integrations for the best of breed tools. A single ALM tool to cover requirements, risk analysis, system design, task management, code repositories, integration, testing and more is a classic trade-off between best-of-breed capabilities vs. a more limited feature, common platform.

Homogenization of data via surrogate requirements – requirements management (RM) tools allow storing, organizing, and managing all requirements of a system's specifications and typically arrange them in a specification tree that links each requirement to its parent requirement in the higher specification. Typical analysis functions based on recorded traceability information are, e.g., completeness checks i.e. do all system level requirements go down to equipment level (with or without modification), assessment of requirements deviations over all levels, and qualification status presentation. In order to ensure traceability to artifact types beyond requirements, RM tools often allow to import other artifacts as surrogate requirements that can then be traced with the tool's requirements tracing methods. The disadvantage of this approach is that different adapters or converters for the different artifact types are necessary that need to have a consistent version and data format. In contrast to ALM tools this consistency must be carried out oneself.

Homogenization of data via a dedicated traceability tool - the basic concept of dedicated traceability tools consists of three essential steps:

The approach unions the advantages of the aforementioned approaches: It covers all tools and artifacts in a holistic approach, homogenizes data and avoids the risk of inconsistencies caused by outdated surrogates. The disadvantage is that this approach implies the extension of a toolchain by another (traceability) tool.

Traceability Tools

In many projects, people use office tools like spreadsheets for managing traceability. These tools are error-prone when you have hundreds of requirements and multiple users working on a project. You may use specialized traceability tools for effective control of your projects.

See also

References

  1. ^ Systems and software engineering -- Vocabulary. Iso/Iec/IEEE 24765:2010(E). 2010-12-01. pp. 1–418. doi:10.1109/IEEESTD.2010.5733835. ISBN 978-0-7381-6205-8.
  2. ^ IEEE Guide for Developing System Requirements Specifications. 1998 Edition IEEE STD 1233. 1998-12-01. pp. 1–36. doi:10.1109/IEEESTD.1998.88826. ISBN 978-0-7381-1723-2.
  3. ^ IEEE Guide for Information Technology - System Definition - Concept of Operations (ConOps) Document. IEEE STD 1362-1998. 1998-12-01. pp. 1–24. doi:10.1109/IEEESTD.1998.89424. ISBN 978-0-7381-1407-1.
  4. ^ a b c Gotel, O.C.Z.; Finkelstein, C.W. (April 1994). "An analysis of the requirements traceability problem". Proceedings of IEEE International Conference on Requirements Engineering. pp. 94–101. CiteSeerX 10.1.1.201.7137. doi:10.1109/icre.1994.292398. ISBN 978-0-8186-5480-0. S2CID 5870868.
  5. ^ Gotel, Orlena; Cleland-Huang, Jane; Hayes, Jane Huffman; Zisman, Andrea; Egyed, Alexander; Grünbacher, Paul; Dekhtyar, Alex; Antoniol, Giuliano; Maletic, Jonathan (2012-01-01). "Traceability Fundamentals". In Cleland-Huang, Jane; Gotel, Orlena; Zisman, Andrea (eds.). Software and Systems Traceability. Springer London. pp. 3–22. doi:10.1007/978-1-4471-2239-5_1. ISBN 9781447122388.
  6. ^ Hull, Elizabeth; Ken Jackson; Jeremy Dick (2005). Requirements Engineering (Second ed.). Springer. pp. 9–13, 131–151. ISBN 978-1-85233-879-4.
  7. ^ Pinheiro F.A.C. and Goguen J.A., "An object-oriented tool for tracing requirements", IEEE Software 1996, 13(2), pp. 52-64
  8. ^ a b Mäder, P.; Jones, P. L.; Zhang, Y.; Cleland-Huang, J. (2013-05-01). "Strategic Traceability for Safety-Critical Projects". IEEE Software. 30 (3): 58–66. doi:10.1109/MS.2013.60. ISSN 0740-7459. S2CID 16905456.
  9. ^ Li, Yin; Juan Li; Ye Yang; Mingshu Li (2008). Requirement-Centric Traceability for Change Impact Analysis:A Case Study. Springer Berlin/Heidelberg. pp. 100–111. ISBN 978-3-540-79587-2.
  10. ^ Wiegers, Karl (2013). "Requirements Traceability: Links in the Requirements Chain, Part 1". jama. Retrieved 2016-12-14.
  11. ^ Wiegers, K.; Beatty, J. (2013). Software Requirements. Microsoft Press.
  12. ^ Bouillon, Elke; Mäder, Patrick; Philippow, Ilka (2013-04-08). "A Survey on Usage Scenarios for Requirements Traceability in Practice". In Doerr, Joerg; Opdahl, Andreas L. (eds.). Requirements Engineering: Foundation for Software Quality. Lecture Notes in Computer Science. Vol. 7830. Springer Berlin Heidelberg. pp. 158–173. CiteSeerX 10.1.1.659.3972. doi:10.1007/978-3-642-37422-7_12. ISBN 9783642374210.
  13. ^ Mäder, Patrick; Egyed, Alexander (2015-04-01). "Do developers benefit from requirements traceability when evolving and maintaining a software system?". Empirical Software Engineering. 20 (2): 413–441. doi:10.1007/s10664-014-9314-z. ISSN 1382-3256. S2CID 2514618.
  14. ^ Rempel, Patrick; Mäder, Patrick (2016-01-01). "Preventing Defects: The Impact of Requirements Traceability Completeness on Software Quality". IEEE Transactions on Software Engineering. PP (99): 777–797. doi:10.1109/TSE.2016.2622264. ISSN 0098-5589. S2CID 1959772.
  15. ^ "open-DO | Toward a cooperative and open framework for the development of certifiable software". www.open-do.org. Retrieved 2017-04-15.
  16. ^ a b c d e f Li, Y.; Maalej, W. (2012). Which Traceability Visualization Is Suitable in This Context? A Comparative Study. Springer. pp. 194–210.
  17. ^ Lerche, Felix (2019). "5 REASONS WHY A REQUIREMENTS TRACEABILITY MATRIX IS NOT ENOUGH".
  18. ^ Kannenberg, Andrew; Saiedian, Hossein (2009). "Why Software Requirements Traceability Remains a Challenge" (PDF). CrossTalk Magazine - the Journal of Defense Software Engineering.
Categories