How to Compile a Project Requirements Document

Do you know that inaccurate requirements gathering appears to be one of the common causes for project failure?

This fact makes us take a fresh look at this process. Collecting and documenting project requirements may seem a formality and additional paperwork, but in fact, if done correctly, it will become one of the prerequisites for project success.

So, what should you know about project requirements and how to create a proper requirements document? Read on to find the answers.

What Are Project Requirements?

Project requirements refer to the tasks that must be completed and/or conditions that must be met to deliver a project successfully. Their purpose is to give an insight into the kind and scope of work that must be completed that will become the basis for a project plan. Also, gathering and documenting project requirements will ensure that the goals of a project will be met and customers/stakeholders will be satisfied with the final outcome of a project.

There are the following types of requirements that must be taken into account, according to PMBOKGuide.

Business requirements relate to business needs of an organization as a whole. They should be defined at the stage of project initiation, as they are the starting point for other types of requirements. Business requirements determine the value of a solution, i.e. the final deliverable.
Stakeholder requirements represent the needs of stakeholders – those who have a certain interest in the product or services that are going to be delivered. Their requirements can sometimes be conflicting, which will affect all the project constraints. So, it’s important to negotiate and prioritize them from the outset of a project.
Solution requirements are features and characteristics of a final deliverable that meet both business and stakeholder requirements. They include functional and non-functional requirements. The functional ones describe the deliverable’s functions, while the non-functional ones are about the way it’s going to work.
Transition requirements represent temporary conditions or capabilities (e.g. data conversion, training requirements) needed for the change from the current state into the future state (upon the project completion).
Project requirements focus on the project implementation itself: deliverables, milestones, due dates, etc.
Quality requirements make it possible to evaluate the success of project delivery.

Requirements may vary depending on the type of a project, its customers, and stakeholders.

Benefits of Collecting and Documenting Project Requirements

Despite the fact that preparing a requirements document is rather time-consuming, this procedure is worth the effort, and here is why.

Firstly, documenting the requirements eliminates unrealistic expectations:

customers and stakeholders will get the idea of what the final output will be;
a project team will have a clear understanding of the results they are expected to achieve.

Secondly, a requirements document will serve as a road map that will make the work on a project more predictable for the team and therefore more efficient. Also, having an approved requirements document saves time, money and effort: more clarity → less assumptions and misunderstandings → no need to rework.

And now, let’s consider how to gather requirements to make the requirements document a really actionable tool.

Gathering and Documenting Project Requirements

Despite the fact that there are many types of projects with different conditions, participants and requirements, in this section, we’ll outline the general procedure that can be taken as a basis for all projects.

In a nutshell, gathering requirements involves identifying and documenting the tasks, features, and functions of a product/service that will be created/delivered upon the project’s completion. But let’s consider this process in more detail.

Identifying and collecting requirements

The following techniques can be used to identify and gather project requirements:

questionnaires: their advantage is that they work well when you need to gather information from various stakeholders, but the disadvantage of this technique is that preparing them can be rather challenging;
interviews;
brainstorming: it is useful for eliciting new requirements for a new product;
benchmarking: this technique involves comparison of the actual state of things with best practices, which will become the basis for defining requirements capable of improving the current situation;
analyzing documents: business plans, use cases, company strategy, technical documents, etc.
the Delphi technique: stakeholders with different levels of influence communicate their requirements anonymously, and they are afterwards analyzed and prioritized. The benefit of this approach is capturing stakeholder requirements free from bias or influence.

Make sure that collected requirements are as detailed as possible as leave no room for assumptions and unrealistic expectations.

It’s also important to record each requirement providing the following information: a title, a description, the source of a requirement, a substantiation for it, a list of stakeholders affected by it, and anticipated priority.

Prioritizing the requirements

As the next step, you should review the collected requirements and distinguish the ones that matter most for achieving project goals and the overall business strategy. To be most effective, prioritization should be conducted with the representatives of major stakeholders, project managers, and customers/users. The priorities are set as a result of a negotiation where all the parties discuss their needs and come up with decisions as to the final outcome that will meet all these needs.

It’s a good idea to create a list of less important requirements and return to them after the most important ones have been implemented or use them for future projects.

Creating a project requirements document

Having gathered and prioritized all the necessary requirements, you can proceed with writing a requirements document.

As a project requirements document example, we’ll consider the one for product development and outline what general sections it will have.

Introduction

It aims to explain the purpose of the requirements document and the way it can be used. Also, the following information should be included into the introduction:

technical background if necessary,
the scope and business case for a product,
a summary of the most important requirements.

General description

Describe the deliverable in non-technical terms and give an idea of what the product will do.
Mention the needs that the product is going to meet, primary stakeholders, and its developers.
Give a description of the product’s main functions and typical user characteristics.
Write about technical dependencies or constraints that will accompany the product development.