“Your dad’s wasted his money.” came the solemn assessment from my uncle as he handed the package back to me.
His reaction puzzled me because dad was obviously very happy with his purchase. In the pack, there were a number of different tools; a hammer, a set of screwdrivers, a tape measure and various other tools. We were always struggling to find the right tool when we needed it and here we had a whole set in a purpose made carrying pouch. They were cheap too.
How could two people have such different reactions about the same item? It took a while before I understood that it was all down to quality. For a while, I thought that quality was an inherent feature of an item. Some items were of high quality, others were complete tat and everything else lay in between the two.
But quality is much more subtle than that. An item can be classed as a quality item if it conforms to the user’s requirements. So quality is not a feature of an item at all, it is much more related to the user and their requirements. Hence my uncle’s assessment differing from my dad’s.
My uncle was a tradesman. He used tools for a living, all day, every day. For him, two of his top requirements were durability and reliability. He needed his tools to last a long time and he needed them to work every single time.
Dad used tools occasionally when he was doing a bit of DIY around the house or when he had some flat packed furniture to assemble. His top requirements were value for money and comprehensiveness. If the tools let him down, it would not be the end of the world.
Understanding the requirements of the user is of vital importance in any project. If you don’t know what the user wants, how on Earth are you going to make sure you have met them? If the requirements are absent or incomplete, the temptation is to unconsciously use your own inbuilt requirements as a yardstick and they might be very different indeed.
This is hard enough in the world of the physical. When it comes to the ethereal world of computer systems, it is even more important to make sure that there is a set of comprehensive requirements describing what the user expects. After all, one man’s bug is another man’s feature.