The Whole Requirement

The Requirement, The Whole Requirement and Nothing But the Requirement

Business Analysts must take care to observe the ‘real’ requirements. What stakeholders say may not be the same as what they do.

Manoj Phatak

Manoj Phatak

An Exercise in Observation

Whilst working on a large automotive project to build an infotainment system in Germany during 1999-2000, I conducted an academic exercise in observation. I wanted to see how difficult it would be to capture the ‘real requirements’ for a hypothetical In­Car Email Dictation System.

Car and Driver

So, I fitted a video camera to the dashboard of my car and asked 3 colleagues to drive round a pre­-specified route. Their objective was to ­dictate an email to an imaginary dictation system whilst driving the car. I filmed all 3 attempts and transcripted the videos:-­

[Engine starts running]
Hi…[engage clutch][change gear] errr…I would like to send
[1 sec pause] an email [change gear][look in rear view mirror]…errr…
I would like to send an email [2 sec pause] to Mary to tell her…[brake as approach turn­off]
[down a gear]. This is an email for Mary [up a gear][accelerate] just to tell her [change gear]…errr…that I will be late home tonight [down a gear for upcoming ascent] [1 sec pause]….errr….. so
please don’t wait up [brake][down a gear], as I have a meeting running late so please don’t
wait for me [down a gear][decelerate][turn left]…….

From the transcripts, it became clear that the system would have to be very smart to make sense of the above…..garbage…!! The transcripts contained:

Pauses: do these mark the end of a phrase or sentence? Repetition: does the user mean to repeat? Words which are not really words: such as ‘errrr’, ‘ummm’ and ‘ahhh’

It was obvious that the driver was much more concerned with driving the car than dictating the email (quite normal considering his / her life depended on it).

When I showed the video to my project manager, we both decided that email dictation systems posed a challenge since the requirements were much more difficult than we had imagined.

Now, if we apply this to a project where you are looking to improve process efficiency, it would be wise to not take for granted what our business stakeholders tell us. It will always be safer to carry out pure observation (just as above) to ensure we have the right data regarding how long a process takes for example (and therefore the ‘real requirements’) before starting out on implementation.

Business Analysts must take care to observe the ‘real’ requirements. What stakeholders say may not be the same as what they do.

Another Example: UK Mortgage Application Process

Business Rule:­ A mortgage loan of a given borrower can only be secured by securities that are owned by the given borrower.

OCL Business Rule

From the above UML fragment, we see that a MortgageLoan is associated to a Property (which it views as it’s Security) and to a Borrower (which the MortgageLoan views as the Customer of the bank). The Property views the Borrower as the Owner. There are different types of MortgageLoan: namely, InterestOnly and Repayment.

The business rule above may need reading a few times to fully understand it. We realised in fact that this statement alone may not be correctly interpreted by our development team, so we decided to break it down further using OCL, the Object Constraint Language:-

The OCL statement says basically what the business rule above says, but in a less ambiguous way, which is less open to misinterpretation by the development engineers. In fact, we found that this process often unearthed problems early on, well before they reached development. Many times, we had to go back to the business to clarify specific aspects (and sometimes even they were not sure).

context MortgageLoan 
inv onlyOwnedSecurities:
security.owner­>forAll(owner | owner = customer)


It is wise to use whatever techniques we can to discover the ‘real’ requirements and business rules before embarking on development. Videoed observation is a key technique that allows us to see what is really happening in a business process. After all, the camera never lies.

Share this post

Share on twitter
Share on linkedin
Share on pinterest
Share on email

Business Analysts can Enable Innovation

Business Analysts can Enable Innovation

Business Analysts must learn to decode the wishes of customers into requirements that focus on what the solution must achieve, but in a way which allows for multiple possible implementations.

Manoj Phatak

Manoj Phatak

Horse and Cart

“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 had access to a Business Analyst at that time, he might have arrived at a better statement of the ‘real’ requirement, namely:- ​ ​

A medium of transport capable of carrying 100 kg of persons and goods a distance of 10km 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 and carriage’ that can meet those requirements.

It is this very 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 end-result, without specifying how the design or implementation is to achieve it.

Here is another example:


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 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 digital user interface design – the Apple iPod, which was one of the first digital 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 listbox, which may not be as effective 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..! ​

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 vs Requirements

So, do Business Analysts need training in how to write patent claims before being set 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 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?


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 allows for 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 small enterprises.

Share this post

Share on twitter
Share on linkedin
Share on pinterest
Share on email

It’s Traceability, Spock – Just not as we know it

It's Traceability, Spock - just not as we know it

Change happens on a project – whether we choose to manage it or not. What are you currently doing to minimise it’s negative impacts? A traceability matrix can be the answer.

Manoj Phatak

