Requirements Defined (in just 24 letters)

Requirements Definition Jumble

How do you define requirements? A large portion of our job is learning, understanding and communicating requirements. But what are they exactly? If we don’t know how to easily define it, how will we know when we’ve got it? And how will we explain to our clients what we’re looking for?

Requirements are “the what but not the how”.

What problem does your client have?

What does your user need to be able to do?

What functions must a user be able to perform?

Okay, so I really could have defined that with just two words (and 8 letters). Requirements are “the what”.  But it’s important to distinguish that requirements are solution-independent, meaning they do not get into how you will solve the need. Many times, your client will ask you for something very specific which generally means they’re asking for how they want something accomplished. Our job as business analysts is to dig a little deeper to understand why they have the need…that is the requirement.

The way you word a Requirement will help you identify if you are including the how.

If a requirement is worded in such a way that you could meet the need in more than one possible way, then it probably does not contain the solution. However, if there is only one way to meet the requirement then you might want to consider re-wording it.

Let’s take a simple example. If your user says they need to be able to have the system send an email to a customer, that’s a very specific solution. The only way you could solve this is to have an email be sent. But, if you were able to dig a little deeper and find out that what they really needed was a way to communicate confirmation of a reservation with the customer, then you could meet that need with an email. But you could also meet the need with a text message, pop up message on a screen (if using a system), letter mailed to the customer…you get the point. While the solution may end up being an email, the requirement is that the user must be able to communicate confirmation of a reservation with the customer.

I sometimes like to think of this as finding the most generic way to say something very specific.

Why is it important to leave out the how?

Because you are not an order taker. It is your job to figure out the possible solutions for meeting your client’s needs. If you include the how, you’ve basically limited your options (which can lead to giving them what they asked for but not what they need); but more importantly you may not be solving the actual problem. Only by taking the time to understand what the client really needs to be able to accomplish, will you be getting at the true requirement.

How do you define requirements? What descriptions or phrases help your customers understand what information you’re looking for?

© 2010-2011 Real World BA, LLC. All rights reserved.
2 Responses to Requirements Defined (in just 24 letters)
  1. […] requirements are “the what”, then specifications are “the […]

  2. […] Hopefully by now the room is a little more relaxed than when you first started. Now you can start getting everyone focused on what lays ahead of them. Start by explaining what requirements are. Even if the team has worked with you before and you “think” they know what requirements are, remember this is likely not their primary job and taking a few minutes to remind them goes a long way to keeping them engaged. (Remember the story I shared with you when I assumed the team knew what requirements were?) If you recall from a previous post, I define requirements as “The What But Not The How”. […]

Leave a Reply

Wanting to leave an <em>phasis on your comment?

CommentLuv badge
Trackback URL