Who Dunnit? The Case of the Bad Requirements

Who is really responsible for a good requirement? If I’m a stakeholder and I say that I want a blue car that goes fast, is it my fault for the following issues upon production or the business analyst’s?

  • Car is the wrong color blue—Tarheel blue instead of Gator blue
  • Car has two doors, and I needed four
  • Car goes faster than a turtle but slower than I needed

As much as I’d like to blame the analyst, I am pretty sure we both have a piece of this problematic pie.  As a stakeholder I should know enough about giving good requirements that I would specify the color blue, the number of doors, and the exact speed to make it easier. However, the analyst also has a responsibility to understand enough about the system that they are gathering requirements about to make me think about things that I may have forgotten to specify (doors are one of those things that seem so obvious that you just might forget to talk about them at all).

What is funny is that we hear a lot about analysts getting better about eliciting requirements—but the business folks who are defining those requirements are rarely commented on as far as whether or not we need to improve as stakeholders.  Even the best analyst is not a mind reader (boy would it make it easier if you were), so I, as a stakeholder, have to figure out how to clearly explain my needs so that they can be met. Otherwise the frustration of receiving a product that doesn’t meet my vision is as much my fault as the team who executed the work.

In the case of the car, the mystery is solved—the analyst and the stakeholder killed the product in the requirements phase by bad communication.

Related Post
Predictive Analytics and Data Mining: Why Most Projects Fail and What Really Works

Related Courses
Business Analysis Essentials
Effective Facilitation for Business Analysts
CBAP® and CCBA™ Exam Prep Boot Camp

In this article

Join the Conversation