Requirements Management (REQM) (CMMI-SVC)

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

In particular, all requirements that the customer and service provider have approved are addressed in the Requirements Management process area. Customer requirements for services are often identified in written agreements created prior to or during the establishment of service delivery. The customer can be internal or external to the service provider’s organization.

Throughout the process areas, where the terms “product” and “product component” are used, their intended meanings also encompass services, service systems, and their components.

Requirements management processes should encourage open communication without retribution.

Sources and considerations for service requirements include mission related performance goals and objectives (found in strategic plans), issues identified during monitoring performance levels and service levels, constraints identified during selection of design solutions, and requirements derived from designing the service system (e.g., reliability, maintainability, availability, supportability, safety and health, mission operations, lifecycle cost, obsolescence management).

Other considerations affecting service requirements can stem from the customer’s agreements with other suppliers (e.g., the customer’s underpinning contracts, operational level agreements, memoranda of agreement, subcontracts).

The work group takes appropriate steps to ensure that the set of approved requirements is managed to support the planning and execution needs of the work. When a work group 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 work plans. Once the requirements provider and the requirements receiver reach an agreement, commitment to the requirements is obtained from work participants. The work group 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 products and services have requirements. In the case of maintenance activities, changes 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 end 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.