Lets not blame the customer - Human limitations wrt software systems

As the title of the article says, "Let us not blame the customer", I will be discussing some very inherent human limitations when it comes to dealing with complex software systems.

One of the fundamental problems highlighted across most of the companies is

"Hemant what do we do when our customer himself doesn't know what he wants or what his requirements are?"

I feel most of us in the software industry face this problem every day, wherein we blame the customers for not giving the requirements completely and correctly, and for changing his requirements frequently.

Friends, is it not surprising to see that the customer who knows his business very well, struggles to describe what he wants or struggles to give his requirements.

It is difficult to understand the fact that how is it possible for the customer to not know about his system or his requirements, although he might we working in company for past many years and would know his company and its processes very well.

Is it that he doesn't know about his business?


Is it that he doesn't want to give you his requirements deliberately???

Both of the above questions are not true. Let us understand that the customer knows his business very well because either he is the founder of his business or he might be working with that business for quite some time to know about the same.

But just because the customer knows his business well does not mean that he will also be able to describe the same completely and correctly at a particular point of time. I will show you a case later in this article wherein the customer knows his business well, even though he will struggle to describe it (if asked to do?) This is a general limitation of any human being and hence each one of us will struggle to describe our systems even if we know the systems well.

So let us understand that it is not that your customer is deliberately trying to give you incomplete or incorrect requirements, it is just because of some human limitations, he is not capable of doing it.

Second ask yourself, why the customer would deliberately not give the requirements completely and correctly, when he knows well that he is the one who will have to pay for these mistakes committed.

To understand this problem let us enact this case:

Let say Mr. A is a senior program manager of a company (of the scale of Infosys, Wipro or TCS), working in the company for many years and knows the company and its processes very well.

Let us say that the company now needs an ERP system to be developed and wants me (A representative of the Software Service Provider) to develop the same for his company.

Mr. A is sitting in one of the cabins of one of the buildings in Bangalore and invites me to his cabin for gathering the structural and behavioral requirements of the company.

The question that I want you to think is:

"While sitting in Mr. A's cabin in one of the buildings in Bangalore and while giving me the structural and behavioral requirements about the company, can you think as to what are the requirements that Mr. A can give to me completely and correctly without making a mistake."

"Without making a mistake" and "completely and correctly" are very important statements because this is the very reason, we blame the customer for. When I say "completely" and "correctly", I mean to a certain extent. I know capturing requirements which are 100% complete and correct is an ideal situation which is not possible

According to me while sitting in Mr A's cabin in one of the buildings and while giving me the structural and behavioral requirements about the company, the only requirements that Mr A can give completely and correctly is something that Mr A can see in the current frame of vision. While for anything which exists within the system but is not visible in the current frame of vision, Mr A will have to depend on his memory to describe the same and the moment Mr A depends on his memory, there is no guarantee that whatever Mr A is saying is complete or correct as memory can be of multiple types viz long term memory and short term memory dependent on Mr A's area of interest.

Now ask your self is a company of the scale of Wipro, Infosys etc small enough to visualize in a single frame of vision. I hope the answer would be NO.

Let us understand it is not that Mr A as a customer doesn't want to give his requirements, it is just that we as human beings are limited due to the problem of single frame of vision and the systems that we are dealing with, are complex enough to be visualized in a single frame of vision.

Today the systems are huge and spread about multiple geographies and hence they cannot be visualized in a single frame of vision .

This problem can also be understood using the following example:

Lets say that we are supposed to gather the requirements for implementing a Supply Chain Planning solution for a company S which is an Oil and Gas major. Lets say this company is structurally made up of 300 oil wells, 80 refineries, 200 ships, 5 primary distribution centers each having 20-0 secondary distribution centers etc.

Now while we are gathering requirements we interact with a Foreman at the Oil well and gather requirements wrt that oil well. The foreman can only correctly and completely describe those aspects of the Oil Well which the foreman can currently see or visualize, but it will be difficult for the Foreman to describe as to how is the oil well related to other aspects of the system. This is true with all of us. We can only describe those aspects which can be visualized completely and correctly, anything which we cannot visualize we depend on our memory to describe the same, which might not be complete or correct.

