‘If I had asked my clients what they wanted, they probably would have said a faster horse.’ Henry Ford, Founder of the Ford Motor Company This alleged Henry Ford quote is often mistakenly used to reason that we do not need to talk to our customers, because they do not really know what they want.
This thinking is essentially flawed. If Henry Ford had hired a business analyst, he might have arrived at a better statement of the ‘real’ requirement, namely: ‘A medium of transport capable of carrying 100kg of persons and goods a distance of 50 km within one hour, without stopping for food.’
Now, if you were to give such a requirement to your late 19th century engineering department, they would need to invent the new concept of a ‘horseless carriage’. This is the very basis of innovation. The business analyst can foster innovation by defining the requirements in an abstract way to focus on the end-result, without specifying how the implementation is to achieve it.
Another example
- Bad requirement - A drop-down listbox capable of showing a potentially infinite list of media items and allowing retrieval of a media item within x seconds;
- Good requirement - A search mechanism capable of showing a potentially infinite list of media items and allowing retrieval of a media item within x seconds.
The bad requirement specifies how to implement the idea, whereas the good requirement abstracts away from the implementation details to focus on what we are trying to achieve, namely ‘to search’. If we take the ‘good requirement’ to our solution provider, they will be obliged to find a mechanism that can search effectively through an ‘infinite’ list of media items.
Given some thought, they may come up the idea of an innovative new circular search mechanism, rather than a dropdown listbox. You may recognise this as one of the most profitable digital consumer electronics products of recent times - the Apple iPod.
On the other hand, if we had given the ‘bad requirement’ to our solution provider, we might have stifled any attempts at innovation because the engineers would have been forced to work with a drop-down list-box, which may not be as eff ective at allowing rapid search within a very large group of items. Instead of an innovative product, we would have ended up with a real turkey of a product.
Still not convinced?
Then consider this court case between Apple Computers and Microsoft. In May 2002, John Platt at Microsoft Research fi led a patent to ‘generate playlists for a library of media items via selecting a plurality of seed items, at least one of which is an undesirable seed item.’
Platt’s patent was submitted seven months after the unveiling of Apple’s iPod, but five months before Apple’s application for a patent covering the iPod’s rotational wheel to select media items. Net result: Apple1 lost this particular court case and their patent2 application was rejected, because the wording of the Microsoft patent application already covered the implementation of the iPod.
Comparing patent claims to requirements
So, even if you are convinced that writing requirements in an abstract way can facilitate innovation, how far should we go? Well, patent claims take an approach which is somewhat similar to writing requirements (although the end-result is protection of intellectual property, rather than solution development).
Let’s look at some similarities: Patents...
- Define the scope of the invention
- Breadth and abstraction allow wider protection and greater value to the patent
- Are legally binding
- Must be sufficiently detailed to allow another person versed in the art to recreate the invention
Requirements...
- Define the scope of operation
- Breadth and abstraction allow multiple possible implementations
- Can be legally binding if annexed to a supplier contract
- Must be sufficiently detailed to allow implementation.
Both patents and requirements should aim for as broad a definition as possible to allow all possible implementations to be covered. So, do business analysts need years of training as patent attorneys do, before being allowed to define requirements? Not at all.
However, I do believe that business analysts can learn from how patent attorneys build abstract and legally binding descriptions of products as patent claims in order to enforce breadth (and therefore value) to the patent. If only business analysts could write requirements in the same way. After all, when is the last time you saw a requirements document that would stand up in a court of law?
Innovation in the art sector
Several years ago, I noticed an exquisite display of a persian 16th century silk and wool-pile rug at the Victoria & Albert museum in London. This artefact is called the Ardabil carpet and is so light-sensitive that the museum illuminates the object for only 10 minutes every half-hour. People forms queues to see this object, just because of the heightened expectation when the lights are switched on.
I realised this could be an industry-wide problem that could be solved more efficiently, so I built some prototypes and showed them to museums across Europe. What came out of those interviews was the following requirement: a method to protect sensitive works of art by balancing the exhibition of the object (and thus its exposure to light) with its conservation.
Now, here is one solution: The simple cardboard box! Don’t laugh: some institutions actually use this technique as a low-cost solution to reduce light exposure on some of the world’s oldest and most sensitive manuscripts, books and textiles.
However, we were sure that a vitrine constructed from electro-optic glass and using a sensor-driven solution could reduce light levels more optimally, as a function of the sensitivity of the materials present on the object. Since 2009 that is exactly what my company (ArtRatio) has been doing. Several years later, we have now installed electro-optic glass vitrines to protect original maps of the 1815 Battle of Waterloo and a priceless 1888 original Torres Spanish guitar, for collectors and museums across Europe.
This innovation came as a direct result of conversations with prospective customers, but they did need to see a prototype first to confirm or refute our assumptions, and to clarify the real requirements.
Enabling innovation
If business analysts are to enable innovation, we must learn to decode the wishes of our customers into abstract requirements that focus on what the solution must achieve, but in a way which leaves open multiple possible implementations. This opens up the design space to ideas which may not have existed previously and hence fosters innovation, both within the multinational as well as for start-ups.
Manoj is a Chartered Engineer at the UK Engineering Council, a Chartered IT Practitioner at BCS and holds a Bachelor’s degree in Electronics Engineering from Southampton University and a Masters in Software Engineering from Oxford University. Manoj is also founder and CEO of ArtRatio, a boutique manufacturer of art conservation vitrines for museums, galleries and private collectors.
