What is requirements gathering?
Requirements gathering, sometimes called requirements elicitation, is the process of discovering what your project needs to deliver for your stakeholders. It includes identifying and documenting the needs, constraints and expectations that will shape the project scope and solution.
Typical types of requirements include:
- Functional requirements – what the product, system or service must do
- Non functional requirements – quality, performance, security, legal and regulatory needs
- Business and KPI requirements – results, benefits and success measures
- Transitional requirements – what is needed to move from the current state to the future state
A simple, well structured Excel template makes it easier to capture, review and agree requirements before you commit to scope, budget and timelines.
- Example Project Requirements
- Preview the Requirements Template
- See what is in the template
- When to use this template
- How to use this template
- Tips for writing good project requirements
- Common mistakes when gathering requirements
- Using the template in Agile and hybrid projects
- FAQs about this template
- Download the Project Requirements Gathering Template
- Other requirements templates to download
The template is fully editable with Excel and can be converted or changed to suit your project. The contents of the template is shown below.
Example project requirements
Here is a simple example using a website redesign project.
| Requirement ID | Requirement Description | Requested by | Category | Priority | Complexity | Test or Verification | Phase or Release |
|---|---|---|---|---|---|---|---|
| REQ 001 | Users must be able to submit a contact form on the website | Marketing Manager | Functional | Must | Medium | Submit a test form and confirm email receipt and database log | Release 1 |
| REQ 002 | Website pages must load in under 3 seconds on a standard 4G connection | Product Owner | Non functional / KPI | Should | High | Performance test on staging environment | Release 1 |
| REQ 003 | Existing blog content must be migrated and kept live under the new design | Communications Lead | Transitional | Must | Medium | Content audit shows that one hundred percent of URLs are redirected correctly | Release 1 |
| REQ 004 | The solution must comply with GDPR and cookie rules | Legal and Compliance | Regulatory | Must | High | Formal legal review and sign off | Release 2 |
Preview of the template
The contents of the Requirements gathering template
- Project name
- Project manager
- Project ID
- Date
When should you use this Requirements Gathering Template?
Use this template whenever you need to define and agree scope for a project or change initiative. It is suitable for projects in any industry, including:
- IT and software projects
- Process improvement and automation
- Construction and facilities projects
- Marketing or product launches
- Organisational change and transformation programmes
The template is typically used by:
- Project managers to control scope and manage change
- Business analysts to structure workshops, interviews and document reviews
- Product owners to capture early requirements before creating a backlog
- Subject matter experts and stakeholders to record their needs in a consistent way
How to use the Project Requirements Gathering Template (step by step)
-
Download the template
Save a copy of the Excel file to your project folder and rename it with your project name or ID. -
Complete the document information
Fill in the Project Name, Project Manager, Project ID and Date. This allows you to reference the requirements log in other documents such as the Business Case, Requirements Management Plan or RAID log. -
Identify your stakeholders
List the key people and groups who will provide requirements. Include sponsors, end users, operations, IT, legal, finance and any external partners. -
Capture requirements from workshops and interviews
As you run workshops, interviews or review existing documents, log each requirement in a new row in the spreadsheet. Give each requirement a unique Requirement ID. -
Classify and prioritise each requirement
For each requirement, complete the Category, Priority, Complexity and Phase or Release fields. This helps the project team to sequence work, make trade offs and understand effort. -
Define test or verification criteria
Agree how each requirement will be verified. For example through testing, inspection, demonstration or a formal sign off. Clear verification criteria reduce disputes at the end of the project. -
Review and agree the requirements baseline
Once the log is complete, review it with your sponsor and key stakeholders. After sign off, the log becomes your requirements baseline. Changes to requirements should go through your change control process. -
Keep the template up to date
As the project progresses, update the log to show which requirements have been delivered and which are still outstanding. You can add extra columns such as Status, Owner or Date Delivered if helpful.
Tips for writing good project requirements
-
Be specific and measurable
Avoid vague words like fast, easy to use or user friendly. Specify measurable criteria. For example state the response time, number of users supported or pass or fail conditions. -
Describe the what, not the how
Requirements should describe what is needed, not how to design or implement the solution. Leave technical design decisions to the delivery team. -
Use consistent categories and priorities
Agree your categories, such as functional, technical, operational, KPI or transitional, and a priority scheme such as MoSCoW or P1, P2, P3. Use them consistently throughout the log. -
Check for conflicts and duplicates
As the log grows, look for requirements that overlap, contradict each other or depend on one another. Resolve conflicts early. -
Link requirements to business objectives
Where possible, tie requirements back to project objectives, benefits or KPIs. This helps you to say no to low value requests.
Common mistakes when gathering requirements
-
Starting design or build before requirements are agreed
Jumping into design, configuration or development before you have a signed off requirements log usually leads to rework and scope creep. -
Treating requirements as a one off task
Requirements evolve as you learn more. Keep the log up to date and use it as a living document, not a one time workshop output. -
Not involving the right stakeholders
If operations, support, compliance or other key groups are missed, new requirements often appear late in the project when they are more expensive to deliver. -
Mixing requirements with solutions
Statements like implement system X describe a solution, not the underlying need. Ask why the stakeholder wants that system and capture the requirement behind it. -
No link to testing
If you do not define how each requirement will be verified, it is hard to prove that the project has delivered what was promised.
Using the template in Agile and hybrid projects
Even in Agile and hybrid environments you still need to understand what problems you are solving and what success looks like. This template works alongside Agile practices.
You can use the requirements log to:
- Capture high level requirements at project kick off
- Provide input to the Product Backlog and User Stories
- Agree non functional requirements and KPIs that apply across many sprints
- Provide a baseline for scope discussions with sponsors and stakeholders
For teams using Scrum or Kanban, the requirements log sits alongside tools such as the Product Backlog, Sprint Backlog and Definition of Done.
Frequently Asked Questions
Do I have to use all of the fields in the template?
No. The template is fully editable. You can hide or delete columns that you do not need, or add extra columns such as Status, Owner or Date Delivered. The important thing is to keep the structure clear and consistent for your project.
What is the difference between a requirement and a user story?
A requirement is a statement of need that describes what the project must deliver. A user story is a user centred way of expressing that need, often used in Agile. You can capture high level requirements in this template and then break them down into user stories later.
How many requirements should I expect to have?
The number of requirements depends on the size and complexity of your project. Small projects may have twenty to fifty requirements. Large programmes can have hundreds. Focus on making each requirement clear, testable and linked to business objectives rather than aiming for a specific number.
How does this template link to a Requirements Traceability Matrix?
This template is used to capture and approve requirements. The Requirements Traceability Matrix then tracks those requirements through design, build, testing and deployment. Together they help you demonstrate that all approved requirements have been delivered.
Can I use this template in regulated industries?
Yes. The template includes fields for Category, Priority, Complexity and Test or Verification, which are useful in regulated environments. You may need to add extra columns or attachments to meet specific regulatory or audit requirements in your sector.