Business Analysts Can Enable Innovation


“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 drop­down 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 light­sensitive 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.

Business Analyst Innovation - 2


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

Like this article:
  20 members liked this article


Putcha posted on Wednesday, June 12, 2013 5:38 PM
The analogy of requirements with patent claims is an interesting and useful suggestion.

AA: A general awareness of how to draft requirement or innovative design without giving specific details or examples is a fine art in thinking and expression.

BB: This is also at play in defining meanings of words, which perhaps lexicographers formally learn. The meanings in any well developed dictionary are delightful to read and appreciate.

CC: Mere technical competency, precision and rigor are not sufficient to specify any of AA or BB---though they are necessary. Some writing skills and appreciation of taxonomies / ontologies should help. A review by professional lexicographers and UX with systematic surveys may also be necessary. I am prompted to say this seeing awful terms and definitions in some international standards.

DD: Henry Fords statement is actually very profound. It is something to reflect on----but not used as a prescription to avoid consulting customers / users. I alerts analysts and designers AGAINST relegating their duty to customers / clients / users. They have to elicit and find real needs (see Robin Goldsmith and Roger Cauvin (Austin)).

EE: Even when analysts get too specific about "means of meeting requirements" and fail to separate "real requirements", the designers must be alert to question and reformulate the requirements removing any implied solutions.

FF: In the light sensitive carpet protection example, the solution suggested works only if the viewers are rare / infrequent. Otherwise the lights will always be on since some one or the other is always viewing. Some kind of bunching of viewers and shutting off the lights after the safe exposure period would still be necessary. Whether the means should be electronic or something else. Sensing the presence of viewers also needs to be reviewed. More important is the exposure time to light.

GG: Finally, creativity and innovation are not confined to a few roles. Nor can it be expected as a rule from some professional roles. It should be nurtured and used wherever it occurs and no one should rule them out of ones work.

Only registered users may post comments.



Copyright 2006-2024 by Modern Analyst Media LLC