|Requirements Management (REQM)||
|The CMMi easy button concept and disclaimer
Disclaimer: The opinions expressed here are the authors
and do not express a position on the subject from the
Software Engineering Institute (SEI) or any organization
or SEI Partner affiliated with the SEI.
The concept of The CMMi easy button is to be able to
jump start SQA software professionals in establishing an
effective Software process Improvement (SPI) framework that is based on CMMi theories and best practices.
CMMI, CMM, and Capability Maturity Model are registered
in the U.S. Patent and Trademark Office.
CMM Integration, SCAMPI, and IDEAL are service marks of
Carnegie Mellon University.
|Causal Analysis and Resolution (CAR)||Configuration Management (CM)||Decision Analysis and Resolution (DAR)|
|Integrated Project Management +IPPD (IPM+IPPD)||Measurement and Analysis (MA)||Organizational Innovation and Deployment (OID)|
|Organizational Process Definition +IPPD (OPD+IPPD)||Organizational Process Focus (OPF)||Organizational Process Performance (OPP)|
|Organizational Training (OT)||Product Integration (PI)||Project Monitoring and Control (PMC)|
|Project Planning (PP)||Process and Product Quality Assurance (PPQA)||Quantitative Project Management (QPM)|
|Requirements Development (RD)||Requirements Management (REQM)||Risk Management (RSKM)|
|Supplier Agreement Management (SAM)||Technical Solution (TS)||Validation (VAL)|
|Requirements Management (REQM) purpose and introductory notes|
|Specific Goals and Practices|
|Specific Goal 1 (SG 1) Manage Requirements (SP 1.*)|
|SP 1.1 Obtain an Understanding of Requirements||SP 1.2 Obtain Commitment to Requirements||SP 1.3 Manage Requirements Changes||SP 1.4 Maintain Bidirectional Traceability of Requirements|
|SP 1.5 Identify Inconsistencies Between Project Work and Requirements||.||.||.|
|Generic Goals and Practices|
|Generic Goal 1 (GG 1) Achieve Specific Goals, Generic Practices (GP 1.*)|
|GP 1.1 Perform Specific Practices||.||.||.|
|Generic Goal 2 (GG 2) Institutionalize a Managed Process, Generic Practices (GP 2.*)|
|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||.||.|
|Generic Goal 3 (GG 3) Institutionalize a Defined Process, Generic Practices (GP 3.*)|
|GP 3.1 Establish a Defined Process||GP 3.2 Collect Improvement Information||.||.|
|Generic Goal 4 (GG 4) Institutionalize a Quantitatively Managed Process, Generic Practices (GP 4.*)|
|GP 4.1 Establish Quantitative Objectives for the Process||GP 4.2 Stabilize Subprocess Performance||.||.|
|Generic Goal 5 (GG 5) Institutionalize an Optimizing Process, Generic Practices (GP 5.*)|
|GP 5.1 Ensure Continuous Process Improvement||GP 5.2 Correct Root Causes of Problems||.||.|
Requirements Management (REQM) is about managing versions of Requirements as well as the relationship between the requirements and the project deliverables. The relationship between the requirements and other project deliverables can be seen using a Traceability Matrix that correlates any two baselined documents, for example cross referencing a given requirement to a design section or cross referencing a requirement with a test case that verifies the presence of the given requirement.
Requirements Management (REQM)
An Engineering Process Area at Maturity Level 2
The purpose of Requirements Management (REQM) 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.
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, 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.
Part of the management of requirements is to document requirements changes and rationale and to maintain bidirectional traceability between source requirements and all product and product component requirements (See the definition of “bidirectional traceability” in the glossary.)
All development projects have requirements. In the case of a project that is focused on maintenance activities, the changes to the product or product components 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 accordingly.
Related Process Areas.
Refer to the Requirements Development process area for more information about transforming stakeholder needs into product requirements and deciding how to allocate or distribute requirements among the product components.
Refer to the Technical Solution process area for more information about transforming requirements into technical solutions.
Refer to the Project Planning process area for more information about how project plans reflect requirements and need to be revised as requirements change.
Refer to the Configuration Management process area for more information about baselines and controlling changes to configuration documentation for requirements.
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.
Refer to the Risk Management process area for more information about identifying and handling risks associated with requirements.
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:
Refer to the Requirements Development process area for more information about ensuring that the requirements reflect the needs and expectations of the customer.
Refer to the Project Monitoring and Control process area for more information about taking corrective action.
SP 1.1 Obtain an Understanding of 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. 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.
Typical Work Products
Subpractice 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.
Examples of evaluation and acceptance criteria include the following:
Subpractice 4: Reach an understanding of the requirements with the requirements provider so that the project participants can commit to them.
SP 1.2 Obtain Commitment to Requirements
Obtain commitment to the requirements from the project participants.
Refer to the Project Monitoring and Control process area for more information about monitoring the commitments made.
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.
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.
Typical Work Products
The impact on the project participants should be evaluated when the requirements change or at the start of a new requirement.
Subpractice 2:Negotiate and record commitments.
Changes to existing commitments should be negotiated before project participants commit to the requirement or requirement change.
SP 1.3 Manage Requirements Changes
Manage changes to the 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 on making the requirements and change data available to the project.
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.
Typical Work Products
Subpractice 2: Maintain the requirements change history with the rationale for the changes.
Maintaining the change history helps track requirements volatility.
Subpractice 3: Evaluate the impact of requirement changes from the standpoint of relevant stakeholders.
Subpractice 4: Make the requirements and change data available to the project.
SP 1.4 Maintain Bidirectional Traceability of Requirements
Maintain bidirectional traceability among the requirements and work products.
The intent of this specific practice is to maintain the bidirectional traceability of requirements for each level of product decomposition. (See the definition of “bidirectional traceability” in the glossary.) 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, and test plans. The 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 the project's activities and work products.
Typical Work Products
Subpractice 2: Maintain requirements traceability from a requirement to its derived requirements and allocation to functions, interfaces, objects, people, processes, and work products.
Subpractice 3: Generate the requirements traceability matrix.
SP 1.5 Identify Inconsistencies Between Project Work and Requirements
Identify inconsistencies between the project plans and work products and the requirements.
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.
This specific practice finds the inconsistencies between the requirements and the project plans and work products and initiates the corrective action to fix them.
Typical Work Products
Subpractice: 2 Identify the source of the inconsistency and the rationale.
Subpractice: 3 Identify changes that need to be made to the plans and work products resulting from changes to the requirements baseline.
Subpractice: 4 Initiate corrective actions.
Generic Practices by Goal
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.
GP 1.1 Perform Specific Practices
Perform the specific practices of the requirements management process to develop work products and provide services to achieve the specific goals of the process area.
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.
This policy establishes organizational expectations for managing requirements and identifying inconsistencies between the requirements and the project plans and work products.
GP 2.2 Plan the Process
Establish and maintain the plan for performing the requirements management process.
This plan for performing the requirements management process can be part of (or referenced by) the project plan as described in the Project Planning process area.
GP 2.3 Provide Resources
Provide adequate resources for performing the requirements management process, developing the work products, and providing the services of the process.
Examples of resources provided include the following tools:
Assign responsibility and authority for performing the process, developing the work products, and providing the services of the requirements management process.
GP 2.5 Train People
Train the people performing or supporting the requirements management process as needed.
Examples of training topics include the following:
Place designated work products of the requirements management process under appropriate levels of control.
Examples of work products placed under control include the following:
Identify and involve the relevant stakeholders of the requirements management process as planned.
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.
Examples of activities for stakeholder involvement include the following:
Monitor and control the requirements management process against the plan for performing the process and take appropriate corrective action.
Examples of measures and work products used in monitoring and controlling include the following:
Objectively evaluate adherence of the requirements management process against its process description, standards, and procedures, and address noncompliance.
Examples of activities reviewed include the following:
Review the activities, status, and results of the requirements management process with higher level management and resolve issues.
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.
GG 3 Institutionalize a Defined Process
The process is institutionalized as a defined process.
This generic goal's appearance here reflects its location in the continuous representation.
GP 3.1 Establish a Defined Process
Establish and maintain the description of a defined requirements management process.
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.
Examples of work products, measures, measurement results, and improvement information include the following:
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, which address quality and process performance, based on customer needs and business objectives.
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.
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.
GP 5.2 Correct Root Causes of Problems
Identify and correct the root causes of defects and other problems in the requirements management process.
Software-Quality-Assurance.org is an independent Web Site that presents information about CMMi and Software Quality Assurance.
No guarantee (or claim) is made regarding the accuracy of this information. Any questions or comments should be sent to:-