Other

Requirements Gathering Best Practices for Software Development

By |

Poorly-written requirements can cause a lot of problems in software development, and sometimes the symptoms can be traced back to requirements gathering. Not the actual system requirements or technical specs, but the process that lead up to the writing of the requirements.

We’ve compiled a few requirement gathering techniques that can help improve your process so you avoid running into issues later on.

The User Is First

When requirements gathering, you always have to keep the end user in mind:

  • What do they need to do?
  • How efficiently can we make that happen?
  • What sorts of flexibility might be required?

The user won’t be as concerned with how we address those needs from a purely technical standpoint. They won’t care if something is coded in C++ or Swift, for instance, unless it bogs down performance.

Requirements should, however, detail how a user would accomplish something using the software. How well that task is accomplished is where the UX meets the user, ensuring efficiency and good design are crucial components.

For discovery purposes, talking to users may be one of your best strategies when beginning your requirements gathering process, but you can accomplish this in a variety of ways. Surveys, interviews, facilitated sessions, prototypes and even just shadowing users as they complete their tasks can all be helpful to find out exactly how they get things done.

Three simple mistakes that will doom your requirements.

Show me.

You could also develop a use case diagram, including all the imagined steps in a new process. It could mean using the “As-Is and To-Be” model, where you diagram the current steps required (As-Is) and then add a “swim lane” (To-Be) showing the optimized solution. Additionally, you could collect stories from users on how they do things or generate a mind map to develop the optimal path.

Either way, you’ll be putting yourself in the role of the user and thinking about how they go from one step to another to achieve their goals using the software.

Freedom Within Limitations

One of the better requirement gathering techniques to remember is to know what users should not be doing with the software or abilities that should be invisible to them. Understanding this helps avoid feature creep and generally makes your project more manageable. For instance, creating a client-facing database program is great until you accidentally allow them to edit someone else’s social security number.

Think about the steps the user will take to accomplish their goals and what dependencies might be involved. For example, if a financial query is needed (perhaps they’re applying for a loan), you’ll likely need some way of securely gathering a social security number or other unique identifier.

With luck, this query has already been built and your team will only need to fetch the data, instead of constructing an entire database to store it. Or, it’s possible that is within your specification as the current business has no such database. Either way, for your own sanity during your requirement gathering steps, learn exactly how big the project will be.

Accurate Scoping of Projects

Often scoping the project involves a context diagram, so you can see how your project fits into existing tools. Setting the boundaries for a project requires a few things:

  • Unambiguous language (be precise)
  • Consistency (what is the context of use?)
  • Completeness (exactly what can or can’t this system do?)

The more specific and accurate your language, the better prepared your team will be to create proper workflows. For instance, writing the system will “process” something isn’t very helpful to a developer who must turn that fuzzy language into real output. Instead, writing, “The credit will be calculated using tables X and Y and their income from field 1,” is the type of specificity needed.

Consistency also comes from integrating with other systems and helps limit the amount of back and forth needed from other teams. How will the databases communicate? What APIs will be needed and how are they already being used?

What’s the “Golden Rule” when writing requirements?

Read it here.

The more you know about how the larger animal works, the better you’ll be able to plug and play your solution. This will also help when things like a user interface gets built. You don’t want a solution that stands out for all the wrong reasons.

And completion isn’t just finishing the job. If you’re wondering when you’re done creating your list of requirements, be sure to check out this article to learn when you’ve hit a stopping point.

Being complete also means being thorough. So combine your precision with consistency: knowing the system and how it works in the context necessary. And then focus on documenting the steps to get things done.

In this part, you can’t make assumptions. Take nothing for granted and be as detailed as possible when documenting every step needed to accomplish a task. This goes back to focusing on the user, asking them what they need and looking at how they hope to get there.

Stop, Collaborate and Listen

It would be great if requirements gathering simply entailed listening to a user’s dream workflow, writing up a diagram on how they’d accomplish a task and then getting to work. But the reality is you’re going to deal with dependencies, either within or outside your organization. To make sure everyone is reasonably happy, it’s important to zoom out and listen.

What are those key objectives again? What is it the group hopes to get done? Make sure these high-level goals are SMART: Specific, Measurable, Agreed-upon, Realistic and Time-based. The larger the organization, the more important each one of those items becomes.

Learn how to manage projects effectively using collaboration, traceability, test coverage, and more.

Read our white paper.

Ask stakeholders in the departments you will interface with what they need and how your team can make their lives easier. This is part diplomacy and part functional requirement gathering.

If the system you built requires a token for a user to interact with another system’s database, for example, make sure you put that in the spec. If that department has a frictionless way of making it happen, don’t reinvent the wheel. For more tips on diplomacy, be sure to read this article on dealing with stakeholder groups.

Lastly, getting potential roadblocks on your map early will save you considerable time down the road. Ask stakeholders across the organization what pitfalls other projects may have found, and work those into your specs as potential hazards to ensure you hit target dates for a smooth release.

For a deeper dive into writing better requirements, check out our white paper, “Writing High Quality Requirements.”

Jama Software
Latest posts by Jama Software (see all)