Posted by tac_admin, March 28, 2016

How Excellent Requirements Bypass Development and Testing Errors

"what if i press this button" written in the sky with contrails left by airplane

Development and testing errors…

After you’ve invested so much time and effort into the business analysis for a project, only to see a technological glitch disqualify your progress…

Well, it’s not fun.

The old adage rings true: you can’t have a solution without eliminating the problem. In fact, this idea is the core principle behind successful business analysis. In this role, it’s up to you to eliminate obstacles that decrease profitability, waste time, and create a weaker organization.

In order to save time, gain respect, earn credibility, and eliminate needless stress, it’s vital to elicit really solid requirements before you start a project.

In this way, you will mitigate the risk of development and testing errors—which could reveal holes in your plan, add hours to your workday, and make stakeholders dissatisfied.

So how do you elicit the project requirements you need? Though in-depth, IIBA-endorsed training will deliver the nitty-gritty details that stop development and testing errors before they happen, here are a few vital details about requirements elicitation.

Solid requirements focus on the big picture.



End Users.




There are quite a few factors that go into the solution you provide. As you figure out whether or not you have the requirements you need, consider what the whole-picture outcome of your solution will be.

Don’t forget to ask about system requirements and previous issues, as you may uncover something that stops testing errors from happening.

Quality requirements take all stakeholders into account.

Stakeholders aren’t just the people you have meetings with. If I’m being honest, not all stakeholders are people you receive requirements from.

In fact, you may never see this person/these people.

Think of everyone who will be impacted by the work you’re doing—especially those who use the software you test. If you can’t satisfy all parties, then you need to elicit more requirements, or at a minimum have deeper discussions about the requirements you’ve already elicited.

Error-proof requirements are sought out, not given.

When you’re a top-tier business analyst, you won’t be given all the requirements you need. You’ll need to go find them, which means asking questions to stakeholders about what their organization experiences.

That means doing research, looking at old reports, going over company history, and most important, asking questions. When you do this, you uncover the requirements that will stop testing errors before they have a chance to derail your success.

It takes training to learn how to elicit these error-proof requirements.

 I mean comprehensive training—a BA leadership course that reveals how to…

  • Define business analysis and requirements.
  • Create a Requirements Elicitation Plan.
  • Elicit requirements from stakeholders using a variety of effective techniques.
  • Practice communication skills to engage stakeholders and uncover needs.
  • Understand communication and conflict resolution techniques and how to use them.
  • Understand how to select the analysis technique(s) that will most accurately help you identify requirements and communicate information to your stakeholders and project team.
  • Reduce development and testing errors by creating excellent requirements.

This (and much more) will ensure you elicit requirements that bypass testing errors.

One response to “How Excellent Requirements Bypass Development and Testing Errors”

  1. Denise says:

    Great article Teresa! It is so true that solid requirements make it so much easier for everyone (developer, DBA, testers, technical documentation and the external IT stakeholders too).

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.