Tag Archives: requirements

Apr 18 2014

Quality

English: A standard measuring tape.

English: A standard measuring tape. (Photo credit: Wikipedia)

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

Related articles
Enhanced by Zemanta
Aug 18 2012

Stop polishing nose cones!

Rocket Engine, Liquid Fuel, H-1

Rocket Engine, Liquid Fuel, H-1 (Photo credit: cliff1066™)

Working on a “nice to have” feature when there are more important requirements to fulfil is a crime. It becomes a heinous crime when it happens in a resource constrained environment. And yet – I see it all the time. If you ever find yourself working on a nice to have feature – stop, and ask yourself “is this the most urgent problem that needs solving?”

We have a special term for such work which, according to my trusted sources, originated in the IBM lab’s. We call it “polishing nose cones“.

Imagine if you will, a factory building rockets. The man in charge runs a tight ship and he organises his factory into departments. The engine department takes care of the bottom of the rocket, the propellant and coolant department takes care of the mid-section of the rocket and the nose cone department takes care of the very top of the rocket.

The guys down at the business end of the rocket, the engine department, have their work cut out. They have to develop the rocket engine (or more correctly the rocket motor) which involves some tricky engineering. The engine guys have to come up with a rocket motor that will get the vessel into space without running out of fuel and without blowing the rocket into smithereens. Their work takes a long time.

The coolant and propellant guys also have a mountain to climb. They have their specifications from the engine guys and they are pretty demanding. Some how, they have to provide enough coolant to stop the engine consuming the rocket in a ball of flame, but enough fuel to make sure that the rocket can make it to orbit. Not only that, but they have to operate within strict weight criteria.

The nose cone guys have the easiest job of all. All they need to do is manufacture the pointy end. Sure they have weight constraints, but their only job is to make something aesthetically pleasing. So the nose cone guys finish long before the coolant and propellant guys and the engine guys still have a ton of work to do.

So do they go and help the other guys – no – because they are in the nose cone department. Once they have finished the essentials, they start on the “nice to haves”. They start polishing their nose cone.

If I ran the factory, I would get away from the department idea and create a resource pool. All the engineers would constantly be picking up the most important tasks on whatever part of the rocket. OK – so maybe my nose cone wouldn’t look quite as good – but I bet my rocket would be ready for launch first.

Related articles
May 30 2012

Who are they?

Clockwise from top left: Marge, Homer, Bart, S...

Clockwise from top left: Marge, Homer, Bart, Santa’s Little Helper (dog), Snowball II (cat), Lisa, and Maggie. (Photo credit: Wikipedia)

One of my favourite episodes of the Simpsons is where Homer discovers he has a long-lost brother called Herb. Of course Herb is the complete antithesis of Homer. He is successful, slim with a full head of hair. He runs a successful car (or automobile in the native American) manufacturing company called Powell Motors in Detroit. Herb is overjoyed to learn of his brother and they start to spend a lot of time together.

After a while, Herb realises that Homer is the epitomical average American guy and therefore the best person to design a car for ordinary Americans, so he lets Homer loose and gives him free rein to design the next car from Powell Automobiles. Of course, being the Simpsons, it is an unmitigated disaster. The car that Homer designs appeals to absolutely no-one and Powell Automobiles ends up going bust.

 So where did Homer go wrong. Quite simple really – he did not focus on who his customer were or what they might want. He simply kept adding features until he could think of nothing else to add. What this did was inflated the cost (because there were so many features) and reduced the appeal, because who wants something that is average at everything.

Every time we develop a product, we need to ask ourselves some basic questions. Who is going to use this product?  What are their needs?  What are they going to want to do? It’s a really good idea to define these things in an audience statement so that everyone involved in the product is left in no doubt as to the niche you are trying to fill. It’s also a good idea to express the requirements for the product in terms of use cases.

A really simple idea, a use case is almost a story that defines what the user will end up doing with the product. The benefit in doing this is that everyone can visualise exactly what the product will do. The use cases “As a racing driver I want to get around a lap in the quickest time possible” will yield a very different product to “As a commuter I want to complete long journeys comfortably without using too much fuel”.

The benefits don’t end with development of the product either. If we have the use cases, testers can immediately understand the natural paths through the system and can make sure their tests fully cover these paths (as well as looking for where the users might stray off the path. Because use cases are written in plain English, Sales & Marketing can immediately understand what the product is about and gear up their materials accordingly.

So if you want to end up with a Bugatti Veyron (and not a Homer special) – it’s a very good idea to think about who’s going to use your product.

Related articles