The term requirements traceability originates from the field of software development and systems engineering.
Requirements traceability is the ability to follow the relations of a requirement to other requirements or work products, also known as artifacts. Typical artifacts are specifications, test cases, software units, source code and test results.
Traceability is achieved by establishing links between those artifacts. This applies especially if they have a direct relation – e.g. a from a requirement to the belonging test. By doing so, a hierarchy of interlinked artifacts is created.
A pragmatic approach to apply traceability is to set up a table that displays the relations between different artifacts. This table is the requirements traceability matrix. It is even possible to set up a matrix that illustrates relations between several (i.e. more than two) types of artifacts.
Relations from “Requirement” to “Validation” can be maintained in any basic spreadsheet tool.
For complex projects comprising hundreds of thousands of artifacts, a matrix may not be suitable. Instead, you may want a tool that helps you to link artifacts, or even better, which derives the links for you. You also may expect several means to analyze these relations, e.g. find all requirements that are related to failing test cases. Such tools manage traceability based on a data model that defines the types of artifacts and relations between them. This data model is a so-called Traceability Information Model (TIM).
Stakeholder requirements can be linked to System requirements, System requirements can be linked to System architecture elements, etc.
The TIM in the above picture illustrates that traceability between stakeholder requirements and any type of test case is (mediately) given because there exists a well-defined chain of links.