The Three Types of Requirements on Any Project

In discussing requirements on any project, it’s important to realize there are really three different types of requirements.

First are the known requirements. These are the requirements users tell us about. Analysts have honed good techniques over the years for gathering a project’s known requirements: interviews, story-writing workshops, open-ended questions, and more.

But we’re fallible. We don’t always ask all the right questions. And users sometimes don’t think of everything. Maybe a user interview was cut short, or a user was absent from a story-writing workshop.

Those requirements that don’t come up when we talk to users are a project’s overlooked requirements. They’re just as important as the known requirements, but we somehow miss them, don’t hear them, or the stakeholders never mention them.

An Example from the Grocery Store

Suppose you’re at a grocery store, doing your shopping for the week. Items on your shopping list represent your known requirements. You knew they were needed, so you added each to the list.

As you walk the aisles, you see orange juice and realize you’d forgotten to put that on the list. Orange juice is an overlooked requirement.

A Third Type of Requirement

With all items on your shopping list crossed off, plus that orange juice you’d forgotten to put on the list, you head to the checkout lines.

But on the way, one more item catches your eye, and you add it to your cart.

Have you ever been at the grocery store and bought something you didn’t even know you needed? It wasn’t on your list (a known requirement) and it wasn’t something you’d merely overlooked. It was something you didn’t even know you wanted until you saw it.

This happened to me about two years ago. I noticed something that looked like a huge, pimpled orange. It was called a Sumo.

A store employee offered me a sample. It was delicious. And I immediately put four Sumos in my cart. Before I saw them and tasted one, I had no idea I wanted one. I didn’t even know Sumos existed.

On that shopping trip, Sumos represented the third type of requirement: an emergent requirement.

Emergent Requirements

Emergent requirements are ones that develop through the act of building the product. The team demonstrates what has been developed so far, and users say, “What would really make this great is…”

Having seen a partial implementation, users identify new things the product should do. Emergent requirements are not things the team should have uncovered during a story-writing workshop or from interviews. They are not things the users could have identified if they’d just thought harder or longer when asked about what they need.

Emergent requirements emerge from users seeing the product under development.

The Universe of Requirements

The universe of requirements can be conceptualized using the following figure. On the left are the known requirements that come out of our discussions with users and other stakeholders. On the right are the overlooked and emergent requirements, which collectively make up a project’s unknown requirements.

There Are Always Emergent Requirements

Every project—well, maybe not a rewrite of Minesweeper—has emergent requirements. No matter how adept team members are at asking questions or how thoroughly users have thought about their own needs, not everything can be identified upfront.

Teams can often do better at reducing the number and significance of overlooked requirements. We can ask better questions, listen more actively, spend adequate time with users, and so on. But a truly emergent requirement is one that a team cannot rightfully be expected to have uncovered until users start seeing early versions of the product.

A Strategy for Handling Emergent Requirements

Since emergent requirements cannot be eliminated, the best strategy is to seek them out as early in the development process as possible.

This means that product owners should have their teams work earlier on the parts of a system they deem most likely to include emergent requirements.

How Have You Handled Emergent Requirements?

Emergent requirements often cause projects to be delivered late. Since the needs haven’t been discovered yet, teams often fail to consider them when planning. Has a project you worked on been affected this way by emergent requirements? How have you handled them?

Please share your thoughts in the comments section below.


A Free PDF to Help You Choose the Approach

A Free PDF to Help You Choose the Approach

I’ve created a PDF you can download that will help you decide which approach is best for any story you’re adding detail to. It also includes examples of the two approaches.

Download my PDF

0

Posted:

Mike Cohn

About the Author

Mike Cohn specializes in helping companies adopt and improve their use of agile processes and techniques to build extremely high-performance teams. He is the author of User Stories Applied for Agile Software Development, Agile Estimating and Planning, and Succeeding with Agile as well as the Better User Stories video course. Mike is a founding member of the Agile Alliance and Scrum Alliance and can be reached at [email protected]. If you want to succeed with agile, you can also have Mike email you a short tip each week.