Geeks With Blogs
Ulterior Motive Lounge UML Comics and more from Martin L. Shoemaker (The UML Guy),
Offering UML Instruction and Consulting for your projects and teams.

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.)

Posted on Saturday, November 15, 2008 3:34 PM It's all about communication. , Requirements Patterns and Antipatterns | Back to top

Comments on this post: The Echo Effect

# re: The Echo Effect
Requesting Gravatar...
Great post! I just found your site today, and have already found several, very useful articles.

I like your notion of the echo and outline effects. A couple ways I've applied a similar pattern is by doing high level use case and/or activity diagrams or even low fidelity mock-ups at first. Sometimes a picture - rough as it may be at the beginning - is just the type of "wrong in illuminative ways" that gets us where we need to be in terms of understanding what the customer wants.. and usually it takes a few iterations before we're completely clear.

It's amazing how we can agree on the words in a spec, but still have such a different mental image of what the solution needs to be. Gotta have the diagrams and pictures.

Anyway, good stuff. I'll look forward to paging through your older material and will look forward to the new stuff as well.
Left by Jonathan Babcock on Nov 17, 2008 11:37 PM

# re: The Echo Effect
Requesting Gravatar...

I've just tooled around your site for a bit. I spent a lot of time saying YES! I fear it's possible that we'll agree so much that we'll sound like echoes; but I think it's more likely that we can learn a lot from each other.

And rough-and-quick is the way to put echoes out, I believe. Too much elaborate effort makes the customer think things are more complete than they really are, with all the attendant hassles that creates. Also, people invest emotionally when they put too much in up front, so they unwittingly badger the customer into "agreement". One thing my customers get sick of me saying is, "Now don't agree with me. Don't accept what I say. Tell me where I'm wrong." But I have to say it.

Left by Martin L. Shoemaker on Nov 17, 2008 11:52 PM

Your comment:
 (will show your gravatar)

Copyright © Martin L. Shoemaker | Powered by: