When you prepare for interviews for business analysis roles, beware of seemingly innocent questions that might trip you up.
One example is: how would you gather requirements?
The trick is in the implication that what you do as a business analyst is gathering requirements.
You go around collecting them from the right sources, put them together, and voila! Tie a neat bow on a package and pass it down the line to the development team.
This is not how we do business analysis in real life. Indeed, this is not analysis.
Gathering means finding things that already exist. You just look carefully in the right places, gather the things you are looking for, and put them in the basket.
A junior analyst may sometimes answer like this:
“I will start by asking who my main stakeholders are. I will then interview them, and ask what are their requirements.”
Then the candidate will talk at length about capturing these requirements in a document, a backlog, or a requirements management tool.
They may continue to talk about naming or numbering the requirements and prioritizing them based on what stakeholders told them. They may mention must haves and nice to haves.
The problem here is, that the interviewee focuses on what happens after they’ve captured the requirements.
But the main point of this question is what happens before you capture requirements.
The million dollar question is, where will the requirements come from?
What you get from the stakeholder interviews is their perception of what is happening, their pain points, and their understanding of the problem.
Sometimes, they will also share their view of how things should work in the future – again, from their perspective.
What you need to realize is that the information from the stakeholders you’ve interviewed, and their opinion on what is happening and why may not be the full picture.
It may reflect the needs of a specific department or region.
Your job as a business analyst is to define what is required to implement a successful business change.
You need to understand the big picture.
You need to understand the real problem, which is frequently a combination of multiple problems, root causes and deficiencies.
To build the picture, you need to combine, analyze and break down information from multiple sources.
When stakeholders provide facts and details – you learn about their perspectives.
When you do your research, you will gather data, examples, artifacts, and analytics.
You will structure and restructure, decompose the answers, dig in and understand each piece of the puzzle.
This is what we do when we do analysis.
We use business analysis techniques to examine each part of the whole (business system or process) and all its interactions.
Creating business requirements is a process of synthesis. We need to figure out what needs to change, and how we should rearrange, modify, or create new components, processes and activities to achieve the goal, the desired business outcome.
So the answer to the question “How do you gather requirements” is not about asking questions and then writing down the answers.
It’s not about scribing.
It’s about listening, eliciting, researching, collecting information, and analyzing it. It’s about validating whether this analysis makes sense, and then formulating what is required to achieve the desired state.
If you can speak to this point, emphasize the role of analysis versus gathering information, and give examples of some business analysis techniques that you would use, this will show your interviewer that you understand the meaning of analysis.
If you would like to learn more about the business analysis process and techniques, check out other videos on the Why Change channel and previous webinar recordings.
Best of luck on your professional journey, and remember the value of analysis.
Check out Yulia’s online courses, personalized coaching and corporate training options for business analysts and architects.