Traceability and Monitoring
Keeping requirements connected and current
Traceability is the ability to follow a requirement's life in both directions: backward to the business need, objective, and source stakeholder that justify it; forward to design, build, test cases, and delivered functionality. Know the traceability matrix and its relationship types - derive, satisfy, verify, depend on, relate to - plus requirement attributes: ID, source, owner, priority, status, version, rationale, acceptance criteria, complexity, stability.
Monitoring covers baselines, configuration management and version control, lifecycle states (proposed, approved, in progress, implemented, deferred, rejected, retired), coverage analysis to expose orphan requirements and untested scope, dependencies, status reporting, and scope creep detection.
Change control is the flow to memorize: receive and log the request, assess impact (cost, schedule, risk, affected requirements, design, tests, other stakeholders), decide at the appropriate authority or change control board, approve/reject/defer, implement and update all artifacts, re-baseline, and communicate.
Traps. Treating a baseline as "frozen." Approving change without forward and backward impact analysis. Using the traceability matrix as a filing cabinet instead of an analytical tool. Forgetting to trace non-functional and transition requirements.
Rule of thumb: when a change arrives, ask three questions - which business objective does this touch, which downstream artifacts break, and who else is affected?
Worked example: a change to the loan approval threshold traces backward to the "reduce cycle time" objective and forward to three use cases, two business rules, and seven test cases; the impact statement lists these plus a two-week schedule effect before the board votes.