Gathering Requirements

In our previous post in this series, we discussed getting an overview of a system. In it, I provided the following items that you should know as you assemble an overview:

  • Why
  • People
  • Systems
  • Budget / Timeline notes
  • Technology

Now that we have an overview, it is time to start gathering requirements.

Requirements are, in many ways, the most important part of the development process. Without good requirements, you will struggle to build what you want or – more importantly – need. And building the wrong software is very expensive.

So how do we arrive at good requirements? There are many techniques for eliciting good requirements, but here are a few of my favorite exercises.

A Few Powerful Exercises

Journey (or Story Mapping) – One of the best ways to elicit requirements is using journey or story mapping to walk through a user’s experience. This technique helps teams arrive at a clearer idea of which features should be prioritized, identify gaps or dependencies, and – most importantly – reinforce that the focus of the product is the end user.

Newspaper Articles – A fun exercise we like is having product owners write two newspaper articles: one discussing how their project succeeded and another where everything ends in failure. In both cases, we want the product owners to focus on what happened that led to success and failure. As the product owners put thought into each of their stories, they will uncover some things they want to ensure they do and some things they should avoid.

Parallel Software Walkthrough – Another great technique I particularly enjoy involves walking through software similar to what we intend to build. Quick demos like this can quickly narrow your requirements by helping you understand how similar problems have been solved, validating key features, and spotting gaps and opportunities for innovation that can differentiate the product.

Are My Requirements Sufficient?

Once we have our requirements, how do we know they are good? The first thing to realize is that no set of requirements will ever be 100% complete.

Three activities will help you add the needed detail to your requirements:

  • Creating Estimates – People seem to dig into requirements more when they are being forced to estimate.
  • Reviewing Estimates
  • Create a Backlog from Multiple Perspectives – This third option is a lot of work, and might not be worth it, but it will often help you identify missing requirements or details.

Good requirements are critical for a successful software project. Taking some time to get these locked in can help everyone.

author avatar
Chad Michel Senior Software Architect
Chad is a lifelong Nebraskan. He grew up in rural Nebraska and now lives in Lincoln. Chad and his wife have a son and daughter.

Related posts