Communication in software development: requirements, prototyping, and agile methods

The comic below is an old one but highlights an important problem in the software development field: often there are significant differences between what the client needs, what they request, and what is understood and built.
Requirements

The solution, to my way of thinking, depends heavily on two factors: skilled requirement elicitation/analysis and rapid development iterations yielding client-reviewable output, ala agile.

Requirements elicitation/analysis
In nine cases out of ten, clients come to us with only partially formed ideas about what they want. They'll say, for instance, "I want a form on my website customers can fill out to apply for a line of credit." It's up to the requirements analyst to delve into their business processes to elicit the unspoken requirements. For instance, how do customers currently apply for a line of credit? If so, how is the process conducted? Should the data collected by written to a file, stored to a database, or something else? These are questions the client may not have considered themselves, or for which there may be multiple answers depending on who on the client's side is asked. As the first line of engagement between the client and development team, the more issues like these which the requirements analyst can raise and resolve, the more successful and cost effective the development effort will be.

Development yielding client-reviewable output
As a developer, few things are more frustrating than to have spent weeks working on a project only to demo it to the client and hear, "Yeah, that's what we said, but we meant was..." As humans, we aren't always capable of sufficiently manipulating abstract ideas in ways which allow us to make decisions based upon those abstractions. A lot of times, we can come up with a plan but can't predict its shortcomings until we try to implement it. That's why it is so important to get development output which the client can understand in front of them frequently and quickly. Whether that output be screen wireframes, use case stories, or working prototypes, the important thing is that the reviewing client(s) are able to look at it, understand it, and make meaningful decisions based on it. To help the client figure out what they really want, we need to take the system out of the abstract, theoretical realm and give them something they can deal with concretely.