LEARN. PRACTICE. GROW.Identify exactly what changes
The sponsor changes a fictional application’s processing window. The request looks like replacing a number but can affect concurrency, batch calendars, observability and out-of-hours operations. Record the current requirement, proposal, reason, scope, intended date and decision owner. Do not immediately replace approved text with the new sentence, since that erases the reference explaining production behavior. Retain identified versions and link the proposal to the objective it aims to improve. If the change is urgent, adapt analysis to the available window without hiding unresolved questions. An approved exception should state what it covers and when it will be reviewed.
Assess freshness of relationships and approvals
In the lab R-window changes from version 1 to version 2. Relations L1, from the need, and L3, to the worker, still reference version 1 and are flagged for review. That does not mean they are wrong; it means validity for the new version has not been established. Approval identifying version 1 does not automatically approve version 2. Likewise, a test passed against the old condition may need a new expectation, another execution or merely a reasoned confirmation that it remains appropriate. Do not update only the version number to remove a warning. Retain who assessed the relationship, with which evidence and what decision they reached.
Separate impact discovery from decision
The query finds the worker and related tests. The analyst confirms with development and APS which require changes, which only need revalidation and which remain adequate with a rationale. Also ask about unrepresented dependencies: teams in another time zone, suppliers, reports and recovery procedures. Every candidate should have an explicit disposition, but need not result in new code. An impact list is neither an approved request nor a complete estimate. The recommendation combines expected benefit, cost, risk, capacity and constraints. The defined authority decides to accept, reject, defer or request more information; analysis makes that choice informed and traceable.
Prepare a coherent delivery
The API is planned for the first release and the worker for the second. If the new contract works only with both, the team must decide how to preserve compatibility, activate capability or deliver the set. A date on each plan row does not resolve the dependency. Relate requirement, component, test, activation and handover to the version to be used. Include the intermediate state: which requests are accepted, how they are handled and how a failure is recovered before the second release. Do not equate requirements approval with deployment authorization. Each decision has its own scope and evidence, although traceability helps establish that they use a coherent reference.
Close the loop without erasing history
After the change, observe agreed criteria and record deviations. If the window improves but manual interventions increase, evaluation should retain both results. The earlier version remains useful for explaining incidents, decisions and historical data; retiring it from current use does not require deleting evidence. In the exercise the baseline copy remains at version 1 while another structure represents the proposal. In actual work, the mechanism can be a requirements tool, version control or a governed repository. What matters is reconstructing the decision and identifying the applicable reference. The lab demonstrates relationship and version logic without executing a banking change, obtaining actual approval or measuring production benefit.
# Inspect staleRelationsAfterVersionChange in the lab evidence.
# Expected: L1 and L3 still cite R-window version 1.
# A previous approval is evidence about its identified version.
# Updating a version field alone is not a review.R-window v2 leaves two relationships awaiting revalidation. Version 1 approval retains historical value but does not cover the new proposal.
Common pitfalls
Updating versions without review; traceability as approval; deleting baselines; ignoring the state between releases.
Related topics: Requirements life cycle · Alternatives and potential value · Acceptance and operational handover
Preserve the reference, review relationships and distinguish recommendation, approval and change acceptance.
Reference: The Business Analysis Standard · CBAP six-knowledge-area blueprint, May 2026 handbook