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?
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:
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.
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:
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:
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.
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:
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.
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?
In the next article, we will be discussing the difference between requirements verification and validation. You might like to look at the following post:
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.
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.
IIBA Business Analyst Training
ECBA Training with Banking Domain
Agile Business Analyst Training