The purpose of Requirements Management (REQM) is to manage requirements of the project’s products and product components and to identify inconsistencies between those requirements and the project’s plans and work products.
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.
Tip
REQM addresses all customer and contractual requirements handled by the project, thus providing a stable foundation for acquisition activities and for suppliers to perform project planning, development, testing, and delivery activities.
Nontechnical requirements include requirements such as cost, schedule, packaging, delivery, and other requirements not associated directly with attributes of the product or service. ARD develops customer and contractual requirements, SSAD formally hands them off to the supplier, ATM ensures that selected supplier work products meet these requirements, AVAL ensures that the resultant products are usable in their intended environment, and REQM manages requirements throughout the project’s life into transition and eventual disposal.
In particular, if the Acquisition Requirements Development process area is implemented, the resulting processes will generate customer and contractual requirements to be managed by requirements management processes. When the Requirements Management and the Acquisition Requirements Development process areas are both implemented, their associated processes may be closely tied and performed concurrently.
The project takes appropriate steps to ensure that the agreed-on set of 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 and all product and product component requirements. (See the definition of “bidirectional traceability” in the glossary.)
Throughout the process areas, where we use the terms product and product component, they are intended to include service and service component and should be interpreted in that way.
Tip
Requirements providers can include customers, end-users, suppliers, management, regulatory agencies, and standards bodies.
Sometimes the customer requirements baseline is different from the contractual baseline that the suppliers are working on. The acquisition project must maintain both baselines and plan to resolve or negotiate inconsistencies. The project will have similar, but often more complex, challenges when multiple systems are being acquired to provide a final capability.
Refer to the Acquisition Requirements Development process area for more information about transforming stakeholder needs into customer requirements and allocating requirements to supplier deliverables.
Refer to the Project Planning process area for more information about how project plans reflect requirements and must be revised as requirements change.
Refer to the Configuration Management process area for more information about baselines and controlling changes to requirements documents.
Refer to the Project Monitoring and Control process area for more information about tracking and controlling activities and work products that are based on requirements and taking appropriate corrective action.
Refer to the Risk Management process area for more information about identifying and handling risks associated with requirements.
Tip
Bidirectional traceability is important when evaluating the impact of supplier product and service changes with respect to customer needs and when evaluating the impact of customer need changes with respect to the supplier’s contractual baselines, products, and services.
Requirements are managed and inconsistencies with project plans and work products are identified.
The project 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, project plans, and work products
• Identifying inconsistencies among requirements, project plans, and work products
• Taking corrective action
Tip
Requirements are a vehicle used to communicate expectations with customers and suppliers. These expectations evolve as the project progresses.
Refer to the Project Monitoring and Control process area for more information about taking corrective action.
Requirements management typically includes directly managing changes to customer and contractual requirements developed by the acquirer and overseeing the supplier’s requirements management process. Requirements changes may result in changes to the supplier agreement.
Tip
“Requirements creep” is the tendency for requirements to continually flow into a project (often from multiple sources) and expand the project’s scope beyond what was planned. “Unfunded requirements” or “mandates” are frequent sources of cost and schedule overruns.
Requirements come from many stakeholders. Sometimes the eventual end-user community is too diverse to work with directly and will identify a surrogate to act as its representative. This additional layer between the acquirer and the end user is a potential source of risk for requirements interpretation issues.
Develop an understanding with requirements providers on the meaning of requirements.
To avoid requirements creep, criteria are established to designate appropriate channels or official sources from which to receive requirements. Those receiving 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 dialog is an agreed-to set of requirements.
Typical Work Products
- Lists of criteria for distinguishing appropriate requirements providers
- Criteria for evaluation and acceptance of requirements
- Results of analyses against criteria
- An agreed-to set of requirements
Tip
Examples of agreed-to sets of requirements include an operational requirements document capturing customer needs and a technical requirements document provided to suppliers as part of the solicitation package, both with appropriate sign-offs from relevant stakeholders.
Subpractices
- Establish criteria for distinguishing appropriate requirements providers.
- 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.
Tip
Having clear lines of communication and authority when dealing with requirements helps to keep requirements creep under control.
- Analyze requirements to ensure that established criteria are met.
- Reach an understanding of requirements with requirements providers so that project participants can commit to them.
Obtain commitment to requirements from project participants.
Refer to the Project Monitoring and Control process area for more information about monitoring the commitments made.
Hint
If you expect changes in requirements to occur, make sure your acquisition strategy and supplier agreements include explicit mechanisms for dealing with these changes.
The previous specific practice dealt with reaching an understanding with requirements providers. This specific practice deals with agreements and commitments among those who must carry out activities necessary to implement requirements. Requirements evolve throughout the project. As requirements evolve, this specific practice ensures that project participants commit to the current and approved requirements and the resulting changes in project plans, activities, and work products.
Tip
Project members who make commitments must continually evaluate whether they can meet their commitments, communicate immediately when they realize they cannot meet a commitment, and mitigate the impacts of not being able to meet a commitment.
Commitments are a recurring theme in CMMI. They are also documented and reconciled in PP, monitored in PMC, and addressed more thoroughly in IPM.
Changes to requirements may lead to changes in supplier agreements. These changes must be agreed on by the acquirer and supplier after appropriate negotiations.
Typical Work Products
- Requirements impact assessments
- Documented commitments to requirements and requirements changes
Typical Supplier Deliverables
- Supplier requirements impact assessments
Hint
When commitment changes cross organizational boundaries, use more formal processes and documentation to capture the changes, new commitments, and rationale for the change.
Subpractices
- Assess the impact of requirements on existing commitments.
- Negotiate and record commitments.
Manage changes to requirements as they evolve during the project.
Refer to the Configuration Management process area for more information about maintaining and controlling the requirements baseline and making requirements and change data available to the project.
Tip
Controlling changes ensures that customers, acquisition project members, and suppliers all have a clear and shared understanding of the requirements.
During the project, 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 project may, however, want to track appropriate measures of requirements volatility to judge whether new or revised controls are necessary.
Tip
“Requirements volatility” is the rate at which requirements change once implementation begins. Customer requirements and contractual requirements should be assessed for volatility. Customer requirements volatility could impact the acquisition strategy and contractual requirements volatility will impact the suppliers’ ability to progress as planned. It is important to identify when requirements volatility is increasing so that appropriate action can be taken.
If contractual requirements defined in the supplier agreement are affected by the changes, the supplier agreement also must be aligned with the changed requirements.
Typical Work Products
- Requirements change requests
- Requirements change impact reports
- Requirements status
- Requirements database
- Requirements decision database
Typical Supplier Deliverables
- Requirements change requests
- Requirements change impact reports
Hint
Many tools are available to help acquirers manage requirements. Consider using a tool compatible with tools used by customers or suppliers to aid in requirements traceability.
Subpractices
- Document all requirements and requirements changes that are given to or generated by the project.
- Maintain a requirements change history, including the rationale for changes.
Maintaining the change history helps track requirements volatility.
- Evaluate the impact of requirements changes from the standpoint of relevant stakeholders.
- Make requirements and change data available to the project.
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.
Tip
A change history should include rationale for the change to allow project members and other stakeholders to review why decisions were made when they are questioned later.
Requirements traceability can also cover 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 in conducting the impact assessment of requirements changes on project activities and work products.
Tip
The acquirer maintains an important link between customer and supplier requirements. Understanding the relationship between end-user needs and how those needs are implemented in supplier products or services is critical when performing ATM and AVAL activities.
The supplier maintains comprehensive bidirectional traceability to requirements defined in the supplier agreement by the acquirer, and the acquirer verifies that traceability. The acquirer maintains bidirectional traceability between customer requirements and contractual requirements.
Typical Work Products
- Requirements traceability matrix
- Requirements tracking system
Typical Supplier Deliverables
- Comprehensive requirements traceability matrix managed by the supplier as required by the supplier agreement
Tip
Maintaining traceability across horizontal relationships can greatly reduce problems encountered in transition to operations and support activities.
Subpractices
- Maintain requirements traceability to ensure that the source of lower-level (derived) requirements is documented.
- Maintain requirements traceability from a requirement to its derived requirements and allocation to functions, interfaces, objects, people, processes, and work products.
- Generate a requirements traceability matrix.
A comprehensive traceability matrix tracing from customer requirements to contractor requirements is maintained by the acquirer. A comprehensive traceability matrix tracing from contractual requirements to lower-level requirements is maintained by the supplier.
Identify inconsistencies between project plans and work products and requirements.
Refer to the Project Monitoring and Control process area for more information about monitoring and controlling project plans and work products for consistency with requirements and taking corrective actions when necessary.
Tip
Especially for large projects, product components are developed in parallel, sometimes by multiple suppliers, and it is challenging to keep all work products fully consistent with changes to the requirements.
This specific practice finds inconsistencies between requirements and project plans and work products and initiates corrective actions to resolve them.
Hint
Make sure acquisition planning documents, such as systems engineering plans and operational test and evaluation plans, are consistent. When a supplier or suppliers are selected, review supplier plans to ensure that they are consistent with acquisition planning documents.
Corrective actions taken by the project to resolve inconsistencies may also result in changes to project plans and supplier agreements.
Typical Work Products
- Documentation of inconsistencies between requirements and project plans and work products, including sources and conditions
- Corrective actions
Subpractices
- Review project plans, activities, and work products for consistency with requirements and changes made to them.
- Identify the source of the inconsistency.
- Identify changes that must be made to plans and work products resulting from changes to the requirements baseline.
- Initiate corrective actions.