I have personally witnessed a 200+ million dollar project failing primarily because of this problem of single frame of vision.

This issue of single frame of vision can also create problems while understanding the system requirements documented in the form of SRS documents.

There can be hundreds of pages in a requirements document describing the requirements of a complex system.

While a reader is reading the 150th page of the document, how can he understand the how the information on the 150th page related to the information on the 2nd page or the 180th page or the 250th page.

While the reader is reading a particular page of a document, he can only visualize the details of a particular page and can understand the same, but since the related information on other pages is not visible, he cannot understand the same and he starts banking on the memory or experience which might be incorrect or incomplete.

This is because while a reader is reading the document, his frame of vision is a page of a document.

Hence for systems to be understood correctly and completely, it is very important that the person should be capable of visualizing the entire system (if not entire the system atleast maximum possible system) in a single frame or vision.

As we know software systems are automation systems that are meant to automate the complexities of the real world systems by using the processing, storage and transmission hardware devices available today so as to deliver the behaviors which were previously not possible manually due to limitations of human beings.

The fact that a customer needs a software system points to the fact that we are dealing with a complex business system because if the customers business system was not complex, then there was no need of a software system in the first place. You can find out more about software systems from the article "Software systems automating the real world".

Study center topic "Understanding the root cause of complexity" also tells us that the root cause of complexity in most of the system lies in the structural model of the system.

Study Center - Topic also tells us that "Structural understanding of the system is a pre-requisite, before we can understand the various behaviors of any system".

In the Study Center - Topic "Technical and Non Technical Systems", we have also learnt that visualization of structure of a system is a pre requisite to understand the different behaviors offered by the system.

In a nutshell visualization of structure of a system in a single frame of vision is a prerequisite for any one to understand the complexity of the system in the right way.

How can this problem be solved?

  • By knowing about this human limitations and accepting the fact that systems are very complex as compared to general human capabilities.
  • By developing or using technical gadgets or systems which can allow us to visualize any system of any complexity from different perspectives at different levels of granularity in a single frame of vision.
  • By using best practices of modeling systems.

The human limitation that I am discussing next is closely dependent on the limitation of single frame of vision.

Human Limitation 2 - Inability of a human brain to comprehend numerous combinations of logical scenarios that can exist in software system.

To exemplify this problem , let me pose a question which I have asked to numerous software engineers and analyst in the software industry.

"How many logical scenarios need to be considered and evaluated by an analyst before which he can say that he has completely understood and captured the requirements wrt the reserving a ticket functionality for a railway reservation system for Indian Railways."

Let me ask you to guess among the following answers:

0 - 20 scenarios
20 - 30 scenarios
30 - 100 scenarios
100 - 300 scenarios
300 - 500 scenarios
500+ scenarios

This question is very interesting in itself because if I ask the same question to a software engineer or an analyst .. their response will be around 20 - 30 scenarios.

The reason majority of the respondents talked about 20-50 scenarios is because it is found that a human being generally doesn't have the capability of thinking about more than 20-30 scenarios and because of which you can see that your customer may not give more than 20-30 scenarios and your engineer will not codify more than 20-30 scenarios.

If you ask the same question to a laymen he cannot think about more than 20-30 flows because it is found that humans in general cannot think about more than 20-30 flows.

But in reality the number of flows in this functionality could be around 500- 700 flows.

Let us technically understand as to how we can find out the number of possible scenarios that are needed to be evaluated for a particular functionality.

The mathematical rule says -

The number of logical scenarios that need to be evaluated in a functionality is directly proportional to the combinations of different types of domain entities which are manipulated in the functionality.

For example... Reserving a ticket functionality:

A specific type of user reserves a specific type of ticket, for a specific type of passenger, for a specific type of train, for a specific type of coach, for a specific type of seat, using a specific type of payment mode, by a specific type of customer, for a specific quota between specific types of stations.