Manoj Phatak


If you change the Product Price on a line item in a Purchase Order, you expect to see the Total Price at the bottom also change, right? That is traceability!

We can achieve the same thing on projects, by mapping business needs, stakeholder benefits, product features, requirements and designs – such that if one of them changes, we can assess the downstream impact.

And since traceability is bi-directional, we can also assess which benefits, features or requirements map back to the business needs, and eliminate those that do not have a strong mapping.

Traceability Matrix

Some people claim that traceability tools are too expensive. Some cannot justify spending time on them. Some claim they are difficult to explain to business sponsors.

For small or medium sized projects, traceability can be managed with a simple spreadsheet. The question is whether we can afford not to put in place the processes, tools and people that manage change.

Change is going to happen anyway. What are you currently doing about it?

Projects need to be managed, whether or not there is a Project Manager on the team. The same is true of Traceability.

Stakeholder Benefits

Describing stakeholder benefits can be a challenge. If we fail to accurately understand what the real benefit is to our customer, it is difficult to know what to implement and whether the customer goal has been met by the end of the project.

I often find that Twitter helps on these occasions.

Can you describe each benefit (in your current project) in less than 140 characters? And get consensus across your stakeholder community?


Product Features


But what benefits are received by users of having a taller display? Or a longer battery life? Or a better camera?

The stakeholder benefits will depend on who we are talking to. Some users may see great benefit in faster connectivity or a higher-resolution camera, some may not.

It is up to the Business Analyst to ‘measure the value’ to the stakeholders of each feature and map this on a traceability matrix.

Traceability Mapping

The example traceability matrix below maps business needs, benefits and features to the requirements and design for the iPhone.

Traceability Matrix for iPhone

Can you connect the boxes together and thus show how the design maps back to the requirements?

And how requirements map back to features?

And how features map back to benefits? And finally how benefits map back to business needs?

Of course, building a solid traceability matrix cannot be done alone – you will need the help of your stakeholder community. That means business, IT, legal, marketing and son on…

If you would like to see the finished result, please contact me.


Change happens on a project – whether we choose to manage it or not.

What are you currently doing to minimise it’s negative impacts? A traceability matrix can be the answer.

If properly managed, this simple, inexpensive tool can minimise threats and identify the value to our stakeholders of key features, before starting implementation.

Share this post

Share on twitter
Share on linkedin
Share on pinterest
Share on email

Digital Business Analysis

Digital Business Analysis

The Digital Business Analyst combines market analysis, competitor analysis and keyword analysis to understand the Voice of the Customer.

Manoj Phatak

Manoj Phatak

What is Digital Business Analysis?

The Digital Business Analyst combines market analysis, competitor analysis and keyword analysis to understand the Voice of the Customer. ​

With this knowledge, we are equipped to feed market intelligence into product / service development to give customers what they need. ​

A Cry Out for Help

After all, each keyword typed in by a person somewhere in the world is a cry out for information, often at the time of maximum need. ​ It is at this crucial time that our products and services must be ranked highly enough that our prospective customers can find us. ​

Not only that. ​ Our content must be engaging enough to create real interest. Our brand must convey trust. Our team must convince. The value we provide must be tangible. ​ Not easy, right? ​ Right.

Traditional Business Analysis

But not impossible either. ​ The traditional role of a Business Analyst has often been limited to internal projects, with face-to-face interviews, workshops and surveys to understand what our internal customers often do not understand either: what they really need. ​

Cost Centre vs Profit Centre

The traditional Business Analyst department / service / team is often seen as a Cost Centre, often within IT, so often ignored by Business and seldom given the chance to explore the real business needs. ​

Enter the Digital Business Analyst, capable of deciphering the wants, needs and desires, typed in as queries into a web browser, by prospective customers, often looking desperately for an answer to a burning issue. ​

So, why can Business Analysis not be seen as a Profit Centre, rather than a Cost Centre? ​

Why can Business Analysis not be set free into the Big Bad World to explore what customers really need, be they B2B or B2C, or even C2C? (Think eBay). ​

Connecting The Dots

What if Business Analysts could connect the dots from the vast resources of global keyword databases, cutting through the noise and define the requirements of our next killer app, without having to conduct a single face-to-face interview.

After all, how could we interview the world, anyway?

I am talking about using the power of the Web to understand our Customers better. ​

I am talking about using Big Data metrics to find out what Customers want or need, and assess the market size, market demographics and market trends before developing products. ​

All the data is already there. We just need to connect the dots. ​

So, empower the traditional Business Analyst with Digital skills and set them free to explore the world.

We might just define that Next Killer App before our customers realise that our product is exactly what they were looking for all along.

Share this post

Share on twitter
Share on linkedin
Share on pinterest
Share on email