Requirements Management: A Project and Work Management Process Area at Maturity Level 2
Purpose
The purpose of Requirements Management (REQM) is to manage requirements of products and product components and to ensure alignment between those requirements and the work plans and work products.
Introductory Notes
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.
Related Process Areas
Refer to the Strategic Service Management process area for more information about establishing and maintaining standard services in concert with strategic needs and plans.
Refer to the Configuration Management process area for more information about establishing baselines and tracking and controlling changes.
Refer to the Risk Management process area for more information about identifying and analyzing risks.
Refer to the Work Monitoring and Control process area for more information about monitoring the work against the plan and managing corrective action to closure.
Refer to the Work Planning process area for more information about establishing and maintaining plans that define work activities.
Specific Practices by Goal
SG 1 Manage Requirements
Requirements are managed and inconsistencies with plans and work products are identified.
The work group maintains a current and approved set of requirements over the life of the project by doing the following:
• Managing all changes to requirements
• Maintaining relationships among requirements, plans, and work products
• Ensuring alignment among requirements, plans, and work products
• Taking corrective action
If the Service Delivery, Strategic Service Management, or Incident Resolution and Prevention process areas are implemented, their processes will generate stakeholder requirements that will also be managed by requirements management processes.
Refer to the Work Monitoring and Control process area for more information about managing corrective action to closure.
SP 1.1 Understand Requirements
Develop an understanding with the requirements providers on the meaning of the requirements.
As the work matures and requirements are derived, all activities or disciplines will receive requirements. To avoid requirements creep, criteria are established to designate appropriate channels or official sources from which to receive requirements. Those who receive requirements conduct analyses of them with the provider to ensure that a compatible, shared understanding is reached on the meaning of requirements. The result of these analyses and dialogs is a set of approved requirements.
Example Work Products
1. Lists of criteria for distinguishing appropriate requirements providers
2. Criteria for evaluation and acceptance of requirements
3. Results of analyses against criteria
4. A set of approved requirements
Subpractices
1. Establish criteria for distinguishing appropriate requirements providers.
2. Establish objective criteria for the evaluation and acceptance of requirements.
Lack of evaluation and acceptance criteria often results in inadequate verification, costly rework, or customer rejection.
3. Analyze requirements to ensure that established criteria are met.
4. Reach an understanding of requirements with requirements providers so that participants can commit to them.
SP 1.2 Obtain Commitment to Requirements
Obtain commitment to requirements from participants.
Refer to the Work Monitoring and Control process area for more information about monitoring commitments.
The previous specific practice dealt with reaching an understanding with requirements providers. This specific practice deals with agreements and commitments among those who carry out activities necessary to implement requirements. Requirements evolve throughout the work. As requirements evolve, this specific practice ensures that participants commit to the current and approved requirements and the resulting changes in work plans, activities, and work products.
Example Work Products
1. Requirements impact assessments
2. Documented commitments to requirements and requirements changes
Subpractices
1. Assess the impact of requirements on existing commitments.
The impact on the participants should be evaluated when the requirements change or at the start of a new requirement.
2. Negotiate and record commitments.
Changes to existing commitments should be negotiated before participants commit to a new requirement or requirement change.
SP 1.3 Manage Requirements Changes
Manage changes to requirements as they evolve.
Refer to the Configuration Management process area for more information about tracking and controlling changes.
Requirements change for a variety of reasons. As needs change and as work proceeds, changes may have to be made to existing requirements. It is essential to manage these additions and changes efficiently and effectively. To effectively analyze the impact of changes, it is necessary that the source of each requirement is known and the rationale for the change is documented. The work group may want to track appropriate measures of requirements volatility to judge whether a new or revised approach to change control is necessary.
Example Work Products
1. Requirements change requests
2. Requirements change impact reports
3. Requirements status
4. Requirements database
Subpractices
1. Document all requirements and requirements changes that are given to or generated by the work group.
2. Maintain a requirements change history, including the rationale for changes.
Maintaining the change history helps to track requirements volatility.
3. Evaluate the impact of requirement changes from the standpoint of relevant stakeholders.
4. Make requirements and change data available to the work group.
SP 1.4 Maintain Bidirectional Traceability of Requirements
Maintain bidirectional traceability among requirements and work products.
The intent of this specific practice is to maintain the bidirectional traceability of requirements. (See the definition of “bidirectional traceability” in the glossary.) When requirements are managed well, traceability can be established from a source requirement to its lower level requirements and from those lower level requirements back to their source requirements. Such bidirectional traceability helps to determine whether all source requirements have been completely addressed and whether all lower level requirements can be traced to a valid source.
Requirements traceability also covers relationships to other entities such as intermediate and final work products, changes in design documentation, and test plans. Traceability can cover horizontal relationships, such as across interfaces, as well as vertical relationships. Traceability is particularly needed when assessing the impact of requirements changes on work activities and work products.
In a service environment, you should be able to trace stakeholder requirements to the elements of the delivered service and supporting service system that were developed from those requirements or other requirements derived from stakeholder requirements. Conversely, elements of the delivered service and supporting service system should be traceable back to the stakeholder requirements they meet.
Such bidirectional traceability is not always automated. It can be done manually using spreadsheets, databases, and other common tools.
Example Work Products
1. Requirements traceability matrix
2. Requirements tracking system
Subpractices
1. Maintain requirements traceability to ensure that the source of lower level (i.e., derived) requirements is documented.
2. Maintain requirements traceability from a requirement to its derived requirements and allocation to work products.
Work products for which traceability may be maintained include the service system architecture, service system components, development iterations (or increments), functions, interfaces, objects, people, processes, and other work products.
3. Generate a requirements traceability matrix.
A traceability matrix might have the list of stakeholder requirements and derived requirements on one axis. The other axis might list all of the components of the service system, including people and consumables. The intersections of the rows and columns would indicate where a particular requirement applies to the parts of the service system.
SP 1.5 Ensure Alignment Between Work Products and Requirements
Ensure that plans and work products remain aligned with requirements.
This specific practice finds inconsistencies between requirements and work plans and work products and initiates corrective actions to resolve them.
Example Work Products
1. Documentation of inconsistencies between requirements and work plans and work products, including sources and conditions
2. Corrective actions
Subpractices
1. Review work plans, activities, and work products for consistency with requirements and changes made to them.
2. Identify the source of the inconsistency (if any).
3. Identify any changes that should be made to plans and work products resulting from changes to the requirements baseline.
4. Initiate any necessary corrective actions.