Requirements Documentation

Project success is directly influenced by the discovery and decomposition of stakeholders’ needs into requirements and by the care taken in determining, documenting, and managing the requirements of the product, service, or result of the project.

These requirements need to be documented in enough detail to be included in the scope baseline and be measured and validated. Requirements documentation assists the project manager in making tradeoff decisions among requirements and in managing stakeholder expectations. Requirements will be progres- sively elaborated as more information about the project becomes available.

When documenting requirements, it is useful to group them by category. Some common categories include:

  • Business requirements
  • Stakeholder requirements
  • Solution requirements
  • Transition and readiness requirements
  • Project requirements
  • Quality requirements

Requirements documentation should include at least:

  • Identifier
  • Requirement
  • Stakeholder
  • Category
  • Priority
  • Acceptance criteria
  • Test or verification method
  • Release or phase

Requirements documentation can receive information from:

  • Project charter
  • Assumption log
  • Stakeholder register
  • Scope management plan
  • Requirements management plan
  • Stakeholder management plan
  • Lessons learned register

It provides information to:

  • Stakeholder register
  • Scope baseline
  • Quality management plan
  • Resource management plan
  • Communications management plan
  • Risk register
  • Procurement management plan
  • Project close out report


Requirements documentation is an output from the process 5.2 Collect Requirements in the PMBOK® Guide – Sixth Edition. This process is done once for projects that have a well-defined scope that is not likely to change. For projects that are adaptive, the requirements documentation can evolve and change throughout the project.

Tailoring tips

Consider the following tips to help tailor the requirements documentation to meet your needs:

  • If you are using an agile or adaptive development approach you may want to incorporate information on the release or iteration for each requirement.
  • For a project with a lot of requirements you may want to indicate the relationships between requirements.
  • You can add information about assumptions or constraints associated with requirements.
  • For small and quick adaptive or agile projects, the requirements documentation and backlog can be combined.


The requirements documentation should be aligned and consistent with the following documents:

  • Requirements management plan
  • Benefits management plan
  • Quality management plan
  • Requirements traceability matrix
  • Release plan
Document element Description
ID A unique identifier for the requirement
Requirement The condition or capability that must be met by the project or be present in the product, service, or result to satisfy a need or expectation of a stakeholder
Stakeholder Stakeholder’s name. If you don’t have a name you can substitute a position or organiza- tion until you have more information
Category The category of the requirement
Priority The priority group, for example Level 1, Level 2, etc., or must have, should have, or nice to have
Acceptance criteria The criteria that must be met for the stakeholder to approve that the requirement has been fulfilled
Test or verification method The means that will be used to verify that the requirement has been met. This can include inspection, test, demonstration, or analysis
Phase or release The phase or release in which the requirement will be met