Software Requirements Gathering Techniques: A Formula For Success

Information on gathering requirements for software development, and an exploration of requirements gathering techniques. 

Editor’s note: This piece was originally published in 2014. It’s been so popular that we updated it with more details in 2019.

---

Once the big software requirements gathering questions have been answered and you’ve hired a software shop, the next thing your development team should do is start asking little questions. These questions are just as important as larger ones, and will relate to the dozens (or even hundreds) of specific requirements for your project.

The Importance Of Requirements Gathering In Software Engineering

When it comes to language, developers tend to be literal-minded. Code is written in explicit software “languages,” and each piece of code means one thing. In contrast, the language we use to communicate with clients can be loaded with ambiguity. Let’s go back to our widget manufacturer example from part I, and imagine a company is looking for a better way to manage their inventory.

Are they referring to an immediate, operational need for a better way of accounting for the physical number and locations of their inventory? Is the cost of order fulfillment is high necessitating an increase in efficiency? Or, do they find themselves cancelling orders because they don’t have a reliable record of what’s in stock? Do they need a way to predict what inventory customers will demand? Or, are they speaking holistically and aiming to completely overhaul their inventory systems to meet business goals?

It’s not so simple after all. To avoid potential ambiguity traps and achieve success, it’s imperative your custom software development partner fully understands each individual requirement of a project, no matter how generic or mundane the requirement seems. That’s where effective techniques for requirements gathering come into play.

Let’s look at a simple, standard requirement for any web application: the user login form. When listing their requirements, a customer may ask for “a user login form.” This appears simple, yet beneath this request is the potential for a lot of complexity. Let’s imagine the developer builds the user login form and launches it.

The day after the application launches, the customer finds users are sharing credentials, allowing for concurrent access to restricted areas. Because the safeguard to prevent the use of one account from two different locations wasn’t in the project scope (simply “login form”), the developer hadn’t built it. They add it.

The next day, another issue arises. Users who forget their usernames or passwords don’t know how to retrieve them. So the developer goes back and sets up username and password retrieval functions. Soon, though, the customer realizes users should agree to the terms and conditions before logging in for the first time. And then, that the systems administrator needs a way to customize access for users with an internal company email address. And so on.

This example illustrates the complexity of requirements gathering. What the customer thought was a single requirement was actually comprised of many, interrelated ones. A developer who wants a client to succeed shouldn’t accept requirements at face value, but ask the “who,” “what,” “where,” “when,” “why” and “how” questions.

Requirements Gathering Steps

To help clients and developers manage the process of requirements gathering, we recommend these 5 steps:

Step 1: Understand Pain Behind The Requirement

Before building a digital solution for a business challenge, developers should understand the analog process in intimate detail. The developer should also understand the challenge(s) the business faces without such a feature. How is the business coping today, and how will this feature reduce severity of the existing challenge?

Step 2: Eliminate Language Ambiguity

The client could be using the phrase “login form” to describe complex functionality, such as charging users a subscription fee for premium content. While Step 1 should help alleviate a potential gaps in understanding, one technique for clarification when requirements gathering can be following one of the following scripts:

“Sometimes when a client says ___, they really mean ___. Other times they might be referring to ___. What does it mean to you?

“Let’s pretend we built a feature that did exactly XYZ, what would happen then? What would that mean for the ___ challenge you mentioned in step 1?”

Step 3: Identify Corner Cases

Developers need time to consider the new feather’s impact on the rest of the system. It’s easy to imagine the “happy path” of a new requirement, but the devil is in the details. Corner cases are rare circumstances in which a feature may not work as expected and may be difficult to preconceived. It’s essential to build in time to discuss the requirement in detail to identify and separate corner cases into additional features.

Step 4: Write User Stories

Now you’re ready to write down the requirement. To capture the relevant information, we recommend using a Mad Libs-style process called the User Story. The basic blank user story looks something like:

“As a (user type), I want this feature to enable me to be able to (task to be performed) so that I can get (resulting business value).”

Writing a “perfect” User Story is not the point. Instead, think of User Stories as a bookmark of the conversation from steps 1-4. When it comes to things such as requirements gathering techniques, the Agile Manifesto emphasizes over-documentation, and it’s important not to get mired down. Instead work with your team to document and save it into your project management system. Then, move on.

Step 5: Create a Definition Of “Done”

The final step is to write a “How to Demo” or “HTD” for each User Story. Think of this as a written agreement that includes the definition of done.

HTDs outline steps that will demonstrate to both the developer and the client that the requirement has been met to the client’s satisfaction. This show-don’t-tell methodology removes any remaining ambiguity, illustrates that a requirement works, and illustrates how it works. This way, there are no unpleasant surprises at deployment.

Even though the written specifications may not have changed, the expectations for how those requirements will be realized may have. If they aren’t tested at regular intervals, both parties may be in for an unpleasant surprise when the project is delivered.

Intrigued?

Want to learn more about requirements gathering techniques for agile software development? Contact us today and find out how our approach uses these five steps to deliver successful software solutions.