Requirements traceability

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]

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