It’s not often that you can point to one aspect of project management and declare it as one of the, if not
most important part of the process. But, when it comes to projects, PMI reports that as many as
because something goes wrong during the requirements process.
Not only is this step crucial to the success of your project, but the more time and money you dedicate to the process, the less likely you are to experience cost overruns. PMI also found that if you dedicate less than 5% of your project costs on requirements, you can expect to see
Yeah. Exactly. It’s that important.
So, rather than run the risk of your project falling apart (or costing you 200% more than it should have), let’s explore what you can do to master the requirements gathering process.
Get started with this requirements gathering template.
What are project requirements?
Project requirements are specific things (features, functionality, etc.) that are required for a project to be successful. This isn’t specific deliverables, though. It’s details that need to be included in the final deliverable. For example, if you’re building a map application that helps people get around new cities, you’d probably need map data, location data, and a way to provide direction (among other things) for the project to be considered successful.
The requirements gathering process involves determining what those requirements are, who they matter to, and why they matter. The goal is to make sure that everyone has a complete list of what needs to be done to complete the project successfully (
). This list of requirements can help you inform at every stage of the project, as
and should be included in your overall project plan or a separate project requirements document (PRD). You can link to the PRD from the project plan.
7 basic types of requirements
Not surprisingly, requirements vary from project to project. There could be technical requirements, business needs, or performance requirements. It all depends on the kind of project you’re running. Here are some of the more common requirements that we see in projects.
1. Functional requirements
These requirements lay out what you need the final product to be able to do. With apps and software platforms, these requirements are determined by what your end users need to do with your product. Referring back to the map application example above, your customers are going to need map data, location data, and the directions to get where you’re going. With these basic requirements, your app is going to be useless.
2. Non-functional requirements
Non-functional requirements kind of sound like you’re asking for things that don’t work, but that’s not what you’re looking for here. These are details that aren’t necessarily tied to functionality, but are still necessary. Factors like how quickly something loads or accessibility features. You don’t need, per se, they affect usability and, because of that, are required.
3. Performance requirements
Performance requirements are the benchmarks for how well your app should perform. This is details like load time, speed within the app, or uptime. These are the basic criteria for your app or product so customers can use them. These requirements will vary depending on the platform your app will be running on. An iOS app, for example, will have different requirements than an Android app.
4. Technical requirements
Technical requirements are the specifications that your app needs, so all people can use it. This includes factors like performance requirements and functional requirements. But, it goes beyond that to include details like security, access management, accessibility, and privacy controls.
Every project needs to bring something to your company, business requirements outline what that something is. A lot of the time, these are going to the usual business requirements, like make more money, bring in more users, or something like that. But, occasionally, you’ll be in a situation where you’re trying out a new feature or product where the goal is to reach a new audience, for example. Stakeholders are a good place to start looking for business requirements.
What is it that your customers are asking for? This is one of the more important set of requirements, but if you’re not listening to what the market says about your product (or products like it), you’re not going to have a successful project. Talking to your customers is a great place to start with gathering market requirements, but also researching similar ideas to what’s currently being done (and to identify what’s missing).
Product requirements are all the various requirements that help define your project. This includes market requirements, technical requirements, technical requirements, and more. The goal, according to PMI, is to
Benefits of a requirements gathering template
Like a lot of things related to project management, requirements gathering is a necessary step that helps you lead a successful project. If you’re not sure about the end goals, user requirements, or even what your product is supposed to do, you might be able to complete the project, but there are no guarantees it’s going to be successful (because we’ve all seen products launch that just haven’t been successful). That’s where the requirements document template comes in. It gives you a plan to follow and prevents you from using spreadsheets to manage the process.
Ultimately, using a template for requirements gathering saves you time and energy because you know exactly who you need to talk about different aspects of the process.
Setting project expectations
Not surprisingly, the requirements gathering process really helps you nail down the expectations for the project. You gain a strong sense of what the final product needs to do, how it needs to do it, what technical specifications it needs, and what your customers expect from the product. Without these requirements, you risk running a project that doesn’t meet expectations at all.
The nice thing about requirements gathering is that it requires that you talk to people. This means that you’re getting a clear understanding of what their expectations are. Not only that, but if you’re uncertain about something that’s written in the requirements, you have a starting point and know who to speak with to gain clarity.
Similar to how the template helps foster communication, it provides an easy tool for collaboration. A requirement gathering templates guides you to the people in your organization that you need to speak to and lets them know that their input is a valuable part of the process. Without the template, you risk missing out on input from key stakeholders who are critical to the success of your project.
With a template, you’re less likely to miss something (or someone) because all the steps are well-defined and the process is easy to follow. There’s no guessing, there’s no running around trying to figure out what else you need. It’s all right there in the template. And because having a strong understanding of the requirements is so critical to the success of your project, having everything laid out means you’re way more likely to knock the project out of the park (as opposed to missing the mark entirely and limping your way to the finish line).
A strong requirements gathering process and template help you do it right the first time. You’re probably not going to get everything perfect, but when you’ve completed a thorough requirements gathering process with a template to guide, you won’t have to redo as much because you know what’s expected. This saves you money, time, effort, and helps you launch when you’re expecting to (it also prevents you from launching a broken project).
How to define business and project requirements
Before you can gather requirements, you need to know what you’re looking for. It’s important to define the project's requirements ahead of time, so you don’t end up either missing something or just straight up getting the wrong information.
Analyze previous successful projects and documentation
Past projects are a good place to start identifying the necessary requirements for any given project. It helps to look at both successful projects (to better understand what led to the success) and other unsuccessful projects (to avoid attempting something that’s failed in the past). These projects help you understand what works best for you and your team, but also for your customers.
Collect feedback from team members
Your team is full of information about what works and what you need to make it happen. Talk to your team to understand what they need to get the job done and even what’s possible. You want to avoid over-promising with customers (or even stakeholders) and your team knows best.
Gather input from stakeholders
Stakeholders are a great reference when it comes to understanding business requirements. They know what customers are expecting, they know what leadership expects, and they can also help you get the resources you need to succeed. We’ve talked about the importance of stakeholder relationships in the past, and this is one of those times when having a strong relationship with your stakeholders can pay off.
From a technical perspective, prototyping helps you understand what a successful project requires. Even basic prototypes have minimum requirements to actually work. Not only that, but building prototypes before a project reduces the amount of time you spend iterating once you go into production.
Perform cost-benefit analysis
There are two ways a cost-benefit analysis can help. The first is that it helps you understand what the bare minimum in terms of requirements that project has to have to be worthwhile. It’s a good way to establish a baseline. It can also help you understand what can reasonably be done with any given project and still be viable. This is particularly helpful if you have a small customer-base and know that you can only expect a certain amount from them..
5 stages of requirements gathering process
Getting started is as simple as checking your stakeholder register (or building one) and figuring out who the key stakeholders are for your project. They’re the best source of information for the first round of requirement gathering.
2. Solicit requirements from stakeholders
Once you find your stakeholders, talk to them. Figure out what’s important to the success of the project. You’ll likely end up with a mix of technical and business requirements, which is exactly what you’re looking for.
Once you get the requirements from the stakeholders, record that information in the template. The information you record will vary from template to template (we’ve got a few examples of what this can look like
). You can, of course, customize the requirements based on specific project types or even your workflow.
4. Prioritize requirements
Create a hierarchy to help you identify which project requirements are must-haves (as in your project absolutely has to have this to succeed) and which ones are just nice to haves. You do this so you make sure each requirement has enough resources behind it. Lower priority requirements aren’t going to need as many resources behind it and if you don’t prioritize them, you risk potentially throwing too many resources at them, causing you to miss a more important requirement.
5. Monitor, manage and report
As always in project management, you need to watch progress. This helps you fine-tune your process, get better at identifying requirements, and (most importantly) stay on top of deadlines.
Get started with this requirements gathering template.
After you copy this template, you can start utilizing this free requirements gathering template for your projects and business.
How to use Coda’s requirements gathering template
Step 1: Fill out high-level details about your project
page, you’ll see some high-level details in a box at the top of the page. Fill out these details (and add more, if necessary) about your project. The Project Objectives and Project Scope might be stored in another document. By putting everything in one place along with your project requirements, it will require less work for your stakeholders in terms of finding the right document to look at.
Step 2: Key stakeholders and timeline
Further down the page, you’ll see tables for your stakeholders and a general timeline. After you’ve copied this template and shared it with your project team, you can select them in the dropdown menu in the
table is a high-level overview of the key milestones of the project.
Step 3: Requirements gathering
This is the main part of the template. Add project requirements after having met with all the key project stakeholders. You may not use all 7 types of requirements, but try your best. This project requirements document will be the main source of truth your project team and stakeholders will turn to in the future to make sure the project is successful and that the deliverable meets all required specifications. At the bottom of the
page, there’s a button for approvals. Stakeholders who have read and approved the project requirements document should click that button to indicate their approval of the document.
Requirements gathering template
A requirement is something that needs to happen in order for a project to be considered successful. These can be technical factors that a product needs, a specific business goal that needs to happen, or a customer need.
What is the difference between a requirement and a need?
The biggest difference between a requirement and a need is that a requirement is something that has to happen in a project. A need on the other hand, is why that something needs to happen. For example, your customers asking for a new app to use your services (the need) and for that app to be successful, they need to be able to do X, Y, and Z (the requirements).
What questions to ask for requirements gathering?
The best questions you can ask are:
What does this project need in order to be successful?
What pain point are we solving with this project?
What features does this need to be successful?
What’s wrong with current solutions and what can we do better?