Ever finished a class project that didn’t go well and suddenly everyone on your team starts throwing blame left and right? People blame each other for not doing the right work, or the project directions for not being clear enough. It’s not fun. Recreating that experience in a work environment isn’t any easier (in fact it’s worse because you’ll still have to work with them tomorrow). So, how can you avoid a project going poorly and a potential grunge match? Requirements. They’re the roadmap for project that outlines the scope of a project, what should and should not be done, and sets the work expectations for the team. A good set of requirements can create a near fool-proof project guide to ensuring success. Let’s hop in and take a look at what requirements are, how to manage the requirements gathering process, and why the whole thing is so important to product development.

What are Requirements?

A requirement is a broad term that gets used in a ton of different industries. Whether it’s law, or engineering, or general business, it’s just used to describe a necessary function, characteristic, or quality for a system. It’s a group of conditions or tasks that have to be completed for a project to be considered successful. Think car tires! Specific car tires have requirements for size and air pressure in order to fit the exact model of car they’re going on. A bike tire wouldn’t last too long on a pick-up truck, so teams have determined exactly how wide and thick a tire should be for a pick-up, how much air should be in the tire, the kind of material used for the tire, etc. Everything relating to the specs of ensuring the tire fits the car properly is the requirement aspect.

In product development, a requirement is a specific documented functional need that a particular design, product, or feature is aimed to solve for. Although requirements can become extremely granular, the high level goal is for the team that’s developing the new feature to better understand the specific expectations for what they’re building. Requirements are used to answer essential product design and development questions: What’s the purpose of the feature? What does the feature need to do? How should a user interact with the feature?

Requirements can be broken down into two main types: Functional and Non-Functional.

  • Functional Requirements refer to the actual product’s functionality: features, scalability, and capabilities as they relate to the greater product experience—what a system or feature does / does not do. For example, when a user clicks on a survey button, a survey loads. Depending on the size and scope of product or functionality in question, there could be multiple functionality milestones your team is trying to address. Setting functional requirements is a great way to track progress over time towards the broader product vision as you develop and release new sets of features.
  • Non-Functional Requirements refer to anything that’s not related to a product’s functionality: stability, security, and technical specifications—essentially how the system does it. Taking from the survey example above, a non-functional requirement for the survey could be how long it takes the survey to load after clicking the survey button. Non-functional requirements won’t affect the base function of a feature, so even if they’re not met, the feature will still perform. They’re product properties and focus on user expectations. How well defined and executed non-functional requirements are determines how easy the feature is to use.

Why are Requirements Important?

Every feature should be simple, fast, and powerful to be released in-product for customers to interact with. So how does a team determine what simple, fast, and powerful actually means in terms of functionality? Requirements—they’re the building blocks. They provide guidance for teams on what to develop as well as what not to develop. It’s a reference point for teams throughout the evolution of a project to ensure everyone is staying on track, and so that teams can later evaluate the success of what was intended versus accomplished within the scope of a project. You can also use requirements to communicate the scope of a project and limitations of development to stakeholders to ensure transparency and managed expectations prior, during, and after development.

What is Requirements Gathering?

In general, any project can go through the process of requirements gathering, whether your support team is determining the best ticketing system or you’re building a brand new car. Typically, requirements gathering refers to the process of researching and documenting project specifications for software development. The core of the process is just understanding what you’re building and why you’re building it.

Truly effective requirements gathering is started at the very beginning of the development process. Whatever the product vision is, requirements need to be communicated to members of the design and product teams so they can understand the function of the new feature, how it fits into the existing product, and what pain it’s designed to solve. The goal is to answer the following type of questions:

    • Who will be involved in development?
    • How long is the timeline for release?
    • What are the risks for the requirements gathering process?
    • What is the ultimate goal in understanding product requirements?

Why is Requirements Gathering Important?

Requirements are great, not just for teams and customer to understand what to expect from a feature, but also what not to expect. We’ve all been there; a new feature is released and suddenly customers (or even internal teams) are coming out of the woodwork asking about functionality and “wait I thought this release would mean we could do XYZ?”. Having goals and requirements for development documented is essential for setting and maintaining expectations along the development and release process. Teams need a base understanding of user needs and the larger product and business strategy. No matter who’s involved in the process (marketing, support, success), it’s important that PMs take the time to reiterate the broader story and pain the feature is meant to solve. Everyone needs to understand the user work flow and how that workflow ties into the product vision.

