Requirements Management (REQM) Category: Engineering
Notes:
·
The contents of this web page were extracted from
the following document: Capability Maturity Model® Integration
(CMMISM), Version 1.1, Continuous Representation,
CMU/SEI-2002-TR-011, March 2002 (CMMI-SE/SW/IPPD/SS). Copyright 2002 by
Carnegie Mellon University. NO WARRANTY.
·
Ignore the identifiers
in square brackets that appear at the end of paragraphs.
·
The formatting may not
be the same as in the printed CMMI document. The web page is best viewed in
Internet Explorer.
·
In the CMMI, a subset is known as a "Process
Area (PA)" and a requirement is known as a "Practice". The
specific practices are referred to as SPs and the generic practices are
referred to as GPs.
·
This web page contains the text for SPs and GPs as
it appears in Chapter 7 of the CMMI document, in the section corresponding to
the process area named in the heading of this page. This web page does not
include the detailed description of the GPs that appears in a separate chapter
of the CMMI document; the detailed
description of the GPs is available in a separate web
page. (Note: Using the hyperlink provided here will open that web page in a
separate window.)
Purpose The purpose of Requirements Management is to manage the
requirements of the project's products and product components and to identify
inconsistencies between those requirements and the project's plans and work
products. [PA146]
Introductory Notes Requirements management processes manage all requirements received or generated by the project, including both technical and nontechnical requirements as well as those requirements levied on the project by the organization. In particular, if the Requirements Development process area is implemented, its processes will generate product and product-component requirements that will also be managed by the requirements management processes. When the Requirements Management, Requirements Development, and Technical Solution process areas are all implemented, their associated processes may be closely tied and be performed concurrently. [PA146.N101]
The project takes appropriate steps to ensure that the agreed-upon 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, the requirements are reviewed with the requirements provider to resolve issues and prevent misunderstanding before the requirements are incorporated into the project’s plans. Once the requirements provider and the requirements receiver reach an agreement, commitment to the requirements is obtained from the project participants. The project manages changes to the requirements as they evolve and identifies any inconsistencies that occur among the plans, work products, and requirements. [PA146.N102]
Part of the management of requirements is to document
requirements changes and rationale and maintain bidirectional traceability
between source requirements and all product and product-component requirements. [PA146.N103]
Refer to the Requirements Development process area for more information
regarding transforming stakeholder needs into product requirements and deciding
how to allocate or distribute requirements among the product components.
[PA146.R101]
Refer to the Technical Solution process area for more information about
transforming requirements into technical solutions.
[PA146.R102]
Refer to the Project Planning process area for more information about how
project plans reflect requirements and need to be revised as requirements
change. [PA146.R103]
Refer to the Configuration Management process area for more information
about baselines and controlling changes to configuration documentation for
requirements. [PA146.R104]
Refer to the Project Monitoring and Control process area for more
information about tracking and controlling the activities and work products
that are based on the requirements and taking appropriate corrective action.
[PA146.R105]
Refer to the Risk Management process area for more information about
identifying and handling risks associated with requirements.
[PA146.R106]
Specific Goals
SG 1 Manage
Requirements [PA146.IG101]
Requirements are managed and inconsistencies with project plans and work products are identified.
Generic Goals
GG 1 Achieve
Specific Goals [CL102.GL101]
The process supports and enables achievement of the specific goals of the process area by transforming identifiable input work products to produce identifiable output work products.
GG 2 Institutionalize
a Managed Process [CL103.GL101]
The process is institutionalized as a managed process.
GG 3 Institutionalize
a Defined Process [CL104.GL101]
The process is institutionalized as a defined process.
GG 4 Institutionalize
a Quantitatively Managed Process
[CL105.GL101]
The process is institutionalized as a quantitatively managed process.
GG 5 Institutionalize
an Optimizing Process [CL106.GL101]
The process is institutionalized as an optimizing process.
Practice-to-Goal Relationship Table
SG 1 Manage Requirements
[PA146.IG101]
SP 1.1-1 Obtain an Understanding of Requirements
SP 1.2-2 Obtain Commitment to Requirements
SP 1.3-1 Manage Requirements Changes
SP 1.4-2 Maintain Bidirectional Traceability of Requirements
SP 1.5-1 Identify Inconsistencies between Project Work and Requirements
GG 1 Achieve Specific Goals [CL102.GL101]
GP 1.1 Perform Base Practices
GG 2 Institutionalize a Managed Process [CL103.GL101]
GP 2.1 Establish an Organizational Policy
GP 2.2 Plan the Process
GP 2.3 Provide Resources
GP 2.4 Assign Responsibility
GP 2.5 Train People
GP 2.6 Manage Configurations
GP 2.7 Identify and Involve Relevant Stakeholders
GP 2.8 Monitor and Control the Process
GP 2.9 Objectively Evaluate Adherence
GP 2.10 Review Status with Higher Level Management
GG 3 Institutionalize a Defined Process [CL104.GL101]
GP 3.1 Establish a Defined Process
GP 3.2 Collect Improvement Information
GG 4 Institutionalize a Quantitatively Managed Process [CL105.GL101]
GP 4.1 Establish Quantitative Objectives for the Process
GP 4.2 Stabilize Subprocess Performance
GG 5 Institutionalize an Optimizing Process [CL106.GL101]
GP 5.1 Ensure Continuous Process Improvement
GP 5.2 Correct Root Causes of Problems
Specific Practices by Goal
SG 1 Manage Requirements
Requirements are managed and inconsistencies with
project plans and work products are identified.
[PA146.IG101]
The project maintains a current and approved set of
requirements over the life of the project by doing the following: [PA146.IG101.N101]
· Managing all changes to the requirements
· Maintaining the relationships between the requirements, the project plans, and the work products
· Identifying inconsistencies between the requirements, the project plans, and the work products
· Taking corrective action
Refer to the Technical Solution process area for more information about
determining the feasibility of the requirements.
[PA146.IG101.N101.R101]
Refer to the Requirements Development process area for more information
about ensuring that the requirements reflect the needs and expectations of the
customer. [PA146.IG101.N101.R102]
Refer to the Project Monitoring and Control process area for more
information about taking corrective action.
[PA146.IG101.N101.R103]
For Software Engineering
The requirements may be a subset of the overall product requirements, or they may constitute the entire product requirements. [PA146.IG101.AMP101]
For Systems Engineering
Each level of product-component design (e.g., segment, subsystem) receives the requirements from the higher level. [PA146.IG101.AMP102]
SP 1.1-1 Obtain an Understanding of Requirements
Develop
an understanding with the requirements providers on the meaning of the
requirements. [PA146.IG101.SP101]
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. The receiving activities conduct
analyses of the requirements with the requirements provider to ensure that a
compatible, shared understanding is reached on the meaning of the requirements.
The result of this analysis and dialog is an agreed-to set of requirements. [PA146.IG101.SP101.N101]
Typical Work Products
1. Lists of criteria for
distinguishing appropriate requirements providers
[PA146.IG101.SP101.W101]
2. Criteria for evaluation and
acceptance of requirements [PA146.IG101.SP101.W102]
3. Results of analyses against
criteria [PA146.IG101.SP101.W103]
4. An agreed-to set of
requirements [PA146.IG101.SP101.W104]
Subpractices
1. Establish criteria for distinguishing
appropriate requirements providers. [PA146.IG101.SP101.SubP101]
2. Establish objective criteria for the
acceptance of requirements. [PA146.IG101.SP101.SubP102]
Lack of acceptance criteria often
results in inadequate verification, costly rework, or customer rejection. [PA146.IG101.SP101.SubP102.N102]
Examples
of acceptance criteria include the following:
[PA146.IG101.SP101.SubP102.N101]
· Clearly and properly stated
· Complete
· Consistent with each other
· Uniquely identified
· Appropriate to implement
· Verifiable (testable)
· Traceable
3. Analyze requirements to ensure that the established
criteria are met. [PA146.IG101.SP101.SubP103]
4. Reach an understanding of the requirements
with the requirements provider so the project participants can commit to them. [PA146.IG101.SP101.SubP104]
SP 1.2-2 Obtain Commitment to Requirements
Obtain
commitment to the requirements from the project participants. [PA146.IG101.SP102]
Refer to the Project Monitoring and Control process area for more
information about monitoring the commitments made.
[PA146.IG101.SP102.R101]
For Integrated Product and Process Development
When integrated teams are formed, the project participants are the integrated teams and their members. Commitment to the requirement for interacting with other integrated teams is as important for each integrated team as its commitments to product and other project requirements. [PA146.IG101.SP102.AMP101]
Whereas the previous specific practice dealt with
reaching an understanding with the requirements providers, this specific
practice deals with agreements and commitments among those who have to carry
out the activities necessary to implement the requirements. Requirements evolve
throughout the project, especially as described by the specific practices of
the Requirements Development process area and the Technical Solution process area.
As the requirements evolve, this specific practice ensures that project
participants commit to the current, approved requirements and the resulting
changes in project plans, activities, and work products. [PA146.IG101.SP102.N101]
Typical Work Products
1. Requirements impact
assessments [PA146.IG101.SP102.W101]
2. Documented commitments to
requirements and requirements changes [PA146.IG101.SP102.W102]
Subpractices
1. Assess the impact of requirements on
existing commitments. [PA146.IG101.SP102.SubP101]
The impact on the project
participants should be evaluated when the requirements change or at the start
of a new requirement.
[PA146.IG101.SP102.SubP101.N101]
2. Negotiate and record commitments. [PA146.IG101.SP102.SubP102]
Changes to existing commitments
should be negotiated before project participants commit to the requirement or
requirement change.
[PA146.IG101.SP102.SubP102.N101]
SP 1.3-1 Manage Requirements Changes
Manage
changes to the requirements as they evolve during the project. [PA146.IG101.SP103]
Refer to the Configuration Management process area for more information
about maintaining and controlling the requirements baseline and on making the
requirements and change data available to the project.
[PA146.IG101.SP103.R101]
During the project, requirements change for a variety of
reasons. As needs change and as work proceeds, additional requirements are
derived and changes may have to be made to the existing requirements. It is
essential to manage these additions and changes efficiently and effectively. To
effectively analyze the impact of the changes, it is necessary that the source
of each requirement is known and the rationale for any change is documented.
The project manager may, however, want to track appropriate measures of
requirements volatility to judge whether new or revised controls are necessary. [PA146.IG101.SP103.N101]
Typical Work Products
1. Requirements status [PA146.IG101.SP103.W101]
2. Requirements database [PA146.IG101.SP103.W102]
3. Requirements decision
database [PA146.IG101.SP103.W103]
Subpractices
1. Capture all requirements and requirements
changes that are given to or generated by the project.
[PA146.IG101.SP103.SubP101]
2. Maintain the requirements change history
with the rationale for the changes. [PA146.IG101.SP103.SubP102]
Maintaining the change history
helps track requirements volatility. [PA146.IG101.SP103.SubP102.N101]
3. Evaluate the impact of requirement changes
from the standpoint of relevant stakeholders.
[PA146.IG101.SP103.SubP103]
4. Make the requirements and change data
available to the project. [PA146.IG101.SP103.SubP104]
SP 1.4-2 Maintain Bidirectional Traceability of Requirements
Maintain
bidirectional traceability among the requirements and the project plans and
work products.
[PA146.IG101.SP104]
The intent of this specific practice is to maintain the
bidirectional traceability of requirements for each level of product
decomposition. When the requirements are managed well, traceability can be
established from the source requirement to its lower level requirements and
from the lower level requirements back to their source. Such bidirectional
traceability helps determine that all source requirements have been completely
addressed and that all lower level requirements can be traced to a valid
source. Requirements traceability can also cover the relationships to other
entities such as intermediate and final work products, changes in design
documentation, test plans, and work tasks. The traceability should cover both
the horizontal and vertical relationships, such as across interfaces.
Traceability is particularly needed in conducting the impact assessment of
requirements changes on the project plans, activities, and work products. [PA146.IG101.SP104.N101]
Typical Work Products
1. Requirements traceability
matrix [PA146.IG101.SP104.W101]
2. Requirements tracking
system [PA146.IG101.SP104.W102]
Subpractices
1. Maintain requirements traceability to ensure
that the source of lower level (derived) requirements is documented. [PA146.IG101.SP104.SubP101]
2. Maintain requirements traceability from a
requirement to its derived requirements as well as to its allocation of
functions, objects, people, processes, and work products. [PA146.IG101.SP104.SubP102]
3. Maintain horizontal traceability from
function to function and across interfaces.
[PA146.IG101.SP104.SubP103]
4. Generate the requirements traceability
matrix. [PA146.IG101.SP104.SubP104]
SP 1.5-1 Identify Inconsistencies between Project Work and Requirements
Identify
inconsistencies between the project plans and work products and the
requirements. [PA146.IG101.SP105]
Refer to the Project Monitoring and Control process area for more
information about monitoring and controlling the project plans and work
products for consistency with requirements and taking corrective actions when
necessary. [PA146.IG101.SP105.R101]
This specific practice finds the inconsistencies between
the requirements and the project plans and work products and initiates the
corrective action to fix them.
[PA146.IG101.SP105.N101]
Typical Work Products
1. Documentation of
inconsistencies including sources, conditions, and rationale [PA146.IG101.SP105.W101]
2. Corrective actions [PA146.IG101.SP105.W102]
Subpractices
1. Review the project's plans, activities, and
work products for consistency with the requirements and the changes made to
them. [PA146.IG101.SP105.SubP101]
2. Identify the source of the inconsistency and
the rationale. [PA146.IG101.SP105.SubP102]
3. Identify changes that need to be made to the
plans and work products resulting from changes to the requirements baseline. [PA146.IG101.SP105.SubP103]
4. Initiate corrective actions. [PA146.IG101.SP105.SubP104]
Generic Practices by Goal
(Note: The detailed description of the GPs is available in a separate web page. Using the hyperlink provided here will open that web page in a separate window. However, the GP elaborations pertinent to the process area of this web page are available below.)
GG 1 Achieve Specific Goals
The process supports and enables achievement of the specific goals of the process area by transforming identifiable input work products to produce identifiable output work products.
Perform
the base practices of the requirements management process to develop work
products and provide services to achieve the specific goals of the process
area. [GP102]
GG 2 Institutionalize a Managed Process
The process is institutionalized as a managed process.
GP 2.1 Establish an Organizational Policy
Establish
and maintain an organizational policy for planning and performing the
requirements management process. [GP103]
Elaboration:
This policy establishes organizational expectations for
managing requirements and identifying inconsistencies between the requirements
and the project plans and work products.
[PA146.EL101]
Establish
and maintain the plan for performing the requirements management process. [GP104]
Elaboration:
Typically, this plan for performing the requirements
management process is a part of the project plan as described in the Project
Planning process area. [PA146.EL102]
Provide
adequate resources for performing the requirements management process,
developing the work products, and providing the services of the process. [GP105]
Elaboration:
Examples of
resources provided include the following tools: [PA146.EL113]
· Requirements tracking tools
· Traceability tools
Assign
responsibility and authority for performing the process, developing the work
products, and providing the services of the requirements management process. [GP106]
Train
the people performing or supporting the requirements management process as
needed. [GP107]
Elaboration:
Examples of
training topics include the following: [PA146.EL105]
· Application domain
· Requirements definition, analysis, review, and management
· Requirements management tools
· Configuration management
· Negotiation and conflict resolution
Place
designated work products of the requirements management process under
appropriate levels of configuration management.
[GP109]
Elaboration:
Examples of
work products placed under configuration management include the following: [PA146.EL108]
· Requirements
· Requirements traceability matrix
GP 2.7 Identify and Involve Relevant Stakeholders
Identify
and involve the relevant stakeholders of the requirements management process as
planned. [GP124]
Elaboration:
Select relevant stakeholders from customers, end users,
developers, producers, testers, suppliers, marketers, maintainers, disposal
personnel, and others who may be affected by, or may affect, the product as
well as the process. [PA146.EL115]
Examples of
activities for stakeholder involvement include: [PA146.EL116]
· Resolving issues on the understanding of the requirements
· Assessing the impact of requirements changes
· Communicating the bidirectional traceability
· Identifying inconsistencies among project plans, work products, and requirements
GP 2.8 Monitor and Control the Process
Monitor
and control the requirements management process against the plan for performing
the process and take appropriate corrective action.
[GP110]
Elaboration:
Examples of
measures used in monitoring and controlling include the following: [PA146.EL111]
· Requirements volatility (percentage of requirements changed)
GP 2.9 Objectively Evaluate Adherence
Objectively
evaluate adherence of the requirements management process against its process
description, standards, and procedures, and address noncompliance. [GP113]
Elaboration:
Examples of
activities reviewed include the following: [PA146.EL112]
· Managing requirements
· Identifying inconsistencies among project plans, work products, and requirements
Examples of
work products reviewed include the following: [PA146.EL114]
· Requirements
· Requirements traceability matrix
GP 2.10 Review Status with Higher Level Management
Review
the activities, status, and results of the requirements management process with
higher level management and resolve issues.
[GP112]
Elaboration:
Proposed changes to commitments to be made external to
the organization are reviewed with higher level management to ensure that all
commitments can be accomplished. [PA146.EL117]
GG 3 Institutionalize a Defined Process
The process is institutionalized as a defined process.
GP 3.1 Establish a Defined Process
Establish
and maintain the description of a defined requirements management process. [GP114]
GP 3.2 Collect Improvement Information
Collect
work products, measures, measurement results, and improvement information
derived from planning and performing the requirements management process to
support the future use and improvement of the organization’s processes and
process assets. [GP117]
GG 4 Institutionalize a Quantitatively Managed Process
The process is institutionalized as a quantitatively managed process.
GP 4.1 Establish Quantitative Objectives for the Process
Establish
and maintain quantitative objectives for the requirements management process
that address quality and process performance based on customer needs and
business objectives. [GP118]
GP 4.2 Stabilize Subprocess Performance
Stabilize
the performance of one or more subprocesses to determine the ability of the
requirements management process to achieve the established quantitative quality
and process-performance objectives. [GP119]
GG 5 Institutionalize an Optimizing Process
The process is institutionalized as an optimizing process.
GP 5.1 Ensure Continuous Process Improvement
Ensure
continuous improvement of the requirements management process in fulfilling the
relevant business objectives of the organization.
[GP125]
GP 5.2 Correct Root Causes of Problems
Identify
and correct the root causes of defects and other problems in the requirements
management process. [GP121]