Requirements gathering is the main objective of a business analyst. This can often be done with one-on-one interviews, but there are many other ways you can gather requirements from a user base. Let’s take a look at some effective business analyst techniques.
1. The Five Whys Technique
This technique is very powerful. It basically involves asking a series of questions starting with “why”, in order to find out the true need or desire of a solution. Each of the “why” questions builds on the previous answer. An explanation over at Mind Tools has this example:
In this example, the problem is that your client, Hinson Corp., is unhappy. Using the 5 Whys, you go through the following steps to get to the cause of the problem:
- Why is our client, Hinson Corp., unhappy? Because we didn’t deliver our services when we said we would.
- Why were we unable to meet the agreed-upon timeline or schedule for delivery? The job took much longer than we thought it would.
- Why did it take so much longer? Because we underestimated the complexity of the job.
- Why did we underestimate the complexity of the job? Because we made a quick estimate of the time needed to complete it, and didn’t list the individual stages needed to complete the project.
- Why didn’t we do this? Because we were running behind on other projects. We clearly need to review our time estimation and specification procedures.
As you can see in the example, the first question doesn’t really answer the problem, even though it might seem like that’s what you’re asking for. Only after a series of questions is the real answer found.
2. User Workshops
This is a common technique in businesses these days. A user workshop is a gathering of people that use the system or are involved in the process. They get together, usually for an extended period of time, and you discuss what the requirements, problems, solutions and needs are. Someone takes notes, and these are used as a basis for the requirements.
It’s very helpful as it gets everyone involved into a room. If you come across any items or areas you’re not sure about, someone else in the room should know the answer. They can speak to each other as well, to find out more about different areas of the system or process.
These workshops can be aided with cards or diagrams. It’s also helpful if you have an agenda, just like any other meeting that you hold.
3. Start With The Process, Not The System
A good technique for finding out problems is to focus on the process that is involved, instead of the system. Software systems are built around business processes. They aim to improve the way a process is done. If there is a need for a software project, it’s often done to improve a process.
When you speak to people, try to gather as much information as you can about the process. Learn why certain things are done. Don’t just focus on how the existing software or system is used, consider what the users are actually doing and need to do. This can help you (and sometimes the user as well) to notice any issues in the process that a new solution could solve.
4. Use Diagrams To Understand And Explain
Diagrams are probably my favourite business analyst technique. Maybe it’s because I’m a visual learner, but I find them very useful during my requirements gathering phase. You can use them primarily for two reasons:
- Helping your understanding. Quite often when we start a new role on a project, we don’t know anything about the environment. We need to work out how the systems interact with each other, what the business process is, and how the teams are laid out. Diagrams may be able to help you understand these if you create the diagram as you’re learning. Using them as a reference can be helpful when you’re gathering requirements.
- Explaining concepts to others. When you need to create your deliverable, which could be a document or a series of Agile cards, you will need to communicate how something works. This could also be a system, or a layout of a team, or a process. The idea is that you’ve done the research and other people need to know how it works.
Diagrams are very useful for this, and if you add supporting text, it’s a great way to inform other people.
5. Prioritization
Quite often in software projects we find users that have a large list of features. When you ask them about all the features, they say they would like them all in the solution, and that they are all important. What happens is that the project has a limited budget, and may not be able to support all of these features given the time and budget of the project.
What you can do in this case is prioritise. Ask the users (or other stakeholders that you’re talking to) to prioritise the requirements. Give them a rating on their importance.
You can come up with whatever system you like. A High/Medium/Low could work, though it indicates Low won’t get done and there are a lot of things that go into High. I prefer a five scale rating (1 to 5) or something similar, which allows for more detail around priorities.
If there are many people involved and they can’t agree on a priority, ask them to submit theirs individually and you can apply an average. I’ve done this on many occasions, with large groups of people, and it offers a fair way to determine what is important and what isn’t.
6. Comparative Solutions
When you’re gathering requirements and putting all of your business analyst techniques to use, you might want to consider if something has already been done.
Search around to see if there is an equivalent solution, either within your company or somewhere else, that may have solved your problem. It can help you think outside the normal boundaries of the organisation and come up with new ideas or new solutions.
Browsing industry forums or doing a Google search is a great way to get this information. If there are no solutions out there, it’s not a total loss. At least you have some information and know that it is a problem.
What’s your favorite technique to use? Share your answer in the comments section below!