For internal teams, this means setting expectations for ownership of work throughout the development process. As requirements are outlined, tasks start emerging for the design team to create the look of a feature, product to wireframe it, engineering to code it, marketing to promote it, customer success to explain it to customers, and sales to, well, sell it. So, now it suddenly sounds like a requirement is influencing everyone in the company in some massive way? Does one little specification really matter that much? Honestly, yes. What ends up happening with requirements gathering is that each team will have an understanding of what tasks are required of them specifically so they can fit it into their own work flows and determine priority of tasks. Engineers, for example, are always notoriously busy. So if product rolls in with some fancy new feature that requires a ton of work for engineering, chances are the engineer assigned to those tasks is going to have stroke and then quickly try to code a basic pass.

Now, If there’s no predetermined specifications for what functionality that first pass should include and how it needs to work, then you should expect to have discrepancies between what engineering codes and the original intent from the product team. This in turn could lead to engineering having to do multiple attempts at a first pass release, which ends up delaying the release of the feature. Any discrepancy between product expectations and other teams, like customer success, can have a massive impact on customer expectations.

Managing customer expectations is one of the best ways to keep customers happy with your product and loyal to your company. One of the worst things for a business is when customer are told their problems will be resolved one way and then your team has to delay the timeline or worse, fail to deliver at all. If the customer success team isn’t kept up-to-date about the exact functional capabilities of new features, it makes it hard for them to properly communicate potential solutions and new workflows to customers who are relying on your product to make their job easier. Without proper communication, customers may become frustrated or feel they’re not valued, forcing the success team to have to double their efforts to ensure customers don’t decide to leave your product for a competitor. Cross-functional communication of requirements is essential to ensuring customers feel included in the development process and that their needs are being properly addressed by your company.

Now that we’ve established what requirements are and why they’re important, let’s break down the steps involved for properly gathering requirements to develop a new feature.

Steps for Requirements Gathering

For product development, requirements gathering will look slightly different at every company, but the general process can be thought of using four discrete steps: elicitation, validation, specification, and verification. For smaller projects, these steps can be done quite quickly, but for larger impact projects it’s important to complete each step thoroughly. First things first though: someone needs to be in charge of the project. A product manager is usually designated as the lead to determine key stakeholders to help brainstorm, analyze, and approve updates. Stakeholders are often key customers, team leads, and department mangers. Include anywhere from three to six participants from different departments (Product, Design, you can even Support and Success teams depending on the scope of the project) to work through the process. Once the team has been determined, it’s time to jump into the first step: elicitation.

1. Elicitation

Elicitation is where requirements first start being gathered. Once a team is put together, introduce the target user segment and the need you’re trying to solve. From there it’s time to start asking the key stakeholders questions to determine items of importance to the project. This can take the form of interviews, prototype previews, and questionnaires—every response is critical and needs to be documented. The goal is to understand what need is being solved, what functionality is desired, potential risk concerns, and indications of what success should look like for the feature. Not everyone in the target demographic is going to have the same use case. Try to keep in mind the feature needs to be able to support the minimal viable segment in question, but is also be used by the larger user population.

2. Validation

After the team has finished eliciting requirements from stakeholders and documented everyone’s responses, it’s time to start analyzing the information. It’s important to make sure the information from the elicitation process properly represents customer and stakeholder needs. You’re looking to consolidate requirements, identify any gaps, and start creating an outline of the development process ahead. All information should be easily accessible and understandable so that anyone, even people on different teams who’ve never touched the project, can quickly grasp the scope and goal to be achieved. Documentation at this phase is important for post-project reflection, as well as help keep the team focused and help manage stakeholder expectations.

3. Specification

Now that everyones’ goals and expectations have been documented and requirements have been reviewed, the next step is writing out the requirements management plan. This is the document that details the scope of the project, requirements, assumptions, and ensures that stakeholder expectations are achieved via the completion of the project. Creating this plan is the most involved aspect of the requirements gathering process. With the requirements management plan you should be able to track requirements through the rest of the lifecycle in a way that is actionable, measurable, and quantifiable.

