Everybody Lies

The Dr. House approach to requirements analysis

This posting was first published on the Intergen Blog Site on the 26th September.

Gregory House M.D. is a maverick medical genius who, in each TV episode, heads a team of diagnosticians in their attempts to diagnose an unfortunate patient’s mystery illness. House’s signature phrase is “Everybody lies” although, for his character, it’s more than just a saying, it’s a philosophy. In this article, I’ll demonstrate how the “everybody lies” approach can be applied to requirements analysis in order to reduce costs and improve overall project quality.

It seems odd to claim that everybody lies. Just as there’s no good reason for a patient to lie to a physician who is trying to save their life, we don’t expect a business person to lie when we’re gathering requirements. The modern-day philosopher, Homer Simpson, has this to say on the subject of lying: “Marge, it takes two to lie. One to lie and one to listen.” Homer’s insight helps us understand the fundamental problem: the users must tell us the truth but as analysts we are equally responsible for finding it.

Before I try to convince you of my rather tongue-in-cheek methodology, you should first understand that getting requirements right is a serious business. Research from Barry Boehm and Philip Papaccio has shown that defects introduced early in a project, such as in the requirements analysis phase, can cost 50 to 200 times more to fix later in the project than if they had been corrected close to the point at which they were introduced. 50 to 200 times – that’s a staggering difference!

Gathering requirements means capturing business problems, not computer problems. You don’t need to be Sherlock Holmes (or Gregory House for that matter) to understand that the first step in solving a problem is to clearly identify what the actual problem is. Building a solution based on the wrong requirements can be a costly mistake to make, but how exactly can we apply our new “everyone lies” approach to requirements analysis and avoid getting it wrong? One approach could be to shout “liar” every time a user describes a requirement, but some may find this a little disturbing. First we need to understand the nature of the lies and how to avoid them.

The first problem I have discovered is that people like to describe solutions and not requirements. If I had a signature phrase for requirements analysis it would be, “That’s not a requirement, it’s a solution!” I’ll admit it’s not as catchy as “everybody lies” but the sentiment’s the same.

A requirement is the answer to a “what” type of question and should always be expressed in business terms. A solution is more of an answer to a “how” type question. There’s an easy way to tell the difference between requirements and solutions: if you can implement it, it’s a solution.

Writing down a solution instead of a requirement happens frequently, but most of the time we get away with it because it just so happens that the solution we’ve written is correct. No harm, no foul; but what happens when the solution isn’t correct? Remember that equation we had before? 50 to 200 times more expensive to fix. That’s why we get the requirements signed off to make sure they’re correct, because no-one would sign off on requirements when they’re not correct. Or would they?

Having a signed off requirements document means nothing if the requirements are wrong – we’re still going to need to fix the defects and our goal is to reduce the project costs, not just our costs. Let’s assume that no one would sign off requirements that they know to be wrong, so it must be that they’re not understood, but this raises a new mystery: why do people agree to requirements when they don’t understand them?

The problem starts when we use the wrong language to describe requirements. If we’re not using business terms, we’re putting the business users at a disadvantage. It can typically go one of two ways: either the business user says, “Hey I’m sorry but I don’t understand this requirement so I can’t agree to it”, or they say, “I don’t understand this requirement but the consultant seems pretty confident that he’s right, so I’ll just keep quiet. If it’s wrong someone else will pick it up later on.”

So the next time you find yourself writing a requirements document, remember that you’re a detective and not a secretary. It’s your job to find the real problems in business terms and not simply record what you’re told. When people tell you that the captured requirements are correct, ask them to explain them to you, just to check they’re not lying.

In my next post, I’ll explore the “Tourette’s Syndrome” approach to handling support calls.