

“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.”





1) A man appeared after the owner had turned off his store lights.


2) The robber was a man


3) The man did not demand money.


4) The man who opened the cash register was the owner.


5) The store owner scooped up the contents of the cash register and ran away.


6) After the man, who demanded the money, scooped up the cash register he ran away.


7) While the cash register contained money the story does not say how much.


8) The robber demanded money of the owner.


9) The story concerned a series of events in which only three people are referred to: the owner of the store, a man who demanded money and a member of the police force.


10) The following events are included in the story: someone demanded money, a cash register was opened, its contents were scooped up, and a man dashed out of the store.





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


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





Case Study

Critical Incident Method

Forward Scenario Simulation

Critical Decision Method


Protocol Analysis



Role Playing

Role Playing





Rapid Prototyping






Goal Related

Goal Decomposition

Dividing the Domain

List Related

Decision Analysis

Construct Elicitation

Repertory Grid

Multi-dimensional Scaling


Card Sorting


Laddered Grid

Document Analysis

Document Analysis


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.


This entry was posted in Consulting Excellence. Bookmark the permalink.

3 Responses to A user will tell you anything you ask, but nothing more.


  2. Pingback: The perfect consultant – The Ambivert? | Infinite Shades of Grey


Leave a Reply


WordPress.com Logo


Google+ photo


Twitter picture


Facebook photo



Connecting to %s