Traceability and Monitoring
Traceability and Monitoring tests whether requirements remain connected to their sources, designs, tests, and business value as the project changes. The exam expects you to establish traceability, monitor requirement status, manage changes through impact analysis, and communicate the resulting state.
Core rules
- A traceability matrix links each requirement backward to its source and forward to design, build, test, and acceptance.
- Record relationship types: derives from, satisfies, verifies, depends on, refines. Dependencies matter as much as parent links.
- Baseline approved requirements. Changes after baseline go through a change request with impact analysis on scope, schedule, cost, risk, and other requirements.
- A change control board or agreed decision authority approves, rejects, or defers changes; the BA documents the decision and updates the baseline.
- Track status: proposed, approved, implemented, verified, deferred, rejected. Status must be visible to stakeholders.
- Communicate changes to affected teams and testers, not just the sponsor.
Worked example
A regulatory change requires a new report field. The BA traces the field to the regulation clause, the data model, an ETL job, and two test cases. Impact analysis finds the field also affects a downstream reconciliation report and adds 15 days of testing. The change board approves it with a revised baseline and a deferral of a low-value enhancement. The reasoning: tracing forward exposed the hidden downstream dependency; without it, the estimate would have missed testing effort.
Traps
Building a matrix that no one maintains, tracing only forward, freezing requirements so change becomes uncontrolled, approving changes without impact analysis, and treating traceability as documentation rather than risk control.