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

And as long as I’m posting UML tips to get you ready for the case study, there are two other analysis effects you should strive for. The first of these is The Outline Effect.

It’s difficult to learn a new domain. Analysts have to constantly learn new domains and requirements. They’re always learning and studying. How can they better focus on the information that they gather and draw knowledge from it? Some teams work in the same domain from project to project, but many teams tackle a new domain with every project. And even within a single domain, technology and end-user needs are constantly changing. Very few teams can coast through a project relying only on what they knew in the past.

Forces that contribute to this problem include:

• Many new facts to comprehend. The first thing you have to learn is roughly how many things there are to learn.
• Passive learning (i.e., reading and listening) is less effective than active learning.
• Too much information. This can lead to lost information.

An extremely powerful answer to these forces is The Outline Effect: require analysts to create an Outline of the problem domain and the problem. Don’t just read, Outline! Now, I use “Outline” in a general sense. They might create an actual outline; but they might also create a UML model, or they might restate the requirements in a different form from how the customer presented them. Obviously, I’m a fan of UML models as Outlines; but regardless of the specific approach, the goal is to restate and reformulate the requirements in your own words and pictures.

Research shows that active learning fixes lessons in the brain more thoroughly. Reformulating the requirements involves more of the brain than does passive review. Reading a document requires you to process words in the language centers of your brain, but not much more – and even less, when the material gets dry and you start to get drowsy. Outlining a document, on the other hand, forces you to move the material into your forebrain, so that you can think about how you want to restate what you read; and then you have to push the knowledge back through the language centers and other “creative” parts of your brain to create the restatement. Heck, even your motor centers have to be involved, since you have to write or type or draw (or even sculpt) to create the restatement.

And more brain leads to better analysis, which is the point of this blog, of course. Not only do you apply more thought to it, but you also fix it more firmly in your brain. Your memory works by association, so the Outline gives you associations to the requirements in more places in your brain. Furthermore, reading the Outline can trigger memories that help you recall what you learned as you created it.

And finally, creating the Outline requires a more careful review of the requirements sources, so less slips through the cracks. It gives you a focus, so that you know when you’ve completed that part of the analysis. And it gives you a check for completeness: if you haven’t finished the Outline, you’re not done reading!

In some cases, consider a throw-away analysis: the analysts and developers analyze the system in advance from written docs just as a way to learn the domain. Then throw it away, because it’s probably more wrong than right. This is one of my favorite tools as a consultant when I’m working with an existing development team: I want them to be primary participants in the analysis, but I also want to speak their language and pull my weight on the project. So I’ll start with an Outline (probably a UML model) just to familiarize myself with the domain; and then I’ll throw it away when I start working with the team, so that I can learn the domain as they see it.

The Outline Effect is also a necessary and useful precursor to The Echo Effect, coming up next.

Inevitably as I discuss modeling and requirements, I find myself discussing The “Martin the Moron” Effect. And that’s important enough that I wanted to revisit it here.

The “Martin the Moron” Effect is as simple as this: I want to hear “Martin, you’re a moron” on day 2 of a 200 day project; because if I don’t, then it’s almost guaranteed that on day 500, I’ll hear, “Martin, you’re a moron, and we’re not paying for this!”

Early modeling is not about being right; it’s about being wrong, but in interesting ways. It’s all about drawing models the best you can, knowing that you’ll get them wrong, because you’re counting on your stakeholders to tell you what’s wrong. These early models are about soliciting feedback from clients and others so that you can make the models better.

This is important to keep in mind. You won’t get every detail right the first time. This can be very liberating, because some people are reluctant to draw anything when they don’t know the right thing to draw. Well, draw something! Maybe it will help you think about the problem and you’ll draw something better than you expected; but most assuredly, it will give you something to take to the stakeholders for feedback.

And be very leery if they tell you the diagrams are fine the first time. That’s usually a sign that they didn’t actually read the diagrams. Sometimes it’s a sign that you bullied them into accepting your “brilliance”. Either one is a recipe for disaster. You’re not supposed to be fine or brilliant right now. You’re supposed to be a moron.