Posted by tac_admin, August 27, 2012

3 Requirements Mistakes You Don’t Want to Make

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.

  1. 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.
  2. Don’t assume everyone in the requirements session knows what the expected outcome of the meeting is.
    • 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.
  3. Don’t come to the requirements meeting assuming “things will fall into place and a natural flow will occur. All you have to do is prepare the first question and everything will go from there.”
    • 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:
      1. Which system is the data being sent to or coming from?
      2. What triggers the data to be sent/received?
      3. 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.

2 responses to “3 Requirements Mistakes You Don’t Want to Make”

  1. Pilar says:

    Very good little article – well worth a read

  2. Teresa Bennett says:

    Hi Nutankumar – this really feeds into the post “I’m a business analyst, I don’t write code. The business analyst is not a developer and therefore should not be part of the development team – either onshore or offshore. Typically the business analyst role is not performed as an offshore role. It would hinder communication and make requirements elicitation very difficult.

Leave a Reply

Your email address will not be published. Required fields are marked *

Get in touch today

Speak directly with The Analyst Coach
and get pointed in the right direction.

Preferred Contact EmailPhone

Subscribe to receive our free white paper on how weak requirements effect strong companies


Sign up to get your FREE Business Analyst Survival Guide

Don't worry, we hate spam too. We will never share your information to third parties.