Why do we go wrong in Requirements gathering?

Why do we go wrong in Requirements gathering?

Requirements gathering is probably the most critical phase of every software project. But empirical data suggests we are not doing well in this. So, why do we go wrong in requirements gathering?

Before getting into reasons for it, I must share with you one of my favorite videos. It’s a funny take on the requirements gathering meeting.

The video highlights a few important points:

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

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 4 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.

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/her 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 well.  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 enough “Why”. What is stated by the customer stakeholder during requirements elicitation meetings should not be taken at face value.

Making Assumptions

Our experience teaches us a lot. Business processes understanding is just one of the skills, a BA acquires in his/her career. Over the years, working in variety of projects, build our skills about an industry, its processes and its implementations.

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. is that always true? More often than not.

Every customer is different.

So, How can we avoid this mistake? By keeping in mind a few things:

  • Treat every customer as different and so their processes
  • Always challenge your assumptions
  • Don’t hesitate in asking questions, even though simple (Ego is your biggest enemy)
  • Validate the requirements properly

As a business analyst, we can start by using open and close ended questions at the right time. Open ended questions are asked to understand the processes and its steps. Whereas close ended questions are asked to confirm an understanding. – Ask open ended questions for understanding requirements.

Examples of open-ended questions:

  • What is your cross-selling process?
  • What do you do when the 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.

Ignoring end users as stakeholders

End users: Users or customer employees, who are the actual users of the software (once it is ready). They are not the managers, who feel that they know every detail.

Ignoring these end users can prove to be counter-productive. It can happen in a project, if:

  • Customer managers/directors/CIOs tell the IT team that they know what is needed and there is no need to talk to the end users
  • We, as business analysts, feel that the end users are not savvy enough to give us valuable details.

It’s not something, we should avoid. The end users are the actual users and they can provide us important inputs from the ground zero.

 

Not validating requirements

We are used to test the developed software thoroughly but miss out on validating the software requirements, the right way. The reason for this is that we feel that verifying the SRS/FS using a checklist is validating the requirements or sending the well-written SRS document to the customer (for going through it and confirming it). That’s far from the 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 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, demonstrate it and get an agreement in a collaborative manner?
  • We can do it by creating demos or proof of concepts also?

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

Conclusion

As a business analyst, we should be aware of the factors, which prevents us from missing out on requirements. Requirements are the basis for the software development and getting them right, is our responsibility.

It’s important that we make ourselves aware of all the factors and aspects, which cause impediments in getting the requirements right.

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 Training

IIBA Business Analyst Training


Business Analyst Training with Banking Domain

ECBA Training with Banking Domain

Agile Business Analyst Training

Agile Business Analyst Training

Cheers

Leave a Reply

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