From LinkedIn’s Business Analyst Forum: Answering the question “How do you gather requirements”?
Gathering requirements for any project, large or small, is the absolute most important task in the process. Any consultant will tell you that most projects fail here. It’s not that they fail to gather requirements, but the requirements gathered are almost never adequate enough to satisfy the business need. More often than not, the tools will take the blame for the failure, but if proper requirements had been gathered at the beginning of the project, your team would have been able to select the correct tool for the job.
Now, having said that, the original question was “how” rather than “why”, so let’s discuss some of things we need to consider while gathering requirements. There are many strategies out there with great acronyms to help you remember them, but I can tell you right now, there is not one strategy that will work in all situations. Each project has a different audience, timeline, and budget that will all affect how you approach just thinking about the problem.
The one constant in all the different requirements gathering approaches is talking to people. But you will need to identify the correct people to talk to first. The list of people should not be restricted to just the business users or the stakeholders, but also the managers or owners of the budget of this project. You will need to determine, from a high level, what is the business need? When does the business need this feature by? And how much time and effort should be put into this project? The end users will not be able to answer all those questions for you. They can help with answering what the business need is, but your managers and other department managers will need to be interviewed to answer the other questions. The interview process is a cyclical one. My approach is normally to start a high-level conversation with the managers that bring me the problem and figure out how large of project we want to make this. From that conversation, I can figure out whether I need to talk to business users at all, or if we need to hold many in-depth conversations with all business users involved.
When interviewing the business users, it is very easy to get sidetracked. Once you get the business talking about what they want, the answer is generally, “everything”. As the business analyst, it is your job to direct the conversation to answering this one problem in a practical manner while encouraging an open conversation. Instead of focusing on finding out exactly what the users want to see, you should direct your inquiries toward “How do you want to interact with this feature”. Let’s say, the project that we are gathering requirements for is to show the users some new sales figures. Instead of drawing up exactly how the report should look, we should first determine how they want to categorize this data (i.e. by Sales Person, Geographic Location, Customer Name, etc…). The last thing you want to do is to back yourself in a corner by not making the design flexible enough.
One way to aid the conversations is to have a prototype that you can show users. After the first few conversations, you should have enough knowledge to put together a quick prototype. There are many great prototyping tools out there for various project types, but Microsoft Visio or even Microsoft Excel seem to be the most versatile tools and are generally readily available. Putting together a prototype and showing the users is the first step toward using the agile methodology for development. You’re probably not going to be able to gather all the requirements in the first cycle. People tend to remember needs or think up new wants after actually seeing a version of the possible product.
In the end, there is no best practice for gathering requirements, but a good approach is to stay flexible and continue the conversation throughout the design process. Needs and Wants will change, that is inevitable, so try to adapt your strategies to anticipate that.
You can subscribe to our RSS feed.