Requirements Management (REQM) Process Area in CMMi

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. It is an Engineering process area at Maturity Level 2.
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.
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.

REQM vs.RD

- REQM is about managing the set of requirements and keeping it consistent with the project’s plans whereas RD is about developing the requirements in a systematic way.
- REQM is a Maturity Level 2 process area whereas RD is a Maturity Level 3 process area.

Specific Practices by Goal

SG 1 Manage Requirements
The project maintains a current and approved set of requirements over the life of the project by managing all changes to the requirements, maintaining the relationships among the requirements, the project plans, and the work products, identifying inconsistencies among the requirements, the project plans, and the work products and taking corrective action.
- SP 1.1 Obtain an Understanding of Requirements.
The intent of this SP is to establish a criteria for the project to identify appropriate requirements providers, criteria for the evaluationand acceptance of requirements, and ensure through an analysis or reviewprocess that the established criteria are met.
- SP 1.2 Obtain Commitment to Requirements.
Once the understanding of the requirement is established through the SP1.1, this SP deals with agreements and commitmentsamong those who have to carry out the activities necessary to implement the requirements.
- SP 1.3 Manage Requirements Changes.
Once commitments to the requirements are established and plans have been made. The project will transform from planning mode to execution mode. During the project execution phase, changes to requirements may occur for a variety of reasons. As needs change and as work proceeds, additional requirements are derived and changes may have to be made to the existing requirements.
- SP 1.4 Maintain Bidirectional Traceability of Requirements.
he intent of this specific practice is to maintain the bidirectional traceability of requirements for each level of product decomposition. When the requirements are managed well, traceability can be established from the source requirement to its lower level requirements and from the lower level requirements back to their source. Such bidirectional traceability helps determine that all source requirements have been completely addressed and that all lower level requirements can be traced to a valid source.
- SP 1.5 Identify Inconsistencies between Project Work and Requirements.
This SP focuses on maintaining consistency between requirements and project plans. I.e. the project plan should be revised, if changes to the requirements are identified to be impacting the schedule.