How do you trace requirements through architecture and tests?

Question

IT Interview Practice · Accepted Answer

Use **bidirectional traceability**: connect each important requirement to the decisions and components that satisfy it, then connect those components to acceptance evidence. The reverse links show why a component exists and which requirements a proposed change could affect.

## A small, maintained chain

```text
[Requirement R-12] --> [Decision D-04] --> [Refund workflow]
        |                                      |
        +--> [Acceptance test T-18] <-----------+
                         |
                  [Test evidence]
```

Suppose R-12 says that replaying the same refund request must not create another refund. D-04 chooses a stable business operation identifier and duplicate detection. The workflow implements that rule. T-18 repeats a request after a simulated lost response and verifies that there is still one business refund.

A traceability record includes the requirement’s owner, its current version, links to the relevant design and tests, and the evidence status. A test name alone is not proof: record the tested version, environment and result.

## Keep it useful during change

- Assign stable identifiers and link to the authoritative requirement instead of copying its text everywhere.
- Review uncovered requirements and design elements with no justified purpose.
- When a requirement changes, inspect its downstream links and mark outdated evidence for revalidation.
- Check the reverse direction too: a changed integration may affect several requirements owned by different teams.

## Trade-offs and interview signals

Start with costly, cross-team or high-risk requirements. Mapping every helper function creates maintenance work with little benefit. A lightweight table or linked work items can be sufficient; the important property is maintained relationships.

Explain who updates the links and when, such as during design review and release acceptance. A matrix that is complete on day one but ignored during implementation gives false confidence.

A small, maintained chain

Keep it useful during change

Trade-offs and interview signals

Related questions