Requirements traceability
Requirements traceability is the ability to describe and follow the life of a requirement in both a forward and backward direction. It links requirements to their origins and to other development artifacts like designs, code, and tests, ensuring all requirements are addressed and facilitating change management.
First used·1980s
Definitions·1
Synonyms·1
Category·Software Engineering
Also known as
Definitions
What it means.
- 01
Requirements Traceability in Software and Systems Engineering
In the context of software and systems engineering, Requirements Traceability is the process of tracking the life of a requirement throughout the entire development lifecycle. It involves documenting the relationships between requirements and other project artifacts, such as business goals, design specifications, source code, and test cases.
This process provides bi-directional visibility, meaning you can follow a requirement's path both forwards and backwards.
Forward Traceability: This involves tracing a requirement from its source to its implementation. For example, linking a specific business need to the functional requirements, then to the design documents, the code modules that implement it, and finally to the test cases that verify it. It answers the question, "Have we implemented all the specified requirements?"
Backward Traceability: Also known as pre-traceability, this involves tracing an artifact from the implementation back to its source requirement. For example, looking at a piece of code or a test case and identifying which specific requirement it fulfills. It answers the question, "Why does this feature exist?" and helps prevent scope creep or "gold plating" (adding unrequested features).
A common tool used to manage this is the Requirements Traceability Matrix (RTM), a table that maps these relationships. Effective traceability is crucial for impact analysis, change management, verification, and proving compliance with industry standards.
Origin
Where it comes from.
Etymology
The term is a compound of "requirements" and "traceability". "Requirement" originates from the Old French "requerre," meaning "to seek or ask for." "Traceability" is derived from "trace," from the Old French "tracier," meaning "to follow or track," combined with the suffix "-ability." Together, the term literally means "the ability to follow the path of a requirement."
Historical context
The concept of tracing components and decisions has its roots in large-scale manufacturing and systems engineering projects, particularly in the aerospace and defense industries of the 1960s and 1970s. In these sectors, tracking every part and decision was critical for safety and quality.
The term and its formal practice gained prominence in software engineering during the 1980s with the rise of structured development methodologies. Military and government standards, such as DoD-STD-2167A, began to mandate formal requirements traceability for defense contracts.
In the 1990s, the Requirements Traceability Matrix (RTM) became a standard artifact in many development processes. The Capability Maturity Model (CMM), and later CMMI, identified Requirements Management, including traceability, as a key process area for mature organizations.
With the advent of Agile methodologies in the 2000s, the implementation of traceability evolved. Instead of large, static matrices, traceability is often achieved by linking user stories to epics, features, and acceptance tests within modern Application Lifecycle Management (ALM) and DevOps tools. This makes the process more dynamic and integrated into the daily workflow.
Usage
In context.
For our medical device to be FDA compliant, we must demonstrate complete Requirements Traceability from patient safety needs down to the specific lines of code that implement them.
The project manager used a Requirements Traceability Matrix to ensure every user story was covered by at least one acceptance test.
Without proper Requirements Tracing, it's impossible to perform an accurate impact analysis when a stakeholder requests a change late in the development cycle.
FAQ
Common questions.
Forward traceability links requirements to the work products created to fulfill them (like design, code, and tests). It helps ensure that every requirement is implemented and answers the question, "Are we building the product right?".
Backward traceability links work products (like a feature or test case) back to their source requirements. It helps verify that the team is only building what was requested and answers the question, "Are we building the right product?".
Taxonomy
Filed under.
Categories
Tags