Business analyst trainers and coaches (including myself) spend a lot of time telling you what you should do to be successful and to excel at your job tasks.
We don’t seem to spend much time telling you what you shouldn’t do. This post will focus on things you should not do when eliciting requirements.
- Don’t use the same approach for every requirements elicitation session.
- For example, a formal requirements workshop probably isn’t necessary for a small project with low risk. Usually informal working sessions are best in that situation.
- Take some time on each project to plan how you will elicit requirements, don’t just jump in and start getting requirements without first planning the best approach based on project size, risk, logistics, and budget.
- There are many different techniques for requirements elicitation, you don’t even have to use the same one for every session on one project. Mix it up, get creative. Keep the project team interested by changing techniques.
- Have you ever been told “hey, we just found out we need a BA for this project, it’s small, not a lot of work, but we need you to jump in for a couple of weeks and help out. We’ll need to join a requirements meeting tomorrow.”? That has happened to me before. You walk in the room without much planning, you may have been given a project overview, but that’s about all you know about the project. You have to assume this could have happened to some of the people in your well-planned requirements meeting. Maybe their manager just asked them to step in and attend a requirements session because they had to pull the other SME off for another project at the last minute.
- As the business analyst, you should start each requirements session by reviewing the importance of the project; the objectives, scope, assumptions and constraints, and expected business benefits so that all participants understand the significance and urgency of the project.
- If you take this approach you’ll end up missing requirements you should have discussed and captured.
- For example, you know there are other applications that interact with the application you are working on for your project so you have interface requirements sessions with each of the business areas that have an interface to your application. If you go to those meetings with the attitude that you’ll just ask them how they interact with your application, you’re probably going to miss some things. In this scenario, I would start out with three questions for each of the interface groups:
- Which system is the data being sent to or coming from?
- What triggers the data to be sent/received?
- What data is sent/received?
If you take some time to do a little planning and preparation, you’ll find your requirements sessions will be more effective.