The 14 domain entities that are manipulated in this functionality are:
User, Passenger, Customer, Ticket, Train, Coach, Seat, Payment Mode, Station, Quota, Fare, Concession, Route, Meals etc.

We also know that each of these domain entities have multiple types. Lets say on an average each of these domain entities have 3 types each.

Refer to "Best practices of structural modeling using class diagrams".

As each of the domain entities can have 3-types, the business logic for reservation can differ for every other different combination of domain entities that are supposed to be manipulated in this functionality.

So for 14 domain entities each with 3 types... there can be 1000+ combinations that are possible.

Even if we discard 50% of the same, still we have at least 500 flows for which we will have different business logic.

Even if we know this rule of finding the number of flows of a functionality, if we start writing the same manually, we might take inordinate amount of time to write it down and that also we might not be sure as to whether we have captured all the possible combinations.

Hence the task of finding out all the possible logical scenarios that need to be considered is not possible manually because of the sheer number of combination of different types of domain entities with different business logic each.

This is the second limitation faced by a human being wherein the human brain is not capable of thinking about the numerous logical conditions. This is the reason, the customer will not be able to tell you anything more than 20-30 scenarios although he might be aware of other scenarios as well.

In the next section, Using these human limitations, I will try to technically explain the reasons for estimations going hay wire in the software industry by a factor more than 100 %.

As we now have inferred that a human beings cannot think more than 20-30 scenarios or flows, let me try to describe a practical case in software development industry wherein there are multiple stakeholders all doing their work efficiently but manually. As all of the stakeholders are doing the job efficiently ... no one can be blamed for this.

Let say for a behavior like Reserving a ticket for a railway reservation system,

  • The customer thinks about 20-30 logical scenarios and gives the associated business logic to the analyst.
  • The analyst doing his job efficiently thinks bout 20 more logical scenarios that could be present and captures the business logic from the customer and formulates his requirement document.
  • The requirements captured and documented by the analyst then goes to the project manager for estimation who also using all his experience puts a 50% buffer while estimating ie he will now estimate for 60 scenarios.
  • Then it goes to the software engineer or the developer who is also doing his job the right way, he thinks about 20 more scenarios which was not thought by the customer and the analyst and he programs the 60 scenarios during his development.
  • Post development, local testing team who is supposed to test this behavior thinks about 20 more scenarios that were not caught by the previous stakeholders and ensures their development, and hence after this phase the functionality will take care of 80 scenarios.
  • Post local testing, the functionality goes to the production testing team which lets say adds 20 more scenarios to it and finally the functionality gets deployed on the production systems.
  • It means while the functionality was rolled out on the production system only 100 logical scenarios were taken into account while we know in reality more than 500 scenarios were possible.
  • Once the functionality is in production from this point of time all the logical scenarios which existed but were not taken into account (500-100= 400 scenarios) will keep coming as change requests for the next 6-7 years.

Our work in this area shows that when people talk about the problem of customer requirements changes, these changes mostly are the missing logical scenarios that were not considered and taken care of rather than the requirements changes because of customers business changing.

I am sure your quality team might have given you this statistics about the cost of solving a defect in the production stage as compared to requirements stage.

The industry statistics is the cost of solving a defect in the production stage is at least 100 times (some metric say it is around 400 times) more than the cost of solving the defect in the requirements gathering stage.

So let us now multiply the difference in the number of flows ie 500-100 with a factor of atleast 100 and this is what the customer will have to pay for this problem.

This example will technically explain why estimations in software industry goes haywire by more than 100 % or why 70% of the software projects are a failure or why US industry looses more than 30 billion USDs only because of defects in the requirements gathering stage.

Think about it project manager only estimated for 60 scenarios but in reality there were more than 500 scenarios and the multiplication of this number by a factor of 100 makes this number unimaginable.

The beauty of this problem is there is no one to blame. Every stakeholder was doing their job the right way.

