How to Identify and Gather Project Requirements
According to the Project Management Institute, up to 70% of projects fail due to issues with requirements.
Unfortunately, this does make sense. If you don’t know what stakeholders want or expect at the end of a project, how can you complete the project successfully?
In this article, you’ll learn how to identify, gather, and manage project requirements. We’ll cover different types of project requirements, common techniques to gather requirements, and the importance of the Requirements Traceability Matrix.
Project Scope and Project Requirements
To understand the importance of project requirements, we need to start with project scope and product scope.
Project scope refers to the work, and only the work, needed to deliver the project on time and within budget.
Scope is recorded in the Project Scope Document, which describes project deliverables, the required work, expected business value, and any exclusions to the project.
The Project Scope Statement also defines the acceptance criteria for deliverables.
How is project scope defined?
Project scope depends on two elements:
- Product scope, the features, and functions of a product, service, or result.
- Requirements, “a condition or capability that should be present in a product, service, or result to satisfy its specifications’’ (Project Management Body of Knowledge).
Requirements are also defined as:
- Something that is needed or that must be done.
- A description of how a system should behave.
- A property or attribute of a system.
The final outcomes of the project – a product, service, or result – are measured against the agreed requirements.
Requirements drive every stage of the project.
A project is initiated to solve a business need. Typically, high-level requirements are documented at this early stage.
During the planning phase, you’ll need to work closely with stakeholders to explore existing requirements in further detail. You will use a range of techniques to identify, gather, analyze, and select project requirements.
Using a list of prioritized requirements, you can delve into detailed planning with tools such as the Work Breakdown Structure.
Once the project is underway, requirements become the basis of monitoring and controlling work, including change requests.
Finally, stakeholders expect to see their requirements in the final product or service before closing the project.
‘Expect’ is an important phrase in this context. Balancing stakeholder expectations, new change requests, and the original project scope is tricky!
If the project veers too far from stakeholder expectations, extensive re-work may be needed to deliver the original requirements. If the project is deemed unviable, the work may be canceled.
Later on, we’ll take a closer look at various techniques to identify and document requirements.
As you’ll see in the next section, there are several types of requirements to consider.
Types of Project Requirements
Project requirements are typically categorized as functional or non-functional requirements:
- Functional refers to the capabilities, usability, features, or operations of a product. Functional requirements describe the response of a system to inputs such as user behavior or data.
- Non-functional requirements are often directly related to functional requirements, for example, how quickly an app loads in a browser. Non-functional requirements typically focus on usability – behaviors and features that affect user experience. These requirements are defined as non-functional as the system can work without such elements.
Functional and non-functional requirements are also known as Solution Requirements.
Solution requirements are based on business and stakeholder requirements.
- Business requirements, the high-level needs of the organization. Business requirements are often documented during project initiation.
- Stakeholder requirements, the needs of a stakeholder or group. As the project manager, you will work closely with stakeholders to select high-value requirements in the project plan.
Other types of requirements include:
- Transition requirements, which help to move an organization from a previous state to a new state, for example, end-user training. Typically, these requirements are only documented once the final deliverable is complete.
- Project requirements refer to the actions, processes, and conditions of the project, for example, milestone dates.
- Quality requirements describe any conditions or criteria used to validate project deliverables.
- Uptime requirements for a service.
- Data storage capacity per customer.
- Back-up processes for managing risks.
- Fault tolerance, such as the ability to work offline.
Requirements will vary depending on the project, product, and stakeholders.
5 Steps for Identifying and Gathering Requirements
1. Create a Plan
Start by identifying relevant project stakeholders.
- What techniques you will use to identify and gather requirements.
- How to document the various outputs from these activities.
- How to finalize requirements with stakeholders.
Finally, contact stakeholders to arrange a time and place to start gathering requirements. Let stakeholders know if they need to do any preparation work in advance of the session(s).
2. Identify and Gather Requirements
There are numerous techniques to identify and gather requirements. Below is a brief list to help you get started.
- Brainstorming brings different stakeholders together to discuss the problem and the desired solution.
- Nominal Group Technique is used to prioritize existing ideas. The aim is to agree on and rank high-value ideas. This technique is frequently used during a brainstorm session.
- Interviews are a useful way to engage stakeholders on a one-to-one basis, especially on smaller projects.
- Questionnaires are an ideal way to collect feedback from a large group of stakeholders or to gather anonymous input.
- Delphi Technique begins with a request for anonymous input from stakeholders. The input is collated and shared with the group for review and prioritization. The process continues until a final decision is reached.
- Context Diagrams describe the functions of a system. The diagram outlines the steps users take to interact with the system (inputs) and how the system responds (outputs).
- Prototypes provide stakeholders with a working model of the deliverables for testing and feedback. Prototypes include small-scale products, mock-ups, and simulations. Prototypes can be used regularly to test and validate requirements as the project progresses.
Other activities to consider include:
- Reviewing existing documentation, such as the project plan, company strategy, and technical documents.
- Observing end-users as they carry out their day-to-day tasks.
- If the goal of the project is to improve an existing product or service, use this product/service as much as possible.
- Conduct workshops to map the ‘As-Is’ state for existing products and services.
3. Review and Prioritize Requirements
In this step, requirements are reviewed and analyzed against the goals and business case of the project.
Record the outputs in requirements documentation, for example, a simple table with high-level details.
Be sure to record any assumptions about the requirements along with processes for quality control.
4. Finalize Requirements
Share the requirements documentation with stakeholders for review and approval.
The approved document becomes an input to project scope, including the WBS, and acts as a performance baseline during project execution.
It’s also a good idea to create a Requirements Traceability Matrix, a document (or SharePoint list!) linking requirements to deliverables.
The document can include:
- A unique requirement name and number.
- A description of the requirement.
- Categorization or a means of grouping similar requirements together.
- Dependencies between requirements.
- Processes for testing, validation, and quality control.
- Relevant notes about the requirement.
5. Manage Requirements
During project execution, you need to:
- Ensure your team is working on activities to deliver the requirements.
- Leverage the Requirements Traceability Matrix to manage change requests carefully to avoid scope creep.
- Assess new requirements that emerge due to testing or quality checks.
Below is a summary of the 5-step process.
Gathering Requirements on Waterfall and Agile Projects
A waterfall or predictive project has defined phases. The scope of the project and deliverables are defined at the beginning of the project. Any changes are typically managed using a formal process.
Stakeholder feedback is gathered at key milestones or at the end of a phase.
As such, gathering requirements and defining the scope of work takes place during the project planning phase.
By contrast, requirements and scope are defined iteratively in agile projects. Deliverables are constantly refined as agile teams work in sprints.
At the start of each sprint, the team selects high-priority requirements from the backlog. Stakeholders should provide feedback regularly on the deliverables and the backlog.
Project requirements are your to-do list – the items your team will work on during the project to meet stakeholder expectations. Taking time to identity, gather, analyze, and prioritize requirements during project planning will make your project easier to control and complete.