How to Gather and Document Project Requirements: Template

One of the most critical things a project manager must do at the start of any project is to get everyone on the same page about the scope.

Lack of clarity and information can lead to fear, concern, and misdirected focus that takes away from creating the best project possible. That’s why gathering and documenting project requirements is such an important step. This ensures you, your team, and all your stakeholders are clear about what the project is (and isn’t).

Before we dive into the process, let’s lay some groundwork with a few simple definitions.

What are project requirements?

Project requirements are specific tasks, features, or functions that must be completed for the project to be considered done. While many other subtasks and decisions will happen along the way, these requirements are the must-haves that will make or break the project's outcome. 

As the project manager, you’ll work together with key stakeholders to determine what’s required to make the project a success. This list of project requirements will help guide everyone else involved in the project, giving them a clear sense of what needs to be done.

5 types of requirements

There are different types of project requirements, and what you decide to document will really depend on the project. Here are a few categories you might consider:

• Business requirements: These define the project’s business needs and goals and should help you understand why this project is happening. Connected to larger business objectives, they’re often tied to financial, marketing, or marketplace positioning goals. 
• Stakeholder requirements: These requirements come directly from a project stakeholder or stakeholder group.
• Technical requirements: These describe specific behaviors within a technical system that must be completed to satisfy a user need.‍
• Functional requirements: If you’re creating a product or system, these requirements will describe how the product or experience will function or behave.‍
• Quality requirements: These requirements set the standard for the implementation of experience, design, or code. For example, your project might have accessibility standards you must meet (e.g., WCAG AAA).
  

What is requirements gathering?

Requirements gathering is the process of identifying the tasks, features, or functions that must be complete for a project to achieve its goals and be defined as a success. This process happens right at the initial phase of a project, though requirements might evolve with a project over time.

In a perfect world, the sales team or project sponsor would have the requirements list all buttoned up to hand off to you. But let’s be honest: That will never happen because it’s simply too early in the process to get it done. 

It’s up to you as the project manager to pull together a concrete list of requirements to guide the project. (If you have a business analyst on your team, they may also lend a hand.)

What is the requirements gathering process?

While your process may change based on the project size, type, and information on hand, requirements gathering generally includes these basic phases:

1. Initial discovery: Collecting any possible tasks, features, or functions the project may require from the project sponsor, client sales team, and all relevant project stakeholders.
2. List refinement: The process of reviewing, refining, and clarifying the project requirements with a smaller group of key stakeholders.
3. Requirement documentation: Capturing the final list of requirements in a file that can be shared with the project team and stakeholders.
4. Final approval: Confirming all stakeholders share a common understanding of the project requirements and agree to the final document.
5. Ongoing management: Managing requirements and updating documentation throughout the project as it grows and changes.

Why is it important to gather requirements?

With all the other tasks on your plate at the start of any project, you might wonder: Is a formal project requirements process really necessary? 

The answer is always yes—no matter how big or small the project is. 

Requirements gathering is critical to get stakeholders from all sides on the same page—bringing clarity and agreement on the path you’re about to take together. More importantly, it ensures everyone has a chance to define what’s needed to deliver a positive and successful project outcome. 

Here are a few more reasons why gathering requirements is a must for any project:

• Avoid scope creep and reduce risk. Having a clear list of project requirements—and even a list of what’s not a requirement—forces stakeholders to make tough choices early. It also gives everyone a straightforward document that can be referenced to avoid large scope changes once work begins.
• Reduce wasted energy. When stakeholders are unclear about what you’re creating, extra time can be wasted on defining, creating, and implementing something that doesn’t meet your business goals. The conversations that happen during requirements gathering will help all team members better understand what you’re doing together, leading to less wasted time.
• Solidify team cohesiveness. Gathering requirements early forces you to work through individual wants to come to an agreement about what you’re doing. This process can help eliminate (or greatly reduce) tension that arises from goal conflicts and internal politics and overall bring the team together.
• Bring comfort through clarity. Finally, the process reduces confusion and ambiguity at the start of the project when stakeholders are most tense and worried about being successful with such a large project. Having an open discussion and breaking the work into sizable pieces gives team members comfort because they’re seeing the process and know a project manager is there to help.

