Requirements Met, Users Lost

Back when we “digitized” a paper form by copying it exactly onto a website, I worked on a project with the clearest, most testable (and most literal) requirements you could imagine. The flavor of the month at the time was “TurboTax-like,” which in this case meant a wizard with hundreds of steps full of perfectly placed textboxes and buttons. It was built in .NET 1.1 by four overqualified developers... and me.

One requirement we all saw, assumed was a typo, and promptly ignored until QA reminded us:

“Any value derived from other values must be manually entered by the user, then the system shall validate that value against the calculated result.”

The customer had simply turned the paper steps into the software requirements, and wrote them in such a way that the application would validate the work (vs just doing it for them).

On paper, the user filled box 1 and box 2, then used those to calculate box 3. Instead of letting the system compute box 3, the requirements, as written, made users do the math while the system graded their work.

When I suggested to the customer that we could let the system compute box 3 from boxes 1 and 2, they were amazed. But the requirement was locked, so the manual math stayed.

The best part? In our big user demo we learned the flow defined in the requirements had already drifted by step four, so we didn’t even get to show off our redundant textboxes. The app was harder to use than the three-inch stack of paper it was meant to replace. We delivered exactly what was asked for, and exactly what no one wanted.

From Waterfall to Agile: Same Trap, New Wrapping

Today, a lot of Agile teams work in regulated industries or sell to government customers, where requirements can be just as strange. The difference is that we are often building for active user bases who will notice and care when something feels pointless.

But bad requirements aren't always malicious. Sometimes they hide a valid intent such as data quality, compliance, or traceability, but get expressed in the most user-hostile ways possible.

As a team, your job is to extract that intent and meet it in a way that satisfies your users and still checks the compliance box (and maybe even adds a little value).

In Agile, that means:

• Engage stakeholders early to unpack the “why” behind the requirement.

• Build the user-friendly version and show how it still satisfies the compliance need.

• Map what you actually build (the one users want to use) to the requirement as written. Then make your acceptance tests prove the link.

Meeting requirements is easy. Meeting requirements without losing your users takes finesse.

If you’re in a regulated space or need to meet rigid contract requirements and would prefer to do it without having to apologize to your users after every release, give me a shout. I can help you thread that needle.