Infrastructure · Requirements
Requirements traceability on infrastructure projects
Requirements traceability connects an obligation to its source, the design response, the evidence used to assess it, and the person who accepted that evidence. Its practical value appears when something changes: the team can find which earlier decisions need another look.
- A document link needs a revision, a precise location and an explanation of what it supports.
- Evidence received, evidence reviewed and requirement accepted are separate states.
- A changed source should trigger a review of the affected links and decisions.
Start with the governing baseline
Choose one package and one upcoming review milestone. Identify the contracts, specifications, interface documents and other approved sources that govern that scope. Record their document identifiers, revisions and approval status before extracting requirements. The newest file in a folder may not be the version authorised for the review.
Give each requirement a stable identifier. Keep its original wording and source location alongside any shorter working description. If a clause contains several independently verifiable obligations, split the working records while retaining their shared source. An unclear clause needs a clarification owner; silently rewriting it can change the obligation.
NASA’s requirements-management guidance describes tracing requirements to their sources, keeping relationships current and controlling changes. Those principles are useful background; the project’s own contract and assurance plan determine the applicable process.
Build a record another reviewer can follow
A requirements verification and traceability matrix, often called an RVTM, can start as a controlled spreadsheet. The essential question is whether another reviewer can reconstruct the basis for the status without asking the original author. Avoid a single evidence cell containing a long list of unexplained filenames.
| Record | What to capture |
|---|---|
| Obligation | Requirement ID, source clause, document revision and applicability. |
| Responsibility | Package or discipline owner and the reviewer with the relevant authority. |
| Acceptance basis | What must be demonstrated, by which method, and at which project phase. |
| Design response | Current drawing, calculation or design record with a sheet, region or section reference. |
| Verification evidence | Evidence identifier, revision, result and explanation of the link. |
| Review decision | Decision, rationale, reviewer, date, conditions and outstanding actions. |
| Change history | What changed, affected records and whether earlier acceptance needs review. |
Check what the evidence actually demonstrates
For each link, ask whether the source addresses the exact requirement, covers the right asset and revision, and is suitable for the current phase. A design drawing may support a design review. It cannot, by itself, establish what was installed or how an asset performed in a later test.
Separate a missing record from a contradictory record. Missing evidence calls for further information; a contradiction needs investigation of the competing sources. Record partial coverage explicitly, including any conditions still outstanding. This makes the next action more useful than a generic red or green status.
Review the links when the design changes
When a drawing, requirement or interface document changes, identify the records that relied on its previous revision. Then check whether the specific evidence location and rationale still hold. A new revision number does not mean every prior decision is invalid, but copying all earlier statuses forward conceals the question.
Retain the earlier decision and its source versions. Add the new review outcome, including the reason when a change has no effect on a requirement. Where the effect is uncertain, leave the review open and name the information needed to resolve it.
- Check upstream sources: has the obligation or its acceptance basis changed?
- Check downstream evidence: do the drawing, calculation and test record still describe the same configuration?
- Check interfaces: does another package rely on the changed information?
Make the next project decision easier
Prepare the review pack around exceptions: unresolved acceptance criteria, evidence gaps, inconsistent revisions, interface questions and decisions awaiting authority. Give each exception an owner and a next step tied to the project milestone. A large count of linked requirements can obscure a small number of consequential unresolved items.
If you report coverage, define the denominator and the status being counted. “Evidence received for applicable requirements” describes something different from “requirements accepted at this milestone”. Keep those measures distinct so progress reporting does not imply approval.
Use AI to prepare reviewable work
AI assistance can help organise clauses, identify candidate evidence and direct attention to inconsistencies. Require the proposed result to point back to the source and show where evidence is incomplete. Keep the reviewer’s assessment separate from the generated suggestion.
ToM Assurance Suite connects project obligations, drawing evidence, findings and reviewer decisions. Its public product walkthrough shows requirements setup and design-evidence workflows. Requirement acceptance and project release remain decisions for the people and systems with the relevant authority.
Before you close the review
- The review scope, milestone and governing source revisions are recorded.
- Each requirement has a stable ID and a traceable source location.
- Acceptance criteria and evidence needs have a responsible reviewer.
- Evidence links explain their relevance and identify the version assessed.
- Unresolved items name an owner, next action and affected decision.
- Changed sources have been checked against earlier review outcomes.
ToM Assurance Suite
Explore how project risk and decision support connects requirements, drawing evidence, interface risks and review ownership.