How many times did you order in a restaurant this very nice meal, which was described on the menu as delicious, to later find out the cook went completely experimental on it? I read this incredibly great description for a main course involving the better parts of a lamb. When I got it, I noticed it wasn't actually cooked; I like my meat extremely well done, nuked to the bone. I remembered, a menu is not a meal.
How many times did you bring your car to the garage for a check up, to hear later on from the mechanic that he took special care of the noise he heard? You are going deaf, or this guy is hearing sounds that are not there, anyway you have to pay for this extra 'service'.
How many times are kids getting a dog because "I wanna doggie" is yelled by some 10 year old, so that the kid can later realize he didn't want the doggie itself, but the soft feeling of fur? You may think you want it, to find out later you had no idea what you were actually wishing for. Having the kid itself falls into this category.
How many times must a man…
Meanwhile, back in the jungle…
In the jungle of software project management the fierce full application developer is searching for requirements. After a good hunt he is dragging a bag full of statements back to his cave. There he grunts for weeks, he picks every requirement up, looks at it, smells it and takes it apart. After months, the creature sets foot for the first time outside his cave. The daylight is hitting hard on him. With him he drags a large ball made out of pieces of requirements. The pastry is the results of his craftsmanship. He shows it to the rest of the tribe. Holding it up, shining in the sun. The tribe leader looks at it, smells at it, sets fire to it. Anthropologists are still trying to figure out, if the leader communicated his disapproval or that he provided warmth to the tribe.
Expectations
The central issue here is "expectations". You imagine a certain situation in the nearby future. You close your eyes and you can actually experience it. You open them again, and try to describe what you saw to some one else. He will hear the same words, the same sentences and you might even share the same enthusiasm for it. But if you both think about "a nice woman" or "a nice man", you both having the same warm feeling doesn't guarantee you that the color of the hair of the imaginary friend is identical. It probably isn't. Communication is always influenced by interpretation of a person. Requirements in a software project are not different in this respect. An "easy to use interface" can be interpreted in hundreds of ways.
So, there is nothing you can do? Wrong. You can do a lot, but it will take some effort. You can provide feedback by using a mechanism, which is not affected by interpretation, or at least less affected. Exchanging pictures of your idea about "a nice (wo)man" can solve the hair color issue. There are several available you can use on the product requirements of a software project. And that's what this section is all about.
Good idea, bad idea
It's not only the talking with people that can cause problems. It's also your own imagination that plays tricks on you. What may seem nice in your head, me be in reality a disaster. Even if the other person understood you correctly. Feedback is also here the magic word. It can help indicate that you, or any one else, was wrong with his idea of the future at a relatively early time in the project.
Requirements validation is all about feedback. Is the interpretation of the requirements to the real life situation correct, and, are the requirements still valid? It's now "feedback time"!
Leave a Reply