“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 1 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.
Let’s look at another example…
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 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’
1. Requirements Define ‘Scope Of Operation’
2. Broader Patent Claims Allow Wider Protection (And Greater Value) To The Patent
2. Technology-Independent Requirements Allow Multiple Possible Implementation
3. Patent Claims Are Legally Binding
3. 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
4. Requirements Must Be ‘Sufficiently’ Detailed To Allow Implementation
Do Business Analysts need training in how to write patent claims before being set loose on requirements definition? Not at all.
However we 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?
If Business Analysts are to enable innovation, we must learn to decode the wishes of our customers into requirements that drive towards 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 how patent claims achieve this difficult balancing act.
About the Author
Manoj Phatak is Founder/CEO at Formal Objects and Senior Business Analysis instructor with Twenty Eighty Strategy Execution. Through Twenty Eighty Strategy Execution, Manoj trains Fortune500 clients across Europe, the Middle East and Latin America in product requirements modelling, UML based CASE tools and stakeholder management, with the aim of reducing project development costs and driving customer centric innovation.
Manoj is a Chartered Engineer at the UK Engineering Council and holds degrees in Electronics Engineering from Southampton University and in Software Engineering from Oxford University. Take a look at the upcoming Master’s Certificate In Business Analysis Course that Manoj will be part of.