Managing Changes to Requirements

When a change to an already-baselined requirement is proposed, this task runs it through the change control plan set up back in Domain II — assessing its impact, its dependencies on other requirements, and any new risk it introduces — before comparing it against the existing baseline to understand exactly what would actually change. This formal comparison is what keeps requirements changes deliberate rather than accidental drift.

Maintaining integrity means every approved change is reflected consistently across the requirement itself and every related artifact — the traceability record, any dependent requirements, supporting documentation — so nothing is left half-updated and quietly out of sync with the rest.

Study focus: a scenario where a requirement change was approved but only updated in one document, leaving the traceability matrix and a dependent requirement still showing the old version, is testing a breakdown in maintaining this integrity.