The purpose of Requirements Management (REQM) is to manage the 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 those requirements levied on the project by the organization. In particular, if the Requirements Development process area is implemented, its processes will generate product and product component requirements that will also be managed by the requirements management processes. Throughout the process areas, where we use the terms product and product component, their intended meanings also encompass services and their components. When the Requirements Management, Requirements Development, and Technical Solution process areas are all implemented, their associated processes may be closely tied and be 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, the requirements are reviewed with the requirements provider to resolve issues and prevent misunderstanding before the requirements are incorporated into the project’s plans. Once the requirements provider and the requirements receiver reach an agreement, commitment to the requirements is obtained from the project participants. The project manages changes to the requirements as they evolve and identifies any inconsistencies that occur among the plans, work products, and requirements.

Part of the management of requirements is to document requirements changes and rationale and to maintain bidirectional traceability between source requirements and all product and product component requirements (See the definition of “bidirectional traceability” in the glossary.)

All development projects have requirements. In the case of a project that is focused on maintenance activities, the changes to the product or product components are based on changes to the existing requirements, design, or implementation. The requirements changes, if any, might be documented in change requests from the customer or users, or they might take the form of new requirements received from the requirements development process. Regardless of their source or form, the maintenance activities that are driven by changes to requirements are managed accordingly.

Refer to the Requirements Development process area for more information about transforming stakeholder needs into product requirements and deciding how to allocate or distribute requirements among the product components.

Refer to the Technical Solution process area for more information about transforming requirements into technical solutions.

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

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

Refer to the Project Monitoring and Control process area for more information about tracking and controlling the activities and work products that are based on the 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       Obtain an Understanding of 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