“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 infamous Henry Ford quote is often mistakenly used to justify that we do not need to talk to our customers, because they do not know what they want or because they do not know what is best for them. This thinking is essentially flawed.
If Henry Ford had contracted out a business analyst, he might have arrived at a better statement of the 'real' requirement, namely: a medium of transport capable of carrying 200kg of persons and goods a distance of 50km within one hour, without stopping for ‘food’.
Now, if you give such a statement to your engineering department, they will need to think outside of the box to reinvent the concept of a horse that can meet those requirements. It is this thought process that may force them to create the concept of a ‘mechanical horse’. This is the basis of innovation.
The business analyst contributes to innovation by defining the requirements in an abstract way that focuses on the desired end-result, without specifying how the design or implementation is to achieve it.
Good and Bad Requirements
Bad: A dropdown list box capable of showing a potentially infinite list of media items and allowing retrieval of a media item within x seconds
Good: 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 to focus on what we are trying to achieve, namely ‘to search’. Now, once again, if we take the good requirement to our IT department, 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 with the idea of a circle. It is possible that this was the basis of creating what we know today as one of the most revolutionary changes in user interface design—the Apple iPod, which was one of the first products to introduce the concept of scrolling using a circular search mechanism.
On the other hand, if we had given the bad requirement to our IT department, we would have stifled any attempts at innovation because the engineers would have been forced to work with a drop down list box, which is not as effective at allowing rapid search within a group of very large items.
Instead of an innovative product, we would have ended up with a real turkey of a product!
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? 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:
1. Patent claims define ‘scope of protection’. Requirements define ‘scope of operation’
2. Broader patent claims allow wider protection (and greater value) to the patent. Technology-independent requirements allow multiple possible implementations
3. Patent claims are legally binding. Requirements are legally binding (in a contract between client/supplier).
4. Patent claims must be ‘sufficiently’ detailed to allow anyone versed in the art to re-create the solution. Requirements must be ‘sufficiently’ detailed to allow implementation.
Do business analysts need training in how to write patent claims before being let loose on requirements definition? 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 allow breadth (and therefore value) to the patent. If only we could learn to 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 Fine Art Sector
The Ardabil carpet at the Victoria & Albert Museum in London is arguably the oldest carpet in the world. It measures 10m x 5m and is extremely light sensitive. So much so, that the museum constructed a glass display case around it which illuminates the work of art for only 10 minutes every half hour. I personally have seen queues forming in anticipation of the next 'showing'. This got me thinking about other possible ways to achieve the same result, so I tried to formulate an appropriate statement of the 'real' requirement:
A localized protection for works of art, allowing viewing of the object (and thus exposure to light) only when a museum visitor is present; otherwise the object is protected from light damage.
Here is one solution:
Don't laugh some museums actually need to take this approach, covering lightsensitive works of art with a simple cloth or housing them in drawers that must be closed by the public after viewing.
However, I took a different approach by constructing a display case made of electronically switchable glass, such that the display case becomes transparent only when someone is present to view the work of art; otherwise it becomes opaque, thereby protecting the art piece from light damage. This display case is tuned to the specific needs of the work of art and can also allow museums to comply with compliance requirements from the green building sector regarding the management of light in buildings.
Conclusion
If business analysts are to enable innovation, we must learn to decode the wishes of our customers into requirements that drive toward what the solution must achieve, without specifying how to achieve it. We can do this by formulating our requirements in abstract, technology-neutral descriptions, learning from patent claims how to achieve this difficult balancing act.
Author: Manoj Phatak is the found and director of product development at Domoticware S.L.U. (Spain) and Senior Business Analysis instructor with ESI International. Through ESI International, Manoj trains Fortune 500 clients across Europe, the Middle East and Latin America in product requirements modeling, UML based CASE tools and stakeholder management, with the aim of reducing project development costs and driving customer centric innovation. Manoj has developed software intensive technologies for the semiconductor, telecommunications, automotive, e-government and financial sectors since 1990. He is a Chartered Engineer at the UK Engineering Council, a member of the International Institute of Business Analysis (IIBA) and Chartered IT Practitioner at the BCS. Manoj holds degrees in Electronics Engineering from Southampton University and in Software Engineering from Oxford University. Visit http://www.esi-intl.co.uk/