GROUND TRUTH · ENGINEERING CAREERS
The Cost of Changing a Requirement After Development Starts
The cost of a requirement change is not the change itself. It is everything built on top of the version being replaced.
A small-sounding requirement change can cost far more once real design and testing already depend on it.
A requirement change often arrives sounding small: "actually, this sensor needs to handle a slightly wider temperature range," "actually, the report needs one more filter option," "actually, the bracket needs to clear an extra two millimeters." Taken in isolation, each of these sounds like a minor adjustment, and it is common for someone outside the engineering team to be confused about why a small-sounding change takes so much longer, or costs so much more, than it seems like it should. The confusion usually comes from measuring the size of the requirement change instead of the size of everything that was already built assuming the old requirement was final.
Cost grows because dependencies grow, not because the requirement is inherently big
When a requirement changes before any design work has started, the cost is close to zero. Nothing yet depends on the old version, so the new version becomes the starting point. Once design work has begun, a change starts to have real cost: drawings, calculations or code already reflect the old requirement and have to be revisited. Once a prototype or a first version has been built and tested against the old requirement, the cost rises again: the tests, and possibly the prototype itself, no longer validate anything relevant, and some of that testing effort has to be repeated once the change is made. Once a product has shipped or a system is in production, changing a requirement that was baked into it can mean recalling units, patching a live system under real users, or requesting regulatory reapproval: the same underlying requirement change, but now touching everything that was built on top of the old assumption. This is why engineering teams often describe requirement changes as getting exponentially more expensive the later they arrive in a project, not because the requirement itself grew, but because the amount of already-completed work resting on the old version grew.
How a late requirement change looks vs what it touches
| What people think | What it actually is |
|---|---|
| It is a one-line change to a spec document | It is potentially a change to every design decision, calculation, test and piece of documentation that referenced the old value. |
| The engineering team is being difficult or overly cautious about a small request | The engineering team is accounting for rework across everything already built on the previous assumption, which the requester often cannot see. |
| A quick patch can absorb the change without redoing earlier work | A quick patch can hide the change's effects temporarily while leaving inconsistencies that surface later, often at a worse time. |
A concrete example makes the multiplier visible
Take a mechanical bracket originally specified to clear a neighboring component by five millimeters, and imagine that clearance requirement later changes to seven millimeters after the bracket has already been designed, analyzed for strength, and included in an assembly drawing that a supplier has started quoting. The geometry change itself might be small, moving one surface two millimeters. But the strength analysis that assumed the original geometry may need to be redone, because a shape change can alter stress concentrations in ways that are not always intuitive. The assembly drawing needs updating, and so does anything that referenced dimensions near that area. The supplier's quote, based on the old geometry, may no longer be accurate. If a prototype had already been machined, that unit may now be unusable for validation and a new one has to be made. None of these individual steps is enormous, but added together they can represent days or weeks of work triggered by a change that, described in a single sentence, sounds like it should take an afternoon.
Software has the same pattern with a different set of dependencies
A requirement change late in software development produces the same multiplying effect through a different set of dependencies: code that was written and tested against the old requirement, other code elsewhere in the system that calls or depends on that code's previous behavior, automated tests that assert the old behavior and now need to be rewritten rather than passing, and documentation or API contracts that other teams, internal or external, may already be relying on. A requirement change to how a function's output is formatted can look trivial in isolation and still require updating every caller of that function, every test that checks its output, and potentially breaking any external system that was already consuming the old format. The requirement itself did not get more complicated; the number of things now inconsistent with it did.
Why engineers push to lock requirements down early, and why that isn't stubbornness
Engineering teams place real value on clarifying and validating requirements as early as possible for a practical reason, and a request for a design review or a requirements freeze is not bureaucratic caution for its own sake. It is an attempt to catch a needed change while it still costs close to nothing to make. It is also why experienced engineers, when a late change is unavoidable, spend time mapping out everything that depends on the old requirement before starting the change, rather than editing the immediately visible piece and hoping nothing else was affected. Skipping that mapping step does not make the dependencies disappear; it just means they get discovered later, usually at a less convenient moment, often by whoever is testing or using the system rather than by the person who made the change.
Not every requirement is equally expensive to change
None of this is an argument for treating every requirement as sacred and unchangeable: some requirements are cheap to revise even late in a project, particularly ones that are relatively isolated from other decisions, like a cosmetic detail, a configurable setting, or a value that was deliberately built to be easy to adjust. The skill an experienced engineer brings is distinguishing, early, between requirements that are load-bearing, ones that many other decisions will end up depending on, and requirements that are peripheral. A load-bearing requirement, like a core structural dimension, a fundamental data model choice, or a foundational architecture decision, deserves disproportionate scrutiny before it is locked in, precisely because a late change to it triggers the widest cascade. A peripheral requirement can reasonably be left more flexible, because changing it later costs comparatively little. Treating every requirement with the same level of upfront caution wastes effort on things that never needed it; treating none of them with extra caution guarantees an expensive surprise on the ones that did.
Requirements are also relationships, not just specifications
A requirement rarely exists in isolation inside a single document. It is usually a promise made to someone else, explicitly or implicitly, and changing it can mean re-negotiating that promise, not just editing a number. A requirement specified to a supplier becomes part of a contract or purchase order that may need to be formally amended, sometimes with a cost renegotiation attached. A requirement communicated to another internal team building something that depends on it means that team's own plan and timeline are now built on an assumption that is about to change underneath them, and they need to be told before the change lands, not after they discover it broke something. This relational cost is often invisible to whoever requested the change, because from their seat, the requirement is just a line in a spec; from the seat of everyone whose work already depends on it, the requirement is a commitment that is now being withdrawn.
The earlier a change is caught, the cheaper it stays, which is the whole argument for reviews
This cost curve is the practical justification behind processes that can otherwise feel like unnecessary overhead to someone eager to start building: design reviews, requirement walkthroughs, structured stakeholder sign-off before development begins. Those steps exist specifically to catch a wrong or incomplete requirement while it still sits at the cheap end of the cost curve, before any design, code or testing has been built on top of it. A team that skips these steps to "move faster" is not avoiding the cost of requirement changes. It is deferring that cost to a later point in the project where the same change costs substantially more, and betting that no change will be needed at all. When that bet does not pay off, which is common on any project of real complexity, the team ends up paying the expensive version of a cost it could have paid cheaply earlier.
Before making a late requirement change
- List everything that was already built, tested or documented against the current version of the requirement, not just the obvious piece.
- Distinguish between updating the requirement itself and updating everything downstream that depended on the old version.
- Check whether any completed testing or validation becomes invalid, not just incomplete, once the change is made.
- If a prototype, build or release already exists reflecting the old requirement, decide explicitly whether it needs to be redone or can be patched.
- Where possible, push to identify and lock requirements early: the same change made before design work starts costs a fraction of the same change made after.
References and further reading
Background reading on the topic of this article. HireSetu is not affiliated with these organisations.