Requirement Change

Requirement Change is the modification of an individual requirement's content — its description, acceptance criteria, or scope — after it has already been recorded, refined, or in some cases already validated, distinguishing it from the addition or removal of entire items and from broader shifts in overall project scope. Because a requirement's precise wording carries specific implications for estimation, design, and testing, changing that wording after work has begun requires its own disciplined handling, ensuring the modification is deliberate, understood, and properly propagated to everything that already depends on the requirement's earlier form.

Types of Requirement Change

Clarifying Change

A clarifying change refines ambiguous or incomplete wording without altering the fundamental intent of the requirement, typically arising from questions raised during refinement or early development.

Corrective Change

A corrective change fixes an error in the requirement's original statement, such as an incorrect assumption, a technical inaccuracy, or a misrepresentation of stakeholder intent discovered through validation.

Expansive Change

An expansive change broadens the requirement's scope to cover additional conditions, use cases, or capabilities beyond what was originally specified, often triggered by newly emergent needs.

Contractive Change

A contractive change narrows the requirement's scope, removing conditions or capabilities previously included, often as a deliberate tradeoff to fit within available capacity or to simplify an overly ambitious original statement.

Timing and Its Implications

Change Before Development Begins

Modifying a requirement before any development work has started carries relatively low cost, since no implementation, test, or design effort has yet been invested in its earlier form.

Change During Active Development

Altering a requirement while it is actively being built requires careful communication with the delivery team, since work already completed may need to be revisited or discarded depending on the nature of the change.

Change After Validation

Modifying a requirement that has already passed scope validation is the most disruptive case, since it implies the previously accepted increment may no longer satisfy the requirement in its new form, potentially requiring rework of already-delivered functionality.

Managing Requirement Change Responsibly

Documenting the Change and Its Rationale

Recording what changed, why, and who approved it preserves a clear history, allowing anyone reviewing the requirement later to understand its evolution rather than seeing only its final, current form.

Assessing Downstream Impact Before Applying

Before finalizing a change, particularly one affecting a requirement already in progress, the team assesses what design decisions, code, or tests were based on the earlier version and what will need to be revisited.

Versioning Significant Changes

For requirements subject to substantial revision, maintaining a version history allows the team to distinguish between the requirement's current form and its earlier states, supporting clearer traceability.

Re-Validating After Substantial Change

A requirement that has changed significantly in intent, rather than merely in clarity, is typically re-validated with stakeholders to confirm the new version still accurately reflects genuine need.

Visualizing a Requirement's Change History

Each version in the sequence preserves the history of how the requirement's content evolved, with the nature of each change explicitly noted rather than left to be inferred later.

Common Pitfalls

Silent Overwriting

Modifying a requirement's text directly without recording what changed or why erases valuable history and can confuse anyone who had already reviewed or begun work against the earlier version.

Underestimating the Cost of Late Change

Treating a change to an already-validated requirement as trivial, without properly assessing the rework it implies for already-delivered work, risks introducing defects or inconsistency into the delivered product.

Failing to Communicate Change Promptly

Delaying communication of a requirement change to the delivery team can result in continued work against an outdated version, wasting effort that must later be redone.

Benefits of Disciplined Requirement Change Management

Reduced Rework

Promptly communicating and properly assessing the impact of changes minimizes wasted effort building against a requirement version that is no longer current.

Preserved Historical Understanding

Maintaining a record of how and why a requirement changed over time helps future readers understand its current form in context, rather than treating it as if it had always existed unchanged.

Greater Confidence in Delivered Accuracy

Careful handling of requirement change, including re-validation when warranted, increases confidence that what is ultimately delivered reflects the requirement's true, current, and correctly understood form.