How to gather and document project requirements

Because every project is different, it’s important to understand what’s unique about each project and create a stepped approach that best supports your project. Use these basic steps as a guide to formulate a process that works for you.  

1. Collect the project requirements you already know 

One of the first things you’ll want to do is review existing documents and get a download from the client sales team or project sponsor. Identifying potential requirements from existing project docs not only helps reduce meeting time, but also shows your client your team listened by bringing past conversations forward.

Take this time to start listing project requirements in a spreadsheet. We created a free project requirements template you can use as a starting point.

In this initial discovery stage, focus on adding the following items to the list:

• Documented requirements: These come from RFPs, project proposals, the sales team’s notes, and other key project documents.
• Current requirements: These come from reviewing a client’s website or product and documenting how things work now.
• Invisible requirements: These are requirements that come to mind because you’re reading between the lines or have experience with similar projects or clients. You may note these as questions or something you’re just unclear about.
• Out of scope: It’s just as important to note items that are clearly out of scope so there’s no confusion. 

I recommend working with your team’s business analyst (if you have one) to identify the business requirements first. All other project requirements should align with these. 

Answer the following questions as you do this work:

• What requirements information already exists in the statement of work (SOW), project brief, or supporting documentation?
• What kind of information am I looking for?
• How will this information help the project and my team?
• Is there any question about what can be done within the scope of this project?
• Where is there confusion?
• Do I understand my client’s business and how our project goals map to it?
• Will these requirements help me set the proper expectations?
• Do I know the right people to go to for additional research?

2. Work with stakeholders to expand the list

You’re going to need stakeholder help to create, refine, and finalize your requirements list—whether it’s your core project stakeholders or an expanded group. Work with the project owners to identify key stakeholders you should include and how at this stage of the process.

This step is all about uncovering unstated goals, assumptions, pain points, and, of course, real requirements. I like to work offline or with smaller groups at this stage because it makes it easier to engage busy folks and reach more stakeholders. Here are few approaches you might use to gather feedback on project requirements:

• Send out a survey or worksheet for stakeholders to complete.
• Do individual or group stakeholder interviews.
• Give stakeholders direct access to the requirements document you started (usually best with smaller groups).

If you plan to assign homework or send a survey, make sure you give stakeholders guidelines around offline work, including:

• What happens to their feedback and how you’ll determine what’s a requirement or not
• The difference between a requirement, subtask, idea, or wish
• What you expect of them if they’re directly filling out the spreadsheet

Encourage stakeholders to work with their own departments or teams to make sure all necessary voices are heard. This will help flush out any unknowns. Your goal should be to work through all the things—not keep the list small.

Interview questions for gathering requirements

We created a requirements gathering interview template with some basic questions you might ask stakeholders at this stage of the process. Adapt and expand these questions to fit the project, stakeholder types, and format you use to gather information.

Don’t be shy about sussing out the details. For every top-level question you ask, use the response to dig down even deeper.

Several questions could come out of one single response, and each response could add requirements to your work. That means one simple “yes” or “no” answer could have a cost attached to it. That’s why this exercise is critical to understanding what your team can do within the project’s scope.

3. Conduct a project requirements workshop

Now that you’ve got a good healthy requirements list, it’s time to workshop it with a smaller, core group of stakeholders. Your goal should be to refine the list down to a formal set of project requirements you can pass around for approval in the end.

Here’s how to run a requirements gathering workshop for your project:

1. Start with your high-level business requirements. These should be firm before you outline any other project requirements.
2. Clarify the remaining project requirements on your list. Make sure they’re written in clear and simple language so everyone understands what each requirement is and it’s accessible for those outside the workshop too.
3. Add any project requirements that are missing.
4. Categorize and group project requirements to improve ease-of-use.
5. Prioritize what’s important. Then move items that don’t make the cut to another tab so they can be referenced later.

The bigger your project scope, the more sessions you’ll need. These tips can help you facilitate more effective project requirements workshops:

