Requirements Management: A Project Management Process Area at Maturity Level 2
Purpose
The purpose of Requirements Management (REQM) is to manage requirements of the project’s products and product components and to ensure alignment between those requirements and the project’s plans and work products.
X-Ref
REQM does not address eliciting or developing requirements. For more information on these topics, refer to the ARD process area.
Introductory Notes
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, thereby providing a stable foundation for acquisition activities and for suppliers to perform project planning, development, testing, and delivery activities. Requirements providers may include customers, end users, suppliers, management, regulatory agencies, and standards bodies.
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 can be closely tied and performed concurrently.
Throughout the process areas, where the terms “product” and “product component” are used, their intended meanings also encompass services, service systems, and their components.
Tip
Nontechnical requirements include requirements related to issues such as cost, schedule, packaging, and delivery, as well as other requirements not associated directly with attributes of the product or service.
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 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. Because the acquirer must often balance changes across multiple customers and multiple suppliers, effective “traceability management” has great value in this environment.
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 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 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 Acquisition Requirements Development process area for more information about developing and analyzing customer and contractual requirements.
Hint
When acquiring services, the organization must continue to manage customer and contractual requirements changes.
Refer to the Configuration Management process area for more information about establishing baselines and tracking and controlling changes.
Hint
Consider using the practices in REQM to manage the requirements associated with other processes such as training, human resources, and so on.
Refer to the Project Monitoring and Control process area for more information about monitoring the project against the plan and managing corrective action to closure.
Refer to the Project Planning process area for more information about establishing and maintaining plans that define project activities.
Refer to the Risk Management process area for more information about identifying and analyzing risks.
Tip
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.
Specific Practices by Goal
SG 1 Manage Requirements
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
• Ensuring alignment among requirements, project plans, and work products
• Taking corrective action
Tip
Requirements are a vehicle used to communicate expectations to both customers and suppliers. These expectations evolve as the project progresses.
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 originally planned. “Unfunded requirements” or “mandates” are frequently sources of cost and schedule overruns.
Refer to the Project Monitoring and Control process area for more information about managing corrective action to closure.
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 can result in changes to the supplier agreement.
Tip
Requirements may come from many different 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.
SP 1.1 Understand Requirements
Develop an understanding with the requirements providers on the meaning of the requirements.
As the project 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.
Tip
Examples of agreed-to sets of requirements include an operational requirements document that captures customer needs and a technical requirements document that is provided to suppliers as part of the solicitation package, both with appropriate sign-offs from relevant stakeholders.
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
1. Establish criteria for distinguishing appropriate requirements providers.
Tip
Having clear lines of communication and authority when dealing with requirements helps to keep “requirements creep” under control.
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 project participants can commit to them.
Tip
Maintaining two-way communication through the life of the project is critical to ensuring that a shared understanding of requirements is maintained between the project and the requirements providers.
SP 1.2 Obtain Commitment to Requirements
Obtain commitment to requirements from project participants.
Refer to the Project 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 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
Commitments comprise both the resources involved and the schedule for completion.
Changes to requirements can lead to changes in supplier agreements. These changes should be agreed on by the acquirer and supplier after appropriate negotiations.
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.
Example Work Products
1. Requirements impact assessments
2. Documented commitments to requirements and requirements changes
Example Supplier Deliverables
1. Supplier requirements impact assessments
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.
Subpractices
1. Assess the impact of requirements on existing commitments.
The impact on the project 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 project participants commit to a new requirement or requirement change. The acquirer negotiates commitments with the customer and supplier before committing to requirement changes.
SP 1.3 Manage Requirements Changes
Manage changes to requirements as they evolve during the project.
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 project may want to track appropriate measures of requirements volatility to judge whether new or revised approach to change control is 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 affect the acquisition strategy, and contractual requirements volatility will affect the suppliers’ ability to achieve progress as planned.
If contractual requirements defined in the supplier agreement are affected by the changes, the supplier agreement also must be aligned with the changed requirements.
Example Work Products
1. Requirements change requests
2. Requirements change impact reports
4. Requirements database
Hint
Many tools are available to help acquirers manage requirements. Consider using a tool that is compatible with the tools used by your customers or suppliers to facilitate requirements traceability.
Example Supplier Deliverables
1. Requirements change requests
2. Requirements change impact reports
Subpractices
1. Document all requirements and requirements changes that are given to or generated by the project.
Tip
Documentation of requirements can take many forms, including databases, electronic files, and prototypes.
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.
Requirements changes that affect the architectures of products being acquired can affect many stakeholders.
Tip
Sources of requirements changes may include customers, acquisition project needs and constraints, regulatory changes, or suppliers.
4. Make requirements and change data available to the project.
SP 1.4 Maintain Bidirectional Traceability of Requirements
Maintain bidirectional traceability among requirements and work products.
Tip
The change history should include the rationale for each change, thereby allowing project members and other stakeholders to review why decisions were made if those choices are questioned later.
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
The acquirer maintains an important link between customer and supplier requirements. Understanding the relationship between end-user needs and knowing how those needs are implemented in supplier products or services is critical when performing ATM and AVAL activities.
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 project activities and work products.
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.
Tip
Maintaining traceability across horizontal relationships can greatly reduce problems encountered in the transition to operations and support activities.
Example Work Products
1. Requirements traceability matrix
2. Requirements tracking system
Tip
A traceability matrix can take many forms—for example, a spreadsheet or a database.
Example Supplier Deliverables
1. Comprehensive requirements traceability matrix managed by the supplier as required by the supplier agreement
Tip
Sometimes the customer requirements baseline differs from the contractual baseline that the suppliers are working on. The acquisition project must maintain both baselines and plan to resolve or negotiate inconsistencies.
Subpractices
1. Maintain requirements traceability to ensure that the source of lower level (i.e., derived) requirements is documented.
Traceability from customer to contractual requirements is maintained by the acquirer. Traceability from contractual requirements to derived or additional requirements is maintained by the supplier.
2. Maintain requirements traceability from a requirement to its derived requirements and allocation to work products.
Requirements changes that affect the architectures of products being acquired can affect many stakeholders.
Hint
When a requirement changes, use the traceability matrix to evaluate how that change will affect supplier deliverables and customer needs.
3. Generate a requirements traceability matrix.
A comprehensive traceability matrix, tracing from customer requirements to contractual requirements is maintained by the acquirer. A comprehensive traceability matrix, tracing from contractual requirements to lower level requirements is maintained by the supplier.
SP 1.5 Ensure Alignment Between Project Work and Requirements
Ensure that project plans and work products remain aligned with requirements.
This specific practice finds inconsistencies between requirements and project plans and work products and initiates corrective actions to resolve them.
Corrective actions taken by the project to resolve inconsistencies can also result in changes to project plans and supplier agreements.
Tip
Especially for large projects, product components are developed in parallel, sometimes by multiple suppliers. In such an environment, it is challenging to keep all work products fully consistent with changes to the requirements.
1. Documentation of inconsistencies between requirements and project plans and work products, including sources and conditions
2. Corrective actions
Hint
Make sure acquisition planning documents, such as systems engineering plans and operational test and evaluation plans, are consistent. When one or more suppliers are selected, review supplier plans to ensure that they are consistent with acquisition planning documents.
Subpractices
1. Review project 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.
Tip
A traceability matrix can help with this review of project plans, activities, and work products.