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 couple of important points:
a) Customers also don’t have clarity on what exactly do they want?
b) Why don’t we ask this question – Why do you want this?
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.
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.
In the next article, we will be discussing the difference between requirements verification and validation. You might like to look at the following post: