• About
        • About
          • Overview
          • What to Expect
          • Careers
          • Team
          • CANDO Culture
          • FAQ
        • Praxent Pricing Guide

          To give you an idea of what investment looks like we've created a guide with estimates by product type as well as set-priced starter engagements.

          Download Now
  • Industries
        • Industries
          • Fintech
          • Insurance
          • Lending
          • Wealth Management
          • Real Estate
          • Other
        • Praxent Pricing Guide

          To give you an idea of what investment looks like we've created a guide with estimates by product type as well as set-priced starter engagements.

          Download Now
  • Services
    • Design
      • User Experience Design
      • Customer Journey Mapping
      • Design Sprints
      • UX Audit
      • User Testing
      • User Research
    • Development
      • Custom Software Development
      • Application Modernization
      • Mobile App Development
      • Web App Development
      • Web Portal Development
      • Front End Development
      • Backend Development
      • Cloud Deployment
      • Implementations
      • Staff Augmentation
  • Case Studies
  • Insights
  • Schedule a Call
  • About
    • About
    • Overview
    • Careers
    • CANDO Culture
    • What to Expect
    • Team
    • FAQ
    • #
  • Industries
    • Industries
    • Fintech
    • Insurance
    • Lending
    • Wealth Management
    • Real Estate
    • Other
    • #
  • Services
    • Services
    • Design
      • User Experience Design
      • Customer Journey Mapping
      • Design Sprints
      • UX Audit
      • User Research
      • User Testing
    • Development
      • Custom Software Development
      • Application Modernization
      • Mobile App Development
      • Web App Development
      • Web Portal Development
      • Frontend Development
      • Backend Development
      • Cloud Deployment
      • Implementations
      • Staff Augmentation
    • #
  • Case Studies
  • Insights
  • Contact

Speak with an expert

(512) 553-6830
Close menu

Topics

  • Uncategorized
  • Development
  • Life at Praxent
  • Project Management
  • Strategy
  • UX & Design
  • Tech & Business News
  • Mobile
  • Product Management
  • Featured
  • Financial Services Innovators
  • Awards
  • UX Insights

Types

  • article Article
  • podcastpodcast
  • presspress
  • webinarwebinar
  • whitepaperwhitepaper

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:

requirements gathering process graphic

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.

Free Ebook Download

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Featured

What the Kardashians can teach your FI about fintech partners to identify niche markets.

What the Kardashians can teach your FI about fintech partners to identify niche markets.

Read more

The 4 Reasons Software Modernizations Fail (and 12 Strategies for Success)

The 4 Reasons Software Modernizations Fail (and 12 Strategies for Success)

We share the strategies you’ll need to modernize your online customer experience so you can outperform your competitor...Read more

Making Sense of User Research: 5 Tools for Finding & Refining Winning Product Ideas (Plus Free Templates)

Making Sense of User Research: 5 Tools for Finding & Refining Winning Product Ideas (Plus Free Templates)

Making Sense of User Research: 5 Tools for Finding & Refining Winning Product Ideas Collecting quality data about … Read More

Many companies have built software applications that no longer meet customer expectations. We help financial services companies modernize those applications so they can remain relevant against born-digital competitors.

4330 Gaines Ranch Loop, Suite 230
Austin, TX 78735

(512) 553-6830

hello@praxent.com

DESIGN
  • UX Design
  • Design Sprints
  • User Research
  • User Testing
DEVELOP
  • Custom Software
  • Web Portals
  • App Modernization
  • Web Apps
  • Mobile Apps
ABOUT
  • Case Studies
  • Team
  • Culture
  • Careers
  • Insights
  • Contact

© 2023 Praxent
Privacy Terms Site Map