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 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
For Software Engineering :
The requirements may be a subset of the overall product requirements, or they may constitute the entire product requirements.
For Systems Engineering:
Each level of product-component design (e.g., segment, subsystem) receives the requirements from the higher level.
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
1. Lists of criteria for distinguishing appropriate requirements providers [PA146.IG101.SP101.W101]
2. Criteria for evaluation and acceptance of requirements
3. Results of analyses against criteria
4. An agreed-to set of requirements
Subpractices
1. Establish criteria for distinguishing appropriate requirements providers.
2. Establish objective criteria for the acceptance of requirements.
Lack of acceptance criteria often results in inadequate verification, costly rework, or customer rejection. Examples of acceptance criteria include the following:
· 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.
4. Reach an understanding of the requirements with the requirements provider so the project participants can commit to them.
SP 1.2 Obtain Commitment to Requirements
Obtain commitment to the requirements from the project participants.
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.
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
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 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 the requirement or requirement change.
SP 1.3 Manage Requirements Changes
Manage changes to the requirements as they evolve during 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
1. Requirements status
2. Requirements database
3. Requirements decision database
Subpractices
1. Capture all requirements and requirements changes that are given to or generated by the project.
2. Maintain the requirements change history with the rationale for the changes. Maintaining the change history helps track requirements volatility.
3. Evaluate the impact of requirement changes from the standpoint of relevant stakeholders.
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 the project plans and work products.
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.
Typical Work Products
1. Requirements traceability matrix
2. Requirements tracking system
Subpractices
1. Maintain requirements traceability to ensure that the source of lower level (derived) requirements is documented.
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.
3. Maintain horizontal traceability from function to function and across interfaces.
4. 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.
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
1. Documentation of inconsistencies including sources, conditions, and rationale
2. Corrective actions
Subpractices
1. Review the project's plans, activities, and work products for consistency with the requirements and the changes made to them.
2. Identify the source of the inconsistency and the rationale.
3. Identify changes that need to be made to the plans and work products resulting from changes to the requirements baseline.
4. Initiate corrective actions.
GG 2 Institutionalize a Managed Process
The process is institutionalized as a managed process.
Commitment to Perform
GP 2.1 (CO 1) Establish an Organizational Policy
Establish and maintain an organizational policy for planning and performing the requirements management process.
Elaboration:
This policy establishes organizational expectations for managing requirements and identifying inconsistencies between the requirements and the project plans and work products.
Ability to Perform
GP 2.2 (AB 1) Plan the Process
Establish and maintain the plan for performing the requirements management process.
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.
GP 2.3 (AB 2) Provide Resources
Provide adequate resources for performing the requirements management process, developing the work products, and providing the services of the process.
Elaboration:
Examples of resources provided include the following tools:
· Requirements tracking tools
· Traceability tools
GP 2.4 (AB 3) Assign Responsibility
Assign responsibility and authority for performing the process, developing the work products, and providing the services of the requirements management process.
GP 2.5 (AB 4) Train People
Train the people performing or supporting the requirements
management process as needed.
Elaboration:
Examples of training topics include the following:
· Application domain
· Requirements definition, analysis, review, and management
· Requirements management tools
· Configuration management
· Negotiation and conflict resolution
Directing Implementation
GP 2.6 (DI 1) Manage Configurations
Place designated work products of the requirements management process under appropriate levels of configuration management.
Elaboration:
Examples of work products placed under configuration management include the following:
· Requirements
· Requirements traceability matrix
GP 2.7 (DI 2) Identify and Involve Relevant Stakeholders
Identify and involve the relevant stakeholders of the requirements management process as planned.
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.
Examples of activities for stakeholder involvement include:
· 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 (DI 3) 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:
· Requirements volatility (percentage of requirements changed)
Verifying Implementation
GP 2.9 (VE 1) Objectively Evaluate Adherence
Objectively evaluate adherence of the requirements management process against its process description, standards, and procedures, and address noncompliance.
Elaboration:
Examples of activities reviewed include the following:
· Managing requirements
· Identifying inconsistencies among project plans, work products, and requirements
Examples of work products reviewed include the following:
· Requirements
· Requirements traceability matrix
GP 2.10 (VE 2) Review Status with Higher Level Management
Review the activities, status, and results of the requirements management process with higher level management and resolve issues.
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. (The following goal is not required and its practices are not expected for a maturity level 2 rating, but are required for a maturity level 3 rating and above.)
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.
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.
