What Is a Requirement? — Ross Belmont

What is a requirement? How would you define it? Is it…

a need that a customer has?
something a key stakeholder wants?
a raw idea from someone on the team?
a detailed description of how something should be built?
a specific solution someone has in mind?

It’s all of those, and none of those. Since a “requirement” can’t be defined in any useful way, we can’t point to something and say, “yep, that’s a requirement.” How many years has the technology industry been building things without a clear, shared definition of this word?

Let’s say you’ve “captured” a requirement or “gathered” it and you’re holding it in your hand, staring at it. What exactly are you looking at? It’s a bunch of words that fell out of someone’s mouth. That’s it.

What do you do with all these words? If you’ve got a big list full of them, how do you move forward? Well, I recommend you print them all out, bundle the pages together, and feed the pages to a goat. That way, at least the goat gets something out of it. Then, go figure out what would actually help your customers.

But I Already Know What It Needs To Do

Let’s say you’re not going into uncharted territory and you already have a good idea about what the product needs to do. OK, that’s cool. Gather your team together and tell them a story of a better tomorrow in which your customer is the hero and they’re succeeding at something using your product.

Kevin, who works the counter at the coffee shop, can take a credit card payment much faster using the new point of sale system. Finally he can focus on making the best espresso possible.

This is what we (and others) call a scenario. It’s a plausible story about a customer using your product in the future to create a positive outcome. Here’s another one:

Kevin moves quickly and sometimes makes a mistake with the register. Fortunately, it’s easy to void a charge and refund money to a patron’s credit card.

The two scenarios above could be grouped together under a capability called Accepting Credit Card Payments. After all, it’s not feasible for the coffee shop to advertise that they take credit cards unless they can both charge them and process refunds. Continue by listing all the scenarios you plan to enable in this release of the product.

Once you group your scenarios into capabilities, it’s usually pretty clear which capabilities need to ship first. The key is to not deliver a feature until your customer can walk through all the scenarios under the same capability. Put dates next to each of the capabilities and you’ve got yourself a release schedule. Congratulations! Your engineers can get started.

Epilogue

Tony Ulwick’s insightful book What Customers Want helped me realize requirements don’t exist. He advocates an even more rigorous method of determining a product’s feature set against a set of quantified outcomes (e.g. “Clerks can ring up patrons 50% faster with our new point of sale system”).

Check it out if you want to dive deeper.