Requirements Gathering Questions to Ask

Gathering requirements for a new project can get unwieldy and unorganized pretty easily. It’s easy to get lost or go down a deep rabbit hole. You may be getting excited about the new project’s technical challenges or be blindly following the client’s explanation and description. How do you know you’ve covered everything, though? What if you’re missing vital points?

No project is exactly the same, so it’s very difficult to make an exact blueprint of the questions you need to ask. However, there are many common patterns and themes in most projects. I’ve created a set of questions that form the basis of my requirements gathering conversation and I’ll share them below.

If you’re a developer or consultant, you can use these to help you during your client conversations. I would suggest using them as a guide to create your own project-specific questionnaire or outline.

If you’re a prospective business client, you can follow along with this article to prepare for the likely questions that will be asked during the requirements gathering process.

What Questions Should I Ask?

The following is an outline of the general topics to cover during a requirements gathering meeting for software and web application projects. The goal is to make sure no area or concept is forgotten. However, not all questions will apply to every project.

General

• What are you building?
• Why are you building it?
• If everything goes the right way, what does 1 year, and 3 years from now look like with this project?

Features

• What are the main features?
• What are some nice-to-have features, or things that you know are in the future?

Users

• Will users need accounts to use your site?
  • If so, what functionality does not need an authenticated user?
  • Will there be user levels/types/roles?
  • Social login? Email login? Combination?
  • Can users delete their own account?
  • Can you ban users?
  • If using emails, can emails be re-used?

Security

• Do you have any specific security concerns?
• What is / can you describe your data privacy stance?

Regulatory / Government

• Do you have any regulatory or state/country/locality provisions you need to account for?

Integrations

• What other systems might you integrate with?
  • Do you have or need a payment provider?
  • Do you have a mailing list provider?
  • How about CRM/Marketing Automation?
  • Any in-house or proprietary systems to integrate with?

Technical

• Do you have an existing tech team that you work with? If so…
  • Who is responsible for deploying the code?
  • Are they taking it over when the project is done?
  • Do you manage two teams, or are all programmers assimilated into a single team?
• Do you have hosting or server resources that I need to use?
• Are there any technologies you require to be used for the project? Languages? Servers? Databases?
• Do you have any uptime monitoring or are you interested in monitoring?
• What support expectations do you have?

Process

• Can the product release be phased or deployed in stages?
• What are the priorities of each main feature compared to the others?
• What process do you have for testing and user acceptance?

But Why These Questions?

Some of these questions are pretty self explanatory. Others may seem a bit confusing or even silly. But, each has a reason and a point. While the details of each question is beyond the scope of this article, the do fall into three main categories or reasons.

First, functionality. What types of features are expected? How do they relate to each other? Which are the most important so they can be prioritized. Which leads to the second category: implementation. Which order should the features be added? Can they be stepped into production or do they need to go all at once? Are there existing teams, infrastructures and products, rules and laws that we need to know about? Finally, what does the future look like? Who holds the keys to the project going forward? What kind of support is required.

You may find yourself digging into some areas more than others. For example, if this is a highly regulated industry, you might spend more time on the laws and certifications. For workflow tools, you might focus more on product integrations. Remember, these questions are just a base.

The End

Requirements gathering can be hard, and each project is unique, but that doesn’t mean that it can’t be done successfully. When you use a base set of questions, you can be pretty certain you will cover topics and strike up conversations that will flesh out the requirements pretty well.

Once you’re set with gathering your requirements, you should move onto writing requirements documentation. I have some guidance as well as an example wireframe and requirements document to help you get started.