The change request landed for the third time. Same feature. "Just one small tweak," the email said, the way it always says. I remember scrolling back up the thread on a Tuesday afternoon, watching that same small change bounce through the build, through QA, through a client demo that went quietly sideways, and finally seeing what I had missed for three rounds: the thing we kept fixing had never been the broken thing. The requirement was.
That is what requirements rework feels like from the inside. Not a crash. A slow tax. You pay it in re-opened tickets, re-scoped sprints, and the quiet way a team stops believing that "done" means done, because it keeps not meaning that. After 25 years in enterprise software delivery, I have landed on an unpopular opinion: most rework is preventable, and almost none of it gets prevented in the place everyone goes looking for it.
What is requirements rework, and where does it start?
Requirements rework is work you redo because the requirement was wrong, missing, or misread, not because the code had a bug. That distinction matters more than it sounds. A code defect is a mistake in how something was built; a requirements defect is a mistake in what you decided to build in the first place, which means every hour of building, testing, and reviewing that followed was spent perfecting the wrong target.
Here is the tell. When a fix ships and the same feature comes back anyway, wearing a slightly different complaint, you are not looking at a bug. You are looking at a requirement that nobody nailed down. The code is doing exactly what it was told. What it was told was incomplete, and it was incomplete before a single line existed, back when the whole thing was still a conversation in a room.
What does requirements rework really cost?
More than almost anyone budgets for. The hard part is that rework hides. It does not arrive as a line item called "rework." It arrives disguised as normal work, a sprint that ran long, a feature that needed "polish," a release that slipped a week, so the true total stays invisible even as it quietly consumes a third of the calendar. Two numbers help drag it into the light.
That figure comes from construction, not software, and I want to be honest about that rather than dress it up. I cite it anyway for two reasons. The range holds up across an enormous, audited sample, and its own root-cause analysis points straight at the requirements side of the house: design errors, omissions, and changes requested by the owner. Swap "owner" for "product stakeholder" and "design" for "spec" and you have described a software project word for word.
Take the low end and it still stings. If a third of everything your team does is redoing work, then a third of your payroll, your calendar, and your team's patience is going to something you could have caught earlier. That is the market's own vendors telling you the ceiling on the opportunity. The question stops being whether rework is worth fighting and becomes where to fight it.
Why does rework start in discovery, not in the build?
Because discovery is where the gap gets made. A requirement is missed, misunderstood, or silently assumed, and then everything downstream is built faithfully on top of that gap. The build does not create the defect. It inherits it, scales it, and hands it to QA, which finds a symptom and files a ticket that describes the symptom, not the cause. So the team fixes the symptom. The cause is still sitting upstream, untouched, ready to produce the next ticket.
I used to think this was mostly a communication problem, a matter of writing clearer documents. I have changed my mind. Clearer documents help, but the real failure is earlier and quieter: the constraint that mattered most was never spoken at all, because everyone in the room assumed everyone else already knew it. Tacit knowledge does not travel through a spec. It travels through the one senior person who happens to be in the meeting, and only if someone thinks to ask.
Years ago I led a bilingual claims platform for a Quebec insurer, and one module kept bouncing back. Approval routing. We shipped it, a change request came in, we adjusted it, another came in. Three rounds. Everyone kept calling it a small UI tweak, and I kept treating it like one, which was my mistake.
On the fourth round I stopped coding and ran a real discovery session instead. One table, an analyst, a developer, a tester, and, for the first time, the claims supervisor who actually lived the process. Twenty minutes in, she said the thing nobody had written down: above a certain dollar amount, a claim needed a second approver, and that threshold changed by region. It had never been a requirement. It had been an assumption living in one person's head. We wrote it as a testable rule that afternoon. The change requests on that module dropped to nearly zero over the next two releases. The fix was not better code. It was a question we should have asked in week one.
Which discovery habits actually cut requirements rework?
Four habits do most of the work. None of them is clever. That is the point: reducing rework is not a breakthrough technique, it is a small set of unglamorous disciplines applied before the build, in the exact window where nobody feels any pressure to slow down and everybody pays later for not having. Here is what has worked across dozens of engagements.
Ask the unasked questions. During discovery, put two questions on the table for every feature: what must this never do, and what happens when the normal path breaks? Those two prompts drag out the constraints that live in people's heads. The senior engineer knows what must never happen. The supervisor knows the exception. Nobody volunteers it, because to them it is obvious, and obvious is exactly the category of knowledge that never makes it into a spec.
Make it concrete with a real example. Abstractions hide disagreement. Get an analyst, a developer, and a tester to walk one specific, real example of the feature together, start to finish, and the gaps show up fast, because a concrete case forces a concrete answer where a vague requirement let everyone quietly imagine something different. Three people, one example, thirty minutes. It is the highest-yield half hour in the whole process.
Write each requirement so a test could check it. "The system should handle approvals correctly" is not a requirement. It is a hope. "Claims over 10,000 dollars route to a second approver in the same region" is a requirement, because a test can pass or fail against it. If you cannot imagine the test, the requirement is not done yet. Rewrite it until you can.
Re-check the tacit rules with the people who hold them. Before the build starts, take the requirements back to the person who knows the domain in their bones, not the person who wrote the ticket, and ask what is missing. This is the step teams skip under deadline pressure, and it is the one that catches the region-specific threshold, the regulatory line, the rule everyone assumed. Five people in a room for an hour is cheaper than five sprints of rework. Every single time.
One caution, learned the hard way. Do not turn this into a heavyweight process with templates and sign-off gates, because the moment discovery feels like paperwork, people route around it and you are back to assumptions. Keep it light and conversational. The goal is not documentation. It is shared understanding, written down just enough that a test can hold it.
Can AI reduce requirements rework, or does it add to it?
Both, and which one you get depends entirely on where you aim it. Point AI at the code with a vague requirement and it does what it does best: it produces more, faster. More of the wrong thing, faster, because the model optimizes for the instruction it was handed and has no way to know about the region-specific threshold nobody wrote down. That is not a hypothetical. It is the pattern behind a lot of the 2026 hidden cost of missed requirements, and it compounds the way we described in the 29x rule: the later a requirement gap is caught, the more it costs to fix.
Now point the same capability upstream, at the requirements themselves. This is where it gets genuinely useful. ScopeMaster, an AI-based requirements analysis tool, tests specifications for gaps and ambiguity before the build and claims automated analysis can cut rework by 20 to 50% and shorten schedules by 5 to 25%. Treat vendor numbers with the skepticism vendor numbers deserve. Even discounted, the direction is the important part: AI applied to discovery attacks rework at its source, while AI applied to code without discovery just industrializes it.
This is the whole idea behind requirements intelligence. It is the systematized version of the four habits above: surface the unwritten constraints, resolve the ambiguity, and turn assumptions into testable requirements before code exists, whether a human or an agent writes that code next. We wrote about compressing that discovery work without cutting corners in how to compress the requirements phase. Speed is not the enemy of quality here. Ungoverned speed is. Give the build a complete spec, including the parts everyone assumed, and the same velocity that used to manufacture rework starts preventing it.
The shortest path to less rework
Rework is one of the largest hidden costs in software delivery, somewhere between a fifth and a half of the work, and you cannot cut it where it shows up. By the time a re-opened ticket lands, the defect is already old. It was created upstream, in discovery, in a constraint nobody wrote down.
So move the fight upstream. Ask the unasked questions, make requirements concrete with a real example, write each one so a test can check it, and re-verify the tacit rules with the people who hold them. Do that before the build, and you stop paying for the same feature three times.
What are the most common questions about reducing requirements rework?
