What Users Really Want Versus What Gets Delivered

I find requirements the hard part of software development because communication is so hard; much harder than it seems it should be.

What the user really wants.
What the user thinks they want.
What the user asks for.
How I interpret what the user asks for (filling in details with my knowledge of the context.)
What I conceptualize that meets my interpretation of what the user wants.
- Mapping my understanding of the requirements to an abstract solution that I think will meet the requirements.
What I deliver

In a perfect world “what I deliver” equals “what the user really wants”. In the real world what I deliver is close to what I think was requested.

Language and Understanding

Sometimes a word or statement means different things to different people.
Sometimes people don’t say what they mean, using the wrong word or combination of words.
Sometimes people mishear or misinterpret what someone else says.

I worked on a project where my interpretation of the ask was for an international site and a domestic site, and I’m pretty sure it was discussed as the international site should do this and the domestic should do that. We had two different domains. Within a month of the go live date during a demo talking about redirecting users from the domestic site to the international based on registratoin country I was told there should be only one site that shows users different content for domestic versus international based on the registration information.

Details

Software is effectively unconstrained with respect to options. Because of this a lot of detail is required to produce it.