“I know that you believe that you understand what you think I said, but I am not sure you realize that what you heard is not what I meant.” says a user after reading a Use case “representing” his requirements.

The fine art of knowledge elicitation.  Despite massive advances in technology, the ability to develop applications at light-speed, an original challenge remains from the day the first piece of code was written to today. It’s getting the user to tell you the requirements they want. Actually no,  here’s a news flash. They don’t know their real requirements most of the time. The times they do, they are incapable of expressing it to you in a form that ensures that both of you understand it correctly.

That’s why today’s requirements gathering is a foolhardy exercise. What we really need is much more refined. Knowledge Elicitation.

Try this quick exercise.

Read the following story and then indicate for the 10 statements in the grid if they are true, false or you are uncertain.

“A business man had just turned off the lights in the shop when a man appeared and demanded money. The owner opened a cash register. The contents of the cash register were scooped up and then man sped away. A member of the police force was promptly notified.”

Now count the number of “TRUE”, “FALSE” and “Uncertain” answers.  Without telling anyone your count, have a friend, colleague or co-worker repeat exactly the same exercise.  Your counts will NOT agree.

If you tried this exercise with a dozen people, the odds that any 2 people would have the identical answers are not good. (great answer from a guy from a University of Waterloo Math program eh?)

However my point is this. The story above has logical gaps in it. The human mind is an amazing thing. It doesn’t like logical gaps and simply fills in the gaps with things it thinks is reasonable. The result is based on context and what the reader thinks is reasonable. Each person interprets the story very differently.

Hence why “requirements gathering” with the usual techniques is pretty much futile.

Knowledge Elicitation on the other hand can be quite useful. http://mentalmodels.mitre.org/cog_eng/ce_references_I.htm#knowledge_elicitation

Definition:

Knowledge elicitation is the formal process of capturing and codifying knowledge required to perform tasks with rules.

It is not “Tell me what you want it to do”

Some Techniques

In short, show me, teach me, prove to me how it works and then I’ll prototype it, show you, observe you and then we’ll get someone else to use it and then make sure it meets the goals. So the next time someone hands you a use case, think about the “crime” story above. What are the odds that the user correctly specified all of the pre- and post- conditions for each of the scenarios. … zero% I would say.  As a profession we need to raise the bar on “requirements gathering”. Let’s think about applying more rigor and check points to requirements. It’s not the documents that are bad (Use Cases etc.), it is the processes by which we create them and their ilk that need more checks and balances. The biggest error we make is assuming the user is telling us correctly what they need. Usually they are telling us what they think they need. It may often be different.