The Role of Traceability in Systems Development


Experience has shown that the ability to trace requirements artifacts through the stages of specification, architecture, design, implementation, and testing is a significant factor in assuring a quality software implementation. The ability to track these relationships and to analyze the impacts of changes forms a key thread throughout many modern high-assurance software processes, particularly in life-critical medical products and business- or mission-critical activities.

Historical safety data has demonstrated that missing or unaddressed requirements and/or the impacts of changes are often missed and that small changes to a system can create significant safety and reliability problems. This has caused some regulatory agencies to mandate traceability as an integral part of the development process. For example, the latest U.S. Food and Drug Administration (FDA) guidance for traceability in medical software development activities is contained in the FDA Office of Device Evaluations (ODE) Guidance Document [FDA 1998]. In addition, the Design Controls section of the medical Current Good Manufacturing Practices (CGMP) document [FDA 1996], Subpart C of the CGMP, defines the obligations of the system designers to be able to trace relationships between various work products within the lifecycle of the product's development.

If traceability has been mandated for your project due to some regulatory or internal process standards, then your team won't have any choice. If it has not been mandated , then your team will need to decide whether to apply implicit and explicit requirements traceability or not, and if so, how much traceability is required to assure the outcome you need. We'll revisit this discussion again in just a bit, but first let's look at what traceability is and how to apply it.

For a starting point, IEEE [1994] provides the following compound definition of traceability.

  • "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 master-subordinate relationship to one another; for example, the degree to which the requirements and design of a given software component match." (IEEE 610.12-1990 §3)

  • "The degree to which each element in a software development product establishes its reason for existing; for example, the degree to which each element in a bubble chart references the requirement it satisfies." (IEEE 610.12-1990 §3)


Managing Software Requirements[c] A Use Case Approach
Managing Software Requirements[c] A Use Case Approach
ISBN: 032112247X
Year: 2003
Pages: 257 © 2008-2017.
If you may any questions please contact us: