I still experience numerous challenges in the requirements gathering process and I feel that there are many steps to be made from both sides: business analysts and customers (users). In my first article (Vol I) some months ago, I argued that eliciting requirements basically involves 2 activities: listening carefully and asking the right questions. Listening carefully involves making the others feel felt, heard, and valued. In the more recent Vol II, I tried to provide some information about how to ask the right questions to get what you want, i.e. meaningful, relevant, and inclusive requirements. In this article I will try to expand the discussion on how a business analyst can use powerful questions to set boundaries and keep the discussion on track. This will help users structure their thoughts in way that they will reveal critical information. Identifying the potential benefits It is a very common thing that users may ask for everything when it comes to providing requirements. They seem to find it challenging to distinguish between requirements with high benefits for them and the organization and ones with less or no benefits at all:
"It is still not clear to me how this is going to add value to the department, can you elaborate further?"
"Can you please explain how your colleagues will benefit from this new process?"
"Why does this matter to you?"
Identifying the hidden risks
Its a business analyst's job to identify potential risks of a proposed requirement. It is extremely valuable for the process to label those risks at this early stage instead of discovering about them much later. Don’t hesitate to ask about risks:
"Can you please pause for a moment and explain to me what could go wrong with the process you are describing?"
"Before going to the next point, may I ask about any potential risks if we proceed this way?"
Identifying the inputs and outputs Users express a need from their point of view. They rarely consider things that are relevant to their need but are outside their responsibility area. It is crucial that those elements are identified and labeled during the process:
"Ok I understand that you want to make a report and assess the performance of the trade promos on a monthly basis. And who will be providing the promo performance data? In what format? Will those data be provided on time?"
"Let’s say that we manage to create a rolling forecast for each SKU. How are you going to optimize inventory based on this forecast? Who will be involved, other than you?"
Identifying importance & priority
Finally, people like to consider everything as top priority. The business analyst will help them clarify criteria when it comes to setting priorities:
"You understand that after those sessions, we will involve your department head for setting the priorities altogether. Would he agree that this is a top priority?"
"Let’s pause for a while and think again about priorities: I have noted down 12 requirements and you have labelled 10 of them as top priority. This looks disproportional, don’t you think? How about taking a fresh look and reducing the top priorities to five?"
Every new requirements elicitation session or project is a learning step and the learning journey never ends. Just listen carefully to understand. And when you speak, show your curiousity to learn more.