Let’s take a second to break this down a bit more. So the management plan is the guide book and checklist for a project’s requirements and assumptions. Requirements were gathered and outlined in the first two steps and now we write the final list in this specifications stage. Assumptions are things that get baked into the requirements gathering process. They are generally thought of in terms of time, budget, and scope. So things like factoring in PTO, assuming optimal software performance, assuming a level of project priority in the roadmap, or even assuming that feedback from customers or stakeholders will be received within a specific timeframe. All of these various factors need to be considered and documented to help minimize risk at each stage of development.

By the end of creating the requirements management plan you should be able to answer the following kind of questions:

    • What is the project timeline (with a list of requirements at each time frame)?
    • Who is involved in the development of the project?
    • What are the potential risks of the requirements gathering process (including all assumptions)?
    • What’s the goal of the project?

With all requirements outlined and documented, you can report the plan to stakeholders for final review.

4. Verification

The final step is a review of documentation to ensure all requirements accurately and completely communicate needs and expectations determined necessary for project completion. This just means stakeholders review documents and approve that the management plan will actually deliver the intended results. Once this is completed, the team can move on to carrying out the development process. Should any questions or concerns arise later on in the process, the requirements management plan is the guidepost your team can return to for assistance and clarification.

How to Make the Requirements Gathering Process More Efficient

Listen, requirements gathering is one of the best things you can do to ensure product development is going to properly advance the product vision and address the needs of key stakeholders. But the process can be time consuming and if not carried out well, actually hinder your team more than it helps. So what can you do to speed up the process and make it an overall efficient and positive use of time and energy? We’ve outlined five key tips to help make that process more efficient for you. Let’s jump in.

Set Clear Goals

First thing you have to do is pretty basic, but it sets the tone of the entire process: set clear objectives and goals. Make it as easy to understand as possible, such as “we need to do X to get Y result”. While it can be interesting to branch off into other ideas and future features, make sure that you’re always coming back to the workflow and user need you’re trying to solve for now. That way, no matter how many feature iterations or passes are needed to complete the project, everyone can go step-by-step to ensure they’re only working on items that directly get to the stated goal.

Identify the Right Stakeholders

Most projects have an initial group of users that a product team will have easily identified as being directly impacted by a new feature. That’s a fantastic place to start. Once the interview process begins, make sure to ask probing questions to identify if there are any hidden stakeholders that may have been overlooked in the initial assessment. These may not be decision makers, but user whose product experience could be vastly improved with the creation of the new feature set. This additional input can uncover essential requirements for features that might have otherwise been overlooked.

Write Down Everything

Write everything, and that means absolutely everything down from the elicitation process. It may seem like overkill, but if the project sits on the back-burner for a week and you have to pick it up again, you’re going to want all those notes crystal clear for you and any stakeholder that views them. It’s not enough for you to understand the goals. You want to make sure your stakeholders know you understand the goals and objectives outlined. After interviews and meetings, edit the notes and share them with other members of the project team and key customers to make sure everyone is on the same page. Not only does this create a sense of buy-in from the team, but it also helps ensure that tasks are actively being carried out throughout the project. If it’s not in the notes or requirements plan, it doesn’t actually exist.

Avoid Assumptions

Accounting for assumptions is part of the requirements process but avoid assuming you understand requirements—even the simple ones. Take “add request button” for example. What is triggered? Is it open text? Can the user make more than one request? Where do the requests go internally? Who’s in charge of sorting requests? The requirements can go on and on. Break down even the most simple requirements to cover your bases and make sure documentation is in order so you don’t miss anything later.

Understand Priority

Requirements gathering sessions can quickly turn into customers and stakeholders dumping a wishlist on your team. While this can be overwhelming, don’t worry about building everything people ask for. What’s important to take away from this is a list of requirements and assign priority to the ones that will be apply within the scope of your project. Having a written out list of active and potential requirements is good when the team is short on time and need to focus efforts on essentials.


Requirements can make or break a product release. It’s about as obvious as it is challenging to complete well. Taking the time to thoroughly gather and document all the requirements and assumptions associated with a development project may seem tedious, but it’s more than worth the effort. If nothing else, you’re managing team and stakeholder expectations so everyone remains on the same page and can’t come back later to blame you for a project going up in flames (unless you totally messed up the scope of the project, then that’s on you, bud).

For more info, check out our podcast: https://podcasts.apple.com/us/podcast/a-realistic-review-of-requirements-gathering/id1503231746?i=1000488771240