One of the first things that I try to teach new BAs is Requirements Elicitation. This is a valuable skill that you can use at all levels of business analysis and there are many techniques to help you elicit the right requirements.
- Do not just gather requirements; find out what the project/client/sponsor really needs instead of just wanting. There can be a big difference between gathering and elicitation. They may want a product to look pretty but they need it to function a certain way to maximize value. That is why the BA is here;
- Discover what they NEED and what they can live without if they had to cut something. Turn this technique into an activity. If they say “nothing”, then play this game: If you could only afford to keep three requirements, what would they be or if you had to drop three requirements what would they be? This should get the sponsor thinking about what they really need;
- Document all requirements even if they seem stupid and will never be used. Something good might come out of it when you least expect it. Tip – Don’t tell the client their idea is stupid;
- Set a priority for each requirement. Some are simply more valuable to have than others. It is a good practice to know what the priorities are. Remember, priorities change over time so revisit your requirements often and update them as required; and
- Create a requirements backlog, meaning all requirements go into a repository that will be used to create other documents. For each requirement assign a usable value (how much work is involved), a priority, and relate it to other requirements if possible (some requirements have pre and post-requirements to make it work).
Successful elicitation is one of the most important activities you can do as a Business Analysis in both the Traditional and Agile world. Remember to review and look for feedback when eliciting requirements. People understand and explain things differently so be as clear as you can when you elicit, document, distribute, and manage requirements.