Delivery Approach Guide
Knowledge Guides /How Should Requirements Baseline Changes Be Reviewed, from Attribute Differences to Affected Evidence?
Last updated: · New Horizon Digital Outsourcing Team
Requirements change reviews need more than a text comparison between documents. Compare records and key attributes using stable identifiers, then check whether related models, interfaces, tests, and reports need updates. Establish a new delivery baseline only after impact analysis and the necessary re-verification.
Agree on Scope and Compared Attributes
- Record old and new baseline identifiers and the compared modules. Distinguish added, removed, modified, and moved records. Check agreed attributes such as status, units, verification method, owner, and priority in addition to requirement text. Name-only comparisons can miss substantive changes.
- Check identifier stability to prevent a re-import from making every record appear new. For cross-tool imports, record mapping rules, unmatched items, and manual decisions. Similar wording alone is not sufficient to establish requirement equivalence.
Trace the Impact through Relationships
- Trace changed requirements to allocated functions, structures, interfaces, and verification items, identifying models and reports requiring review. Check broken links, removed elements, and version mismatches. Even an intact link needs its meaning rechecked after a change.
- Separate direct from potential impacts and assign domain owners to confirm propagation boundaries. Record unresolved analysis items when scope is uncertain; an automated trace result cannot replace engineering judgment.
Translate Changes into the Delivery Plan
- Review implementation effort, verification effort, and external dependencies. Decide which changes are accepted, deferred, or rejected. Update scope, milestones, and the acceptance matrix rather than leaving decisions only in meeting minutes.
- Retain previous verification results with their applicable baselines, then repeat tests or analyses as needed. Reuse old evidence only after confirming its conditions remain applicable. An unchanged identifier does not automatically preserve a pass status.
Create an Auditable Closure Record
- Record the decision, owner, implementation version, verification evidence, and residual risks for each change. Before releasing a baseline, check open issues and approved exceptions, then archive the difference report with models, interfaces, and documents.
- Evaluate efficiency through impact-identification time, missed updates, and re-verification duration. Separate simple editorial changes from interface or performance changes rather than comparing tasks of different complexity.