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, all requirements that the
customer and service provider have approved are addressed in the
Requirements Management process area.
Throughout the process areas, where the terms
“product” and “product component” are used, their intended meanings also
encompass services, service systems, and their components.
The written agreement can take the form of a
service level agreement (SLA), performance work statement (PWS), statement
of objectives (SOO), statement of work (SOW), or other type of agreement.
The written agreement may be part of a contract, a memorandum of
agreement, an approved requirements document, or some other
The written agreement may have to be
established while service provision is ongoing. The intent of Requirements
Management is to repeat the service agreement process during the service
period to support a positive relationship between the service provider and
the customer while meeting the needs of both. Requirements management
processes should encourage open communication without
The customer may be internal or external to the
service provider’s organization.
Sources and considerations for service
requirements include mission-related performance goals and objectives
(found in strategic plans and employee performance plans), monitoring
capability, current 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 may stem from the customer’s agreements with other suppliers
(e.g., the customer’s underpinning contracts, operational level
agreements, memoranda of agreement, subcontracts).
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
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.)
All projects 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 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