Why do we go wrong in Requirements gathering? | Business Analyst Tutorial

Why do we go wrong in Requirements gathering?

Requirements gathering is probably one of the most important responsibilities for a business analyst. But empirical data suggests we are not doing well in this. So, why do we go wrong in requirements gathering?

Before getting into the details of it, I must share with you one of my favorite videos. It’s a funny take on the requirements gathering meeting between the software company and customer representatives.

The video highlights a few important points:

a) Customers also don’t have clarity on what exactly do they want always?

b) Why don’t we ask this question – Why do you want this? What is the purpose of this feature?

All the studies about the success and failure of software projects have found that lack of clarity on understanding, is one of the top reasons for project failure. In this post, I am going to touch upon top 3 reasons for  – Why do we go wrong in Requirements gathering?

Not Asking “Why”

The question “Why do you want something to be done” is one of the most important questions – a Business Analyst can ask? It not only enables you to understand the actual requirements but also enables the customer to explore and understand – what do they want and why?

It’s important to associate requirements with the business objective and goal. Every feature or function included in the system must be linked to the end objective and not because it is a fanciful idea for the customer.

One simple example will further explain this aspect. Let’s say you visit a doctor because you have fever.  Once you meet the doctor, you may tell the doctor – “Doctor, I might have viral fever as I am having nausea and headache as well?” A good doctor  never takes that statement on face value, instead the doctor asks questions to do his own diagnosis. These questions could be:

  • Since when you are having fever?
  • Did you measure it?
  • Are you having body ache?
  • Do you feel chill?

Based on the answers to these questions, the doctor may ask for further investigation. Unless the doctor is sure of the actual reason, he/she can’t treat it.  Imagine doctor giving medicines based on our judgement rather than his own diagnosis.

One of the most important mistakes, we make as business analysts is to not use “Why”. I feel that’s the most important tool in the hands of a business analyst.

Making Assumptions

Our experience teaches us a lot. Business processes understanding is just one of the knowledge areas. During the requirements elicitation discussions, we come across several processes and functions, which might have been implemented in the past.

This helps us in a lot of ways. But many a times, we also assume that the current customer organization will also be doing this function as the previous customer. But that may prove to be wrong as every customer organization is different. This is the reason why we have customized project in the first place, otherwise we would have had only products.

How can we avoid this mistake? We can resort to the basic requirements gathering principle – Ask open ended questions for understanding requirements. For example?

  • What is your cross-selling process?
  • What do you do when the customer’s due date for bill payment is passed?
  • What is the process of account opening? How many steps are involved?

An account opening process for ICICI Bank is different from Kotak’s bank even though they may be savings bank account. The steps carried out in the back-end are completely different. This is my first hand experience.

 

Not validating requirements

We are used to test the developed software thoroughly but miss out on validating the software requirements. The reason for this is that we feel that verifying the SRS/FS using a checklist is validating the requirements. That’s far from truth. A perfectly verified requirements specification can produce completely useless software product. Why?

That’s because verification of requirements only look at what is written and documented. It does not check if the documented requirements will be able to help customer achieve the business goal. Most of the times, it does not.

Validation is the process of checking the written requirements (It can be in any format) with respect to the business objectives/goals. How do we do it? And how we should not do it?

  • We don’t do it by sending a 300 page SRS document (Do you think customer will read it?)
  • We do it by creating prototypes and get an agreement in a collaborative manner?
  • We can do it by creating demos or proof of concepts?
  • In case of product implementations, we do it by conducting Gap Analysis

In the next article, we will be discussing the difference between requirements verification and validation. You might like to look at the following post:

Top 6 characteristics of Well written requirements

About Techcanvass

Techcanvass offers IT certification courses for professionals. We are an IIBA endorsed education provider (EEP), iSQI ATP (for Certified Agile Business Analyst Training) as well as Agile Testing alliance partner for CP-SAT certification training in Selenium.

We have a Business analyst training course with domain training in-built into it. This training program offers you the opportunity to get certified with ECBA certification as well as have banking domain understanding.

Business Analyst Course | ECBA Certification training

Business Analyst Course | ECBA Certification training

Business Analyst Training with Banking Domain

Business Analyst Training with Banking

Business Analyst Short Courses

Business Analyst Training Self-learning Course

Cheers

Leave a Reply

Your email address will not be published. Required fields are marked *