Summary

The purpose of Requirements Management (REQM) (CMMI-DEV) is to manage requirements of the project’s products and product components and to ensure alignment between those requirements and the project’s plans and work products.

Description

Introductory Notes

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 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 the terms “product” and “product component” are used, their intended meanings also encompass services, service systems, and their components. When the Requirements Management, Requirements Development, and Technical Solution process areas are all implemented, their associated processes can be closely tied and be performed concurrently. The project takes appropriate steps to ensure that the set of approved 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, all product and product component requirements, and other specified work products. (See the definition of “bidirectional traceability” in the glossary.) All projects have requirements. In the case of maintenance activities, changes are based on changes to the existing requirements, design, or implementation. In projects that deliver increments of product capability, the changes can also be due to evolving customer needs, technology maturation and obsolescence, and standards evolution. In both cases, the requirements changes, if any, might be documented in change requests from the customer or end users, or they might take the form of new requirements received from the requirements development process. Regardless of their source or form, activities that are driven by changes to requirements are managed accordingly.
In Agile environments, requirements are communicated and tracked through mechanisms such as product backlogs, story cards, and screen mock-ups. Commitments to requirements are either made collectively by the team or an empowered team leader. Work assignments are regularly (e.g., daily, weekly) adjusted based on progress made and as an improved understanding of the requirements and solution emerge. Traceability and consistency across requirements and work products is addressed through the mechanisms already mentioned as well as during start-of-iteration or end-of-iteration activities such as “retrospectives” and “demo days.” (See “Interpreting CMMI When Using Agile Approaches” in Part I.)

References

Refer to the Requirements Development (RD) (CMMI-DEV) process area for more information about eliciting, analyzing, and establishing customer, product, and product component requirements.
Refer to the Technical Solution (TS) (CMMI-DEV) process area for more information about selecting, designing, and implementing solutions to requirements.
Refer to the Configuration Management (CM) (CMMI-DEV) process area for more information about establishing baselines and tracking and controlling changes.
Refer to the Project Monitoring and Control (PMC) (CMMI-DEV) process area for more information about monitoring the project against the plan and managing corrective action to closure.
Refer to the Project Planning (PP) (CMMI-DEV) process area for more information about establishing and maintaining plans that define project activities.
Refer to the Risk Management (RSKM) (CMMI-DEV) process area for more information about identifying and analyzing risks.

Contains

REQM.SG 1 Manage Requirements
Requirements are managed and inconsistencies with project plans and work products are identified.