The primary conundrum in requirements analysis is simple: how can you be sure that you understand what the user said or wrote? Analysts have to master the terminology and domain of the customers. Only customers can verify that analysts have done so. This is made more difficult by many forces:

• The difficulty of learning a new domain and new terminology.
• The slippery nature of language.
• Overloaded language: you understand the words they’re using, but not the domain-specific way in which they’re using those words.
• Illusions of understanding. Misunderstandings often arise when participants only think they agree on something; and then they realize their disagreement only after a lot of time has been committed to the wrong solution.
• The customer’s hyper-familiarity: familiarity to the point where the domain is just a background, an unseen and unspoken given.
• Too much information. This can lead to lost information.
• Impatience and schedule pressure. These push people to declare understanding before it’s really reached.

The answer to these forces is The Echo Effect: ensure that analysts restate the requirements to the customers, but not in the same words the customers used. Polish up the artifacts you created as part of The Outline Effect, and present those to the customer as an Echo.

Early on, the goal is not to be right, but rather to be wrong in interesting, illuminative ways. Oh, it’s nice to feel like a genius when you do get it right the first time; but that’s rare. Much more common is that you think that you got it right, because your customer nods and doesn’t say much, when what’s really happening is that he’s too busy and just wants this meeting to be over. So being “right” in your early Echoes can lead to a false sense of security; and trying too hard to be right right away is misplaced effort and worry. Be as correct as you can manage, but recognize the limitations of your current knowledge. (See also The “Martin the Moron” Effect.)

And when users tell you that you’re wrong, get them to explain why. This will reveal hidden knowledge and assumptions, and is the real goal of The Echo Effect. When users tell you that they don’t understand your restatements, restate again in different ways.

You can also apply The Echo Effect within the team, before you take your Outline to your customer, as a way of reaching a common understanding of your requirements.

The act of translation in The Outline Effect helps you to form a concept of the requirements, and then the communication of The Echo Effect highlights misconceptions. Requirements elicitation is a loop, not a pipeline. These two effects together form the core of any good requirements analysis process.

And sometimes, they can really make you look good! After one long requirements session with me and a large number of users, we sat back and looked at the resulting UML diagrams. One user asked, “You just got here, and you’ve got a better picture than we do. How can you know all that?” And I answered, “I don’t know it. I have to go study these pictures still, so I can start to learn it. You know some of it, and she knows some, and he knows some. You all know all of it, when we put you all together, and I still don’t know hardly any of it. All I know is how to ask the questions and then draw the pictures of your answers.”

See also Joel Spolsky’s User Interface Design for Programmers. His discussion on mental models is a good argument for The Echo Effect. He explains how the end user and the developer each have a mental model of how the system works; and when those two models are closely aligned, the result is great software. But without The Echo Effect, it’s impossible to recognize when the models are misaligned. (He also argues that it’s far easier to move the developer’s model toward the end user’s than vice versa. Sorry, but that’s just the way it is.)