The only thing that can be concretely blamed is the limitation of the Humans to think about more than 20 scenarios.

If you look at it from the point of view that it is a human limitation then none of the stakeholders can be blamed.

But if you think about it from technical point of view this problem can be solved very easily by simply writing a software program that takes domain entities and its types as an argument and that can generate the combination of the types of each of the domain entities.

I agree that manually it is extremely difficult to think about the possible combinations, but for a software program it is just a matter of seconds.

According to me, this problem can be very easily solved by the analyst by using a bit of his engineering skills by using a software program to get the combinations of domain entities.

Both of these human limitations are interrelated with each other. For anyone to find out all the combination of different types of domain entities, the prerequisite is that he should be able to understand the structural complexity of the system in a single frame of vision.

The exact way of solving both these problems will be described in the section "Best Practices for modeling the structural complexity using class diagrams".

On one hand the lack of usage of engineering skills by the analyst to handle this complexity is the root cause of this huge problem in this software industry.

On the other hand the way Software development companies make this problem worse.

Generally in the software industry, all the roles of analyst, designer, engineer and unit level tester is all played a single engineer. As a single person is playing all the roles, the number of logical scenarios found and taken care of is far less than what if all these roles are played by different people or individuals.

Using these examples I have tried to demonstrate that bulk of the problems faced by the software industry are because of some human limitation wrt complex systems and these problems will continue to exist till we don't develop engineering tools and best practices to overcome these limitations.

Just by managing these technical human limitations by using the tools and techniques built by us , we can reduce the cost and time of Software Project by more than 60%.

Although this limitation looks fairly simplistic but remember

"Some of the most successful products in this world are successful because their designer or the inventors thought so simple and basic which others in the world were not able to think"

While "Some of the most daunting problems are mostly because of some very simple and fundamental reasons which most of the people tend to over look or underestimate its impact"

The limitations faced by human beings when dealing with complex software systems is one such problem which is very basic but also is the root cause of the entire mess in the software industry.

Another interesting aspect of these limitations is the fact the laymen, investors, vcs, customer representatives, the engineers and technical managers of the software development companies understand and accept these limitations but the strategic management of the software development companies refuse to understand and accept the same. We will understand the reasons behind the same in the next article "Requirements Engineering - A problem that no software development company wants to solve".

An interesting analogy

Lets say you are hungry and so you to a restaurant and ask the waiter for a sandwich.

The waiter goes inside and gets a "Grilled Chicken Sandwich" for you while you were expecting "A Non Grilled Vegetable Sandwich" .

Now who according to you should be responsible for this mistake? Whether the waiter is to be blamed or you will take the blame on yourself and pay for the "Grill Chicken Sandwich" as well.

So will you take the blame on yourself and pay for it? I am sure you will not take the blame on yourself as technically you are a customer... and as a customer you cannot be blamed?

Am I right... customers can never be blamed...

The reason is as a customer you can give ambiguous requirements, but why did the waiter accept this ambiguous requirements and presumed the sandwich to be something else.

The moment he would have realized that "Sandwich" is a ambiguous requirement, his job was to ask you about the exact sandwich you were looking out for.

In India, there are some small restaurant which does have a menu card... so the moment you tell the waiter that I want rice... he will quickly narrate all the variety of rice that he has and then requests you to choose a specific option. He is doing the same so that he doesn't take any ambiguous requirements.

Similarly although most of the restaurants these days have menu cards.... but even after taking the order the waiter repeats the entire order so as to double check the requirements.

Now in this scenario if waiter is to be blamed for capturing ambiguous requirements, then why do people blame the customer for giving ambiguous requirements?

I will conclude this article by saying, "Most of the problems wrt requirements engineering are man made and can be solved by using appropriate engineering best practices and software based tools, provided that management of the software development companies wants this problem to be solved."

I feel we have discussed numerous examples to also conclude that "Lets not blame the customer for improper requirements."

Hemant Jha
Founder - VPlanSolutions
Researcher, Trainer