LEARN. PRACTICE. GROW.Concept and mechanism
A requirement does not end when it receives a signature. It remains connected to its source, design options, implementation, and tests demonstrating behavior. Those relationships help assess changes. If a retention rule changes, links to tables, jobs, and procedures help identify what to review without inventing a universal retention period. Maintain attributes such as state, source, owner, and version to determine what can be reused. A requirement approved for one product or country does not automatically become valid elsewhere. Confirm constraints and authority before copying an old approval.
Guided application
In an API contract, changing complete from sent to accepted may require little code but considerable compatibility work. Assess consumers, timeouts, retries, tests, and runbooks before the decision. Priority also depends on relationships: an interface with low standalone value may unlock an essential feature. When everything is called mandatory, clarify deferral consequences, actual obligations, and capacity. A baseline records an agreement at a point in time; it enables controlled evolution with history rather than prohibiting new needs. When a requirement is withdrawn, review linked elements and update their relevant validity. Do not automatically delete every test, since some may still check other requirements.
A one-hour field edit may affect two consumers, the dashboard, and the retry procedure.
Common pitfalls
Local effort as total impact; immutable baseline; context-free reuse; verified as approved.
Related topics: Need, future state, and change strategy · Model, verify, and validate requirements
Use relationships and history to decide changes with impact awareness.
Reference: CBAP Competencies and Proficiency Levels · CBAP six-knowledge-area blueprint, May 2026 handbook