• Tidy up your working requirements list as best as you can and send it to attendees before the first workshop. Ask them to review it as prepwork to keep the meeting running smoothly. 
• Include visuals where helpful. Pictures enable everyone to quickly understand something better.
• Avoid user stories at this point. They aren’t always everyone's cup of tea, and that level of detail will only slow your workshop down.
• Add validation criteria as needed so there’s no question about how and when a requirement has been met.
• Make your workshops interactive. Add each requirement as a task or milestone in a shared TeamGantt project, and use Board view to refine your list and organize it into priority columns. (Bonus: It’ll save you time when it’s time to build your plan.)

4. Document your project requirements 

After the workshops are over, it’s time to get your project requirements list in its final form so it’s ready to share more widely for approval.

Ideally, you’ve been writing your official document as you go. Or maybe you already have a good start in a tool like TeamGantt.

Here are some items you may want to include in your formal project requirements documentation:

• ID number: Number each item for easy reference. For connected requirements, consider making them sub numbers (1, 1.1, 1.2, etc.).
• Requirement name: Give each item a unique name that’s short yet descriptive so anyone can scan the list quickly. 
• Description: Explain what the requirement is in more detail. This field might also include clear, testable information about what “complete” looks like.
• Category: Assign a tag that allows you to group several requirements together. This is especially helpful for organizing longer lists. 
• Requester: Knowing who originally requested a requirement makes it easier to follow up with that individual for further clarification, if needed.
• Phase added: It’s helpful to know when this requirement was added (e.g., sales, discovery, design) in case decisions need to be made about what to keep and what to drop once work is underway. 
• Out of scope: Mark this column for any requirement that’s determined out of scope.
• Notes: This enables you to capture additional questions and/or notes as they surface. 

Want to include additional items—like milestones and status—in your final requirements list? Just be sure the tool you’ll use to manage them can accommodate those extra details.

Download our free project requirements template

With TeamGantt’s free Google Sheets template, you can save time and effort on your requirements documentation. Feel free to fine-tune the format and only include what will be useful for your clients and projects.

Download our free project requirements template to get started!

5. Get final approval from key stakeholders

Now that the list is finalized, it’s important to make sure it’s shared with and approved by all key stakeholders. Doing this ensures everyone’s on the same page and provides clear visibility to the project scope.

Once the list is approved, this will become your working checklist to track and determine if the project is complete and delivered as promised. 

6. Manage your project requirements

From this point on, your job is to manage these requirements. This doesn’t just mean tracking progress and completion. It also includes planning and responding to change, as well as communicating regularly with your team and stakeholders.

Often, it’s best to move your list into a collaborative project management tool that allows you to assign dates and responsibility to project requirements. TeamGantt makes it easy to set requirements as milestones and track them to completion so everyone involved in the project has clear visibility and accountability.

You’ll also need a solid plan for handling any new requirements that arise. For instance, what’s the approval process for new requests? Is the budget or timeline flexible, or will something else have to be removed from the list? Change will happen, so having a process in place for managing change—and communicating it—is key from the start.

Finally, be sure to check in with stakeholders at each major milestone. This gives everyone a clear picture of progress, a chance to address anything that’s not working, and the ability to pivot if you need to change focus.

Meet project requirements more easily with TeamGantt

Want to keep better track of all your project requirements? With TeamGantt, you’ll have all the features you need to ensure projects finish on time and on budget, including:

• Drag and drop simplicity
• Easy team collaboration
• Customizable views
• Team availability & workload management
• Planned timeline vs. actual timeline
• Dedicated mobile app

And it all comes with a simple and intuitive interface that’s easy for anyone to use.

Give TeamGantt a free try today!

‍

About the author: Lynn Winter

Lynn is a freelance Digital Strategist who combines 20+ years of experience in content strategy, user experience, and project management to bring a holistic approach to her work. She has spoken at numerous local and national conferences and hosts an annual conference for Digital Project Managers called Manage Digital (http://managedigital.io/). You can connect with her at lynnwintermn.com.