A Project Management Process Area at Maturity Level 2

The purpose of Requirements Management (REQM) is to manage requirements of the project’s products and product components and to identify inconsistencies between those requirements and the project’s plans and work products.

Requirements management processes manage all requirements received or generated by the project, including both technical and nontechnical requirements as well as requirements levied on the project by the organization.

In particular, if the Acquisition Requirements Development process area is implemented, the resulting processes will generate customer and contractual requirements to be managed by requirements management processes. When the Requirements Management and the Acquisition Requirements Development process areas are both implemented, their associated processes may be closely tied and performed concurrently.

The project takes appropriate steps to ensure that the agreed-on set of requirements is managed to support the planning and execution needs of the project. When a project receives requirements from an approved requirements provider, these requirements are reviewed with the requirements provider to resolve issues and prevent misunderstanding before requirements are incorporated into project plans. Once the requirements provider and the requirements receiver reach an agreement, commitment to the requirements is obtained from project participants. The project manages changes to requirements as they evolve and identifies inconsistencies that occur among plans, work products, and requirements.

Part of managing requirements is documenting requirements changes and their rationale and maintaining bidirectional traceability between source requirements and all product and product component requirements. (See the definition of “bidirectional traceability” in the glossary.)

Throughout the process areas, where we use the terms product and product component, they are intended to include service and service component and should be interpreted in that way.

Refer to the Acquisition Requirements Development process area for more information about transforming stakeholder needs into customer requirements and allocating requirements to supplier deliverables.

Refer to the Project Planning process area for more information about how project plans reflect requirements and must be revised as requirements change.

Refer to the Configuration Management process area for more information about baselines and controlling changes to requirements documents.

Refer to the Project Monitoring and Control process area for more information about tracking and controlling activities and work products that are based on requirements and taking appropriate corrective action.

Refer to the Risk Management process area for more information about identifying and handling risks associated with requirements.

Specific Goal and Practice Summary

SG 1 Manage Requirements

SP 1.1       Understand Requirements

SP 1.2       Obtain Commitment to Requirements

SP 1.3       Manage Requirements Changes

SP 1.4       Maintain Bidirectional Traceability of Requirements

SP 1.5       Identify Inconsistencies Between Project Work and Requirements