CMMI - Engineering

Requirements Management

Requirements Development

Technical Solution

Product Integration

Verification

Validation

REQM: Requirements Management

Purpose

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 importance of effective requirements management cannot be understated; indeed, industry analyst reports have clear findings that projects succeed with it and fail without it. When asked by Standish Group why projects succeed, 50 percent of respondents attributed successful projects to requirements management."

CMMI and Integrated Requirements, Change and Configuration Management, Andy Gurd and Dominic Tavassoli, Version 1, 22 December 2005, p. 9

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.

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.

Part of the management of requirements is to document requirements changes and rationale and maintain bi-directional traceability between source requirements and all product and product-component requirements.

Specific Goals

Goal	Supporting Practices	Sub Practices
REQM-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: 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	Obtain an Understanding of Requirements	[SP]
	Obtain Commitment to Requirements	[SP]
	Manage Requirements Changes	[SP]
	Maintain Bi-directional Traceability of Requirements	[SP]
	Identify Inconsistencies between Project Work and Requirements	[SP]

Institutionalizing the Processes

Basic (Managed) Goals

Advanced Goals

Establish Policy: This policy establishes organizational expectations for managing requirements and identifying inconsistencies between the requirements and the project plans and work products.
Plan the Process: Typically, this plan for performing the requirements management process is a part of the project plan as described in the Project Planning process area.
Provide Resources: Examples of resources provided include:
- Requirements tracking tools
- Traceability tools
Assign Responsibility: Assign responsibility and authority for performing the process, developing the work products, and providing the services of the requirements management process.
Train People: Examples of training topics include:
- Application domain
- Requirements definition, analysis, review, and management
- Requirements management tools
- Configuration management
- Negotiation and conflict resolution
Manage Configurations: Examples of work products placed under configuration management include :
- Requirements
- Requirements traceability matrix
Identify and Involve Relevant Stakeholders: 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
Monitor and Control the Process: Examples of measures used in monitoring and controlling include - Requirements volatility (percentage of requirements changed)
Objectively Evaluate Adherence: Examples of activities reviewed include:
- Managing requirements
- Identifying inconsistencies among project plans, work products, and requirements
Examples of work products reviewed include:
- Requirements
- Requirements traceability matrix
Review Status with Higher Level Management: 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.

Defined

Establish Defined Process:Establish and maintain the description of a defined requirements management process.
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.

Quantitatively Managed

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.
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 processperformance objectives.

Optimizing

Ensure Continuous Process Improvement: Ensure continuous improvement of the requirements management process in fulfilling the relevant business objectives of the organization.
Correct Root Causes of Problems: Identify and correct the root causes of defects and other problems in the requirements management process.

REQD: Requirements Development

Purpose

To produce and analyze customer, product, and product-component requirements.

This process area describes three types of requirements: customer requirements, product requirements, and product-component requirements. Taken together, these requirements address the needs of relevant stakeholders, including those pertinent to various product lifecycle phases (e.g., acceptance testing criteria) and product attributes (e.g., safety, reliability, maintainability). Requirements also address constraints caused by the selection of design solutions (e.g., integration of commercial off-the-shelf products).

Requirements are the basis for design. The development of requirements includes:

Elicitation, analysis, validation, and communication of customer needs, expectations, and constraints to obtain customer requirements that constitute an understanding of what will satisfy stakeholders
Collection and coordination of stakeholder needs
Development of the life-cycle requirements of the product
Establishment of the customer requirements
Establishment of initial product and product-component requirements consistent with customer requirements

This process area addresses all customer requirements rather than only product-level requirements because the customer may also provide specific design requirements.

Customer requirements are further refined into product and product component requirements. In addition to customer requirements, product and product-component requirements are derived from the selected design solutions.

Requirements are identified and refined throughout the phases of the product life cycle. Design decisions, subsequent corrective actions, and feedback during each phase of the product’s life cycle are analyzed for impact on derived and allocated requirements.

The Requirements Development process area includes three specific goals. The Develop Customer Requirements specific goal addresses defining a set of customer requirements to use in the development of product requirements. The Develop Product Requirements specific goal addresses defining a set of product or product-component requirements to use in the design of products and product components. The Analyze and Validate Requirements specific goal addresses the necessary analysis of customer, product, and product-component requirements to define, derive, and understand the requirements. The specific practices of the third specific goal are intended to assist the specific practices in the first two specific goals. The processes associated with the Requirements Development process area and those associated with the Technical Solution process area may interact recursively with one another.

Analyses are used to understand, define, and select the requirements at all levels from competing alternatives. These analyses include:

Analysis of needs and requirements for each product life-cycle phase, including needs of relevant stakeholders, the operational environment, and factors that reflect overall customer and end-user expectations and satisfaction, such as safety, security, and affordability
Development of an operational concept
Definition of the required functionality

The definition of functionality, also referred to as “functional analysis,” is not the same as structured analysis in software development and does not presume a functionally oriented software design. In object-oriented software design, it relates to defining the services. The definition of functions, their logical groupings, and their association with requirements is referred to as a “functional architecture.”

Analyses occur recursively at successively more detailed layers of a product’s architecture until sufficient detail is available to enable detailed design, acquisition, and testing of the product to proceed. As a result of the analysis of requirements and the operational concept (including functionality, support, maintenance, and disposal), the manufacturing or production concept produces more derived requirements, including consideration of:

Constraints of various types
Technological limitations
Cost and cost drivers
Time constraints and schedule drivers
Risks
Consideration of issues implied but not explicitly stated by the customer or end user
Factors introduced by the developer’s unique business considerations, regulations, and laws

A hierarchy of logical entities (functions and sub-functions, object classes and subclasses) is established through iteration with the evolving operational concept. Requirements are refined, derived, and allocated to these logical entities. Requirements and logical entities are allocated to products, product components, people, associated processes, or services.

Involvement of relevant stakeholders in both requirements development and analysis gives them visibility into the evolution of requirements. This activity continually assures them that the requirements are being properly defined.

Specific Goals

Goal	Supporting Practices	Sub Practices
REQD-1: Develop Customer Requirements Stakeholder needs, expectations, constraints, and interfaces are collected and translated into customer requirements. The needs of stakeholders (e.g., customers, end users, suppliers, builders, and testers) are the basis for determining customer requirements. The stakeholder needs, expectations, constraints, interfaces, operational concepts, and product concepts are analyzed, harmonized, refined, and elaborated for translation into a set of customer requirements. Frequently, stakeholder needs, expectations, constraints, and interfaces are poorly identified or conflicting. Since stakeholder needs, expectations, constraints, and limitations should be clearly identified and understood, an iterative process is used throughout the life of the project to accomplish this objective. To facilitate the required interaction, a surrogate for the end user or customer is frequently involved to represent their needs and help resolve conflicts. The customer relations or marketing part of the organization as well as members of the development team from disciplines such as human engineering or support can be used as surrogates. Environmental, legal, and other constraints should be considered when creating and resolving the set of customer requirements.	Collect Stakeholder Needs	[SP]
	Elicit Needs	[SP]
	Develop the Customer Requirements	[SP]
REQD-2: Develop Product Requirements Customer requirements are refined and elaborated to develop product and product-component requirements. Customer requirements are analyzed in conjunction with the development of the operational concept to derive more detailed and precise sets of requirements called “product and product-component requirements.” Product and product-component requirements address the needs associated with each product life-cycle phase. Derived requirements arise from constraints, consideration of issues implied but not explicitly stated in the customer requirements baseline, and factors introduced by the selected architecture, the design, and the developer’s unique business considerations. The requirements are reexamined with each successive, lower level set of requirements and functional architecture, and the preferred product concept is refined. The requirements are allocated to product functions and product components including objects, people, and processes. The traceability of requirements to functions, objects, tests, issues, or other entities is documented. The allocated requirements and functions are the basis for the synthesis of the technical solution. As internal components are developed, additional interfaces are defined and interface requirements established.	Establish Product and Product-Component Requirements	[SP]
	Allocate Product-Component Requirements	[SP]
	Identify Interface Requirements	[SP]
REQD-3: Analyze and Validate Requirements The requirements are analyzed and validated, and a definition of required functionality is developed. The specific practices of the Analyze and Validate Requirements specific goal support the development of the requirements in both the Develop Customer Requirements specific goal and the Develop Product Requirements specific goal. The specific practices associated with this specific goal cover analyzing and validating the requirements with respect to the user’s intended environment. Analyses are performed to determine what impact the intended operational environment will have on the ability to satisfy the stakeholders' needs, expectations, constraints, and interfaces. Considerations such as feasibility, mission needs, cost constraints, potential market size, and acquisition strategy must all be taken into account, depending on the product context. A definition of required functionality is also established. All specified usage modes for the product are considered, and a timeline analysis is generated for timecritical sequencing of functions. The objectives of the analyses are to determine candidate requirements for product concepts that will satisfy stakeholder needs, expectations, and constraints; and then translate these concepts into requirements. In parallel with this activity, the parameters that will be used to evaluate the effectiveness of the product are determined based on customer input and the preliminary product concept. Requirements are validated to increase the probability that the resulting product will perform as intended in the use environment.	Establish Operational Concepts and Scenarios	[SP]
	Establish a Definition of Required Functionality	[SP]
	Analyze Requirements	[SP]
	Analyze Requirements to Achieve Balance	[SP]
	Validate Requirements	[SP]
	Validate Requirements with Comprehensive Methods	[SP]

Institutionalizing the Processes

Basic (Managed) Goals

Advanced Goals

Establish Policy: This policy establishes organizational expectations for collecting stakeholder needs, formulating product and product-component requirements, and analyzing and validating those requirements.
Plan the Process: Typically, this plan for performing the requirements development process is a part of the project plan as described in the Project Planning process area.
Provide Resources: Special expertise in the application domain, methods for eliciting stakeholder needs, and methods and tools for specifying and analyzing customer, product, and product-component requirements may be required. Examples of other resources provided include:
- Requirements specification tools
- Simulators and modeling tools
- Prototyping tools
- Scenario definition and management tools
- Requirements tracking tools
Assign Responsibility: Assign responsibility and authority for performing the process, developing the work products, and providing the services of the requirements development process.
Train People: Examples of training topics include:
- Application domain
- Requirements definition and analysis
- Requirements elicitation
- Requirements specification and modeling
- Requirements tracking
Manage Configurations: Examples of work products placed under configuration management include:
- Customer requirements
- Functional architecture
- Product and product-component requirements
- Interface requirements
Identify and Involve Relevant Stakeholders: 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:
- Reviewing the adequacy of requirements in meeting needs, expectations, constraints, and interfaces
- Establishing operational concepts and scenarios
- Assessing the adequacy of requirements
- Establishing product and product-component requirements
- Assessing product cost, schedule, and risk
Monitor and Control the Process: Examples of measures used in monitoring and controlling include:
- Cost, schedule, and effort expended for rework
- Defect density of requirements specifications
Objectively Evaluate Adherence: Examples of activities reviewed include:
- Collecting stakeholder needs
- Formulating product and product-component requirements
- Analyzing and validating product and product-component requirements
Examples of work products reviewed include:
- Product requirements
- Product-component requirements
- Interface requirements
- Functional architecture
Review Status with Higher Level Management: Review the activities, status, and results of the requirements development process with higher level management and resolve issues.

Defined

Establish Defined Process: Establish and maintain the description of a defined requirements development process.
Collect Improvement Information: Collect work products, measures, measurement results, and improvement information derived from planning and performing the requirements development process to support the future use and improvement of the organization’s processes and process assets.

Quantitatively Managed

Establish Quantitative Objectives for the Process: Establish and maintain quantitative objectives for the requirements development process that address quality and process performance based on customer needs and business objectives.
Stabilize Subprocess Performance: Stabilize the performance of one or more subprocesses to determine the ability of the requirements development process to achieve the established quantitative quality and processperformance objectives.

Optimizing

Ensure Continuous Process Improvement: Ensure continuous improvement of the requirements development process in fulfilling the relevant business objectives of the organization.
Correct Root Causes of Problems: Identify and correct the root causes of defects and other problems in the requirements development process.

TS: Technical Solution

Purpose

To design, develop, and implement solutions to requirements. Solutions, designs, and implementations encompass products, product components, and product-related lifecycle processes either singly or in combinations as appropriate.

The Technical Solution process area is applicable at any level of the product architecture and to every product, product component, product-related life-cycle process, and service. The process area focuses on :

Evaluating and selecting solutions^N that potentially satisfy an appropriate set of allocated requirements
Developing detailed designs for the selected solutions^N
Implementing the designs as a product or product component. Typically, these activities interactively support each other. Some level of design, at times fairly detailed, may be needed to select solutions.

Product-component prototypes may be used as a means of gaining sufficient knowledge to develop a technical data package or a complete set of requirements.

Technical Solution specific practices apply not only to the product and product components but also to services and product-related life-cycle processes. The product-related life-cycle processes are developed in concert with the product or product component. Such development may include selecting and adapting existing processes (including standard processes) for use as well as developing new processes.

Processes associated with the Technical Solution process area receive the product and product-component requirements from the requirements management processes. The requirements management processes place the requirements, which originate in requirements development processes, under appropriate configuration management and maintain their traceability to previous requirements.

For a maintenance or sustainment organization, the requirements in need of maintenance actions or redesign may be driven by user needs or latent defects in the product components. New requirements may arise from changes in the operating environment. Such requirements can be uncovered during verification of the product(s) where actual performance can be compared against the specified performance and unacceptable degradation can be identified. Processes associated with the Technical Solution process area should be used to perform the maintenance or sustainment design efforts.

Specific Goals

Goal	Supporting Practices	Sub Practices
TS-1: Select Product-Component Solutions Product or product-component solutions are selected from alternative solutions. Alternative solutions and their relative merits are considered in advance of selecting a solution. Key requirements, design issues, and constraints are established for use in alternative solution analysis. Architectural features that provide a foundation for product improvement and evolution are considered. Use of commercial off-the-shelf (COTS) product components are considered relative to cost, schedule, performance, and risk. COTS alternatives may be used with or without modification. Sometimes such items may require modifications to aspects such as interfaces or a customization of some of the features to better achieve product requirements. More...	Develop Alternative Solutions and Selection Criteria	[SP]
	Develop Detailed Alternative Solutions and Selection Criteria	[SP]
	Evolve Operational Concepts and Scenarios	[SP]
	Select Product-Component Solutions	[SP]
TS-2: Develop the Design Product or product-component designs are developed. Product or product-component designs must provide the appropriate content not only for implementation, but also for other phases of the product life cycle such as modification, reprocurement, maintenance, sustainment, and installation. The design documentation provides a reference to support mutual understanding of the design by relevant stakeholders and supports future changes to the design both during development and in subsequent phases of the product life cycle. A complete design description is documented in a technical data package that includes a full range of features and parameters including form, fit, function, interface, manufacturing process characteristics, and other parameters. Established organizational or project design standards (e.g., checklists, templates, object frameworks) form the basis for achieving a high degree of definition and completeness in design documentation.	Design the Product or Product Component	[SP]
	Establish a Technical Data Package	[SP]
	Establish Interface Descriptions	[SP]
	Design Interfaces Using Criteria	[SP]
	Perform Make, Buy, or Reuse Analyses	[SP]
TS-3: Implement the Product Design Product components, and associated support documentation, are implemented from their designs. Product components are implemented from the designs established by the specific practices in the Develop the Design specific goal. The implementation usually includes unit testing of the product components before sending them to product integration and development of enduser documentation.	Implement the Design	[SP]
	Develop Product Support Documentation	[SP]

Institutionalizing the Processes

Basic (Managed) Goals

Advanced Goals

Establish Policy: This policy establishes organizational expectations for addressing the iterative cycle in which product-component solutions are selected, product and product-component designs are developed, and the product-component designs are implemented.
Plan the Process: Typically, this plan for performing the technical solution process is a part of the project plan as described in the Project Planning process area.
Provide Resources: Special facilities may be required for developing, designing, and implementing solutions to requirements. When necessary, the facilities required for the activities in the Technical Solution process area are developed or purchased. Examples of other resources provided include the following tools: [PA160.EL104]
- Design specification tools
- Simulators and modeling tools
- Prototyping tools
- Scenario definition and management tools
- Requirements tracking tools
- Interactive documentation tools
Assign Responsibility: Assign responsibility and authority for performing the process, developing the work products, and providing the services of the technical solution process.
Train People: Examples of training topics include:
- Application domain of the product and product components
- Design methods
- Interface design
- Unit testing techniques
- Standards (e.g., product, safety, human factors, environmental)
Manage Configurations: Examples of work products placed under configuration management include:
- Product, product component, process, service, and interface designs
- Technical data packages
- Interface design documents
- Criteria for design and product-component reuse
- Implemented designs (e.g., software code, fabricated product components)
- User, installation, operation, and maintenance documentation
Identify and Involve Relevant Stakeholders: 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: [PA160.EL114]
- Developing alternative solutions and selection criteria
- Evolving operational concept and scenarios
- Obtaining approval on external interface specifications and design descriptions
- Developing the technical data package
- Assessing the make, buy, or reuse alternatives for product components
- Implementing the design
Monitor and Control the Process: Examples of measures used in monitoring and controlling include:
- Cost, schedule, and effort expended for rework
- Percentage of requirements addressed in the product or product-component design
- Size and complexity of the product, product components, interfaces, and documentation
- Defect density of technical solutions work products
Objectively Evaluate Adherence: Examples of activities reviewed include:
- Selecting product-component solutions
- Developing product and product-component designs
- Implementing product-component designs
Examples of work products reviewed include:
- Technical data packages
- Product, product-component, and interface designs
- Implemented designs (e.g., software code, fabricated product components)
- User, installation, operation, and maintenance documentation
Review Status with Higher Level Management:Review the activities, status, and results of the technical solution process with higher level management and resolve issues.

Defined

Establish Defined Process: Establish and maintain the description of a defined technical solution process.
Collect Improvement Information: Collect work products, measures, measurement results, and improvement information derived from planning and performing the technical solution process to support the future use and improvement of the organization’s processes and process assets.

Quantitatively Managed

Establish Quantitative Objectives for the Process: Establish and maintain quantitative objectives for the technical solution process that address quality and process performance based on customer needs and business objectives.
Stabilize Subprocess Performance: Stabilize the performance of one or more subprocesses to determine the ability of the technical solution process to achieve the established quantitative quality and process-performance objectives.

Optimizing

Ensure Continuous Process Improvement: Ensure continuous improvement of the technical solution process in fulfilling the relevant business objectives of the organization.
Correct Root Causes of Problems: Identify and correct the root causes of defects and other problems in the technical solution process.

PI: Product Integration

Purpose

To assemble the product from the product components, ensure that the product, as integrated, functions properly, and deliver the product.

This process area addresses the integration of product components into more complex product components or into complete products. The term “integration” is used in this sense throughout this process area and is not to be confused with integration of people or activities that may be described elsewhere in the model.

The scope of this process area is to achieve complete product integration through progressive assembly of product components, in one stage or in incremental stages, according to a defined integration sequence and procedures.

A critical aspect of product integration is the management of internal and external interfaces of the products and product components to ensure compatibility among the interfaces. Attention should be paid to interface management throughout the project.

Product integration is more than just a one-time assembly of the product components at the conclusion of design and fabrication. Product integration can be conducted incrementally, using an iterative process of assembling product components, evaluating them, and then assembling more product components. This process may begin with analysis and simulations (e.g., threads, rapid prototypes, virtual prototypes, and physical prototypes) and steadily progress through increasingly more realistic incremental functionality until the final product is achieved. In each successive build, prototypes (virtual, rapid, or physical) are constructed, evaluated, improved, and reconstructed based upon knowledge gained in the evaluation process. The degree of virtual vs. physical prototyping required depends on the functionality of the design tools, the complexity of the product, and its associated risk. There is a high probability that the product, integrated in this manner, will pass product verification and validation. For some products, the last integration phase will occur when the product is deployed at its intended operational site.

Specific Goals

Goal	Supporting Practices	Sub Practices
PI-1: Prepare for Product Integration Preparation for product integration is conducted. Preparing for integration of product components involves establishing and maintaining an integration sequence, the environment for performing the integration, and integration procedures. The specific practices of the Prepare for Product Integration specific goal build on each other in the following way. The first specific practice determines the sequence for product and product-component integration. The second determines the environment that will be used to carry out the product and product-component integration. The third develops procedures and criteria for product and product-component integration. Preparation for integration starts early in the project and the integration sequence is developed concurrently with the practices in the Technical Solution process area.	Determine Integration Sequence	[SP]
	Establish the Product Integration Environment	[SP]
	Establish Product Integration Procedures and Criteria	[SP]
PI-2: Ensure Interface Compatibility The product-component interfaces, both internal and external, are compatible. Many product integration problems arise from unknown or uncontrolled aspects of both internal and external interfaces. Effective management of product-component interface requirements, specifications, and designs helps ensure that implemented interfaces will be complete and compatible.	Review Interface Descriptions for Completeness	[SP]
	Manage Interfaces	[SP]
PI-3: Assemble Product Components and Deliver the Product Verified product components are assembled and the integrated, verified, and validated product is delivered. Integration of product components proceeds according to the product integration sequence and available procedures. Before integration, each product component should be confirmed to be compliant with its interface requirements. Product components are assembled into larger, more complex product components. These assembled product components are checked for correct interoperation. This process continues until product integration is complete. If, during this process, problems are identified, the problem should be documented and a corrective action process initiated. Ensure that the assembly of the product components into larger and more complex product components is conducted according to the product integration sequence and available procedures. The timely receipt of needed product components and the involvement of the right people contribute to the successful integration of the product components that compose the product.	Confirm Readiness of Product Components for Integration	[SP]
	Assemble Product Components	[SP]
	Evaluate Assembled Product Components	[SP]
	Package and Deliver the Product or Product Component	[SP]

Institutionalizing the Processes

Basic (Managed) Goals

Advanced Goals

Establish Policy: This policy establishes organizational expectations for developing product integration sequences, procedures, and an environment, ensuring interface compatibility among product components, assembling the product components, and delivering the product and product components.
Plan the Process: This plan for performing the product integration process addresses the comprehensive planning for all of the specific practices in this process area, from the preparation for product integration all the way through to the delivery of the final product.
Provide Resources: Product-component interface coordination may be accomplished with an Interface Control Working Group consisting of people who represent external and internal interfaces. Such groups can be used to elicit needs for interface requirements development. Special facilities may be required for assembling and delivering the product. When necessary, the facilities required for the activities in the Product Integration process area are developed or purchased.
Examples of other resources provided include:
- Prototyping tools
- Analysis tools
- Simulation tools
- Interface management tools
- Assembly tools (e.g., compilers, make files, joining tools, jigs and fixtures)
Assign Responsibility: Assign responsibility and authority for performing the process, developing the work products, and providing the services of the product integration process.
Train People: Examples of training topics include:
- Application domain
- Product integration procedures and criteria
- Organization's facilities for integration and assembly
- Assembly methods
- Packaging standards
Manage Configurations: Examples of work products placed under configuration management include:
- Acceptance documents for the received product components
- Evaluated assembled product and product components
- Product integration sequence
- Product integration procedures and criteria
- Updated interface description or agreement
Identify and Involve Relevant Stakeholders: 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:
- Reviewing interface descriptions for completeness
- Establishing the product integration sequence
- Establishing the product integration procedures and criteria
- Assembling and delivering the product and product components
- Communicating the results after evaluation
- Communicating new, effective product integration processes to give affected people the opportunity to improve their performance.
Monitor and Control the Process: Examples of measures used in monitoring and controlling include:
- Product-component integration profile (e.g., product-component assemblies planned and performed, and number of exceptions found)
- Integration evaluation problem report trends (e.g., number written and number closed)
- Integration evaluation problem report aging (i.e., how long each problem report has been open)
Objectively Evaluate Adherence: Examples of activities reviewed include:
- Establishing and maintaining a product integration sequence
- Ensuring interface compatibility
- Assembling product components and delivering the product
Examples of work products reviewed include:
- Product integration sequence
- Product integration procedures and criteria
- Acceptance documents for the received product components
- Assembled product and product components
Review Status with Higher Level Management:Review the activities, status, and results of the product integration process with higher level management and resolve issues.

Defined

Establish Defined Process: Establish and maintain the description of a defined product integration process.
Collect Improvement Information: Collect work products, measures, measurement results, and improvement information derived from planning and performing the product integration process to support the future use and improvement of the organization’s processes and process assets.

Quantitatively Managed

Establish Quantitative Objectives for the Process: Establish and maintain quantitative objectives for the product integration process that address quality and process performance based on customer needs and business objectives.
Stabilize Sub-process Performance: Stabilize the performance of one or more sub-processes to determine the ability of the product integration process to achieve the established quantitative quality and process-performance objectives.

Optimizing

Ensure Continuous Process Improvement: Ensure continuous improvement of the product integration process in fulfilling the relevant business objectives of the organization.
Correct Root Causes of Problems: Identify and correct the root causes of defects and other problems in the product integration process.

VER: Verification

Purpose

To ensure that selected work products meet their specified requirements.

Verification of work products substantially increases the likelihood that the product will meet the customer, product, and product-component requirements.

The Verification process area involves the following:

verification preparation,
verification performance, and
identification of corrective action.

Verification includes verification of the product and intermediate work products against all selected requirements, including customer, product, and product-component requirements.

Verification is inherently an incremental process because it occurs throughout the development of the product and work products, beginning with verification of the requirements, progressing through the verification of the evolving work products, and culminating in the verification of the completed product.

The specific practices of this process area build upon each other in the following way:

the Select Work Products for Verification specific practice enables the identification of the work products to be verified, the methods to be used to perform the verification, and the requirements to be satisfied by each selected work product.
the Establish the Verification Environment specific practice enables the determination of the environment that will be used to carry out the verification.
The Establish Verification Procedures and Criteria specific practice then enables the development of verification procedures and criteria that are aligned with the selected work products, requirements, methods, and characteristics of the verification environment.
The Perform Verification specific practice conducts the verification according to the available methods, procedures, and criteria.

The Verification and Validation process areas are similar, but they address different issues. Validation demonstrates that the product, as provided (or as it will be provided), will fulfill its intended use, whereas verification addresses whether the work product properly reflects the specified requirements. In other words, verification ensures that “you built it right;” whereas, validation ensures that “you built the right thing.”

Peer reviews are an important part of verification and are a proven mechanism for effective defect removal. An important corollary is to develop a better understanding of the work products and the processes that produced them so defects can be prevented and process improvement opportunities can be identified. ^[Note]

Specific Goals

Goal	Supporting Practices	Sub Practices
VER-1: Prepare for Verification Preparation for verification is conducted. Up-front preparation is necessary to ensure that verification provisions are embedded in product and product-component requirements, designs, developmental plans, and schedules. Verification includes selection, inspection, testing, analyses, and demonstration of work products. Methods of verification include, but are not limited to, inspections, peer reviews, audits, walkthroughs, analyses, simulations, testing, and demonstrations. Preparation also entails the definition of support tools, test equipment and software, simulations, prototypes, and facilities.	Select Work Products for Verification	[SP]
	Establish the Verification Environment	[SP]
	Establish Verification Procedures and Criteria	[SP]
VER-2: Perform Peer Reviews Peer reviews are performed on selected work products. Peer reviews involve a methodical examination of work products by the producers' peers to identify defects for removal and to recommend other changes that are needed. The peer review is an important and effective engineering method implemented via inspections, structured walkthroughs, or a number of other collegial review methods. Peer reviews are primarily applied to work products developed by the projects, but they can also be applied to other work products such as documentation and training work products that are typically developed by support groups.	Prepare for Peer Reviews	[SP]
	Conduct Peer Reviews	[SP]
	Analyze Peer Review Data	[SP]
VER-3: Verify Selected Work Products Selected work products are verified against their specified requirements.	Perform Verification	[SP]
	Analyze Verification Results and Identify Corrective Action	[SP]

Institutionalizing the Processes

Basic (Managed) Goals

Advanced Goals

Establish Policy: This policy establishes organizational expectations for establishing and maintaining verification methods, procedures, criteria, verification environment, performing peer reviews, and verifying selected work products.
Plan the Process: Typically, this plan for performing the verification process is included in (or referenced by) the project plan, which is described in the Project Planning process area.
Provide Resources: Special facilities may be required for verifying selected work products. When necessary, the facilities required for the activities in the Verification process area are developed or purchased. Certain verification methods may require special tools, equipment, facilities, and training (e.g., peer reviews may require meeting rooms and trained moderators; certain verification tests may require special test equipment and people skilled in the use of the equipment). Examples of other resources provided include:
- Test management tools
- Test-case generators
- Test-coverage analyzers
- Simulators
Assign Responsibility: Assign responsibility and authority for performing the process, developing the work products, and providing the services of the verification process.
Train People: Examples of training topics include:
- Application domain
- Verification principles, standards, and methods (e.g., analysis, demonstration, inspection, test)
- Verification tools and facilities
- Peer review preparation and procedures
- Meeting facilitation
Manage Configurations: Examples of work products placed under configuration management include:
- Verification procedures and criteria
- Peer review training material
- Peer review data
- Verification reports
Identify and Involve Relevant Stakeholders: 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:
- Selecting work products and methods for verification
- Establishing verification procedures and criteria
- Conducting peer reviews
- Assessing verification results and identifying corrective action
Monitor and Control the Process: Examples of measures used in monitoring and controlling include:
- Verification profile (e.g., the number of verifications planned and performed, and the defects found; perhaps categorized by verification method or type)
- Number of defects detected by defect category
- Verification problem report trends (e.g., number written and number closed)
- Verification problem report status (i.e., how long each problem report has been open)
Objectively Evaluate Adherence: Examples of activities reviewed include:
- Selecting work products for verification
- Establishing and maintaining verification procedures and criteria
- Performing peer reviews
- Verifying selected work products
Examples of work products reviewed include:
- Verification procedures and criteria
- Peer review checklists
- Verification reports
Review Status with Higher Level Management: Review the activities, status, and results of the verification process with higher level management and resolve issues.

Defined

Establish Defined Process: Establish and maintain the description of a defined verification process.
Collect Improvement Information: Collect work products, measures, measurement results, and improvement information derived from planning and performing the verification process to support the future use and improvement of the organization’s processes and process assets.

Quantitatively Managed

Establish Quantitative Objectives for the Process: Establish and maintain quantitative objectives for the verification process that address quality and process performance based on customer needs and business objectives.
Stabilize Sub-process Performance: Stabilize the performance of one or more sub-processes to determine the ability of the verification process to achieve the established quantitative quality and process-performance objectives.

Optimizing

Ensure Continuous Process Improvement: Ensure continuous improvement of the verification process in fulfilling the relevant business objectives of the organization.
Correct Root Causes of Problems: Identify and correct the root causes of defects and other problems in the verification process.

VAL: Validation

Purpose

To demonstrate that a product or product component fulfills its intended use when placed in its intended environment. [

Validation activities can be applied to all aspects of the product in any of its intended environments, such as operation, training, manufacturing, maintenance, and support services. The methods employed to accomplish validation can be applied to work products as well as to the product and product components. The work products (e.g., requirements, designs, prototypes) should be selected on the basis of which are the best predictors of how well the product and product component will satisfy user needs.

The validation environment should represent the intended environment for the product and product components as well as represent the intended environment suitable for validation activities with work products.

Validation demonstrates that the product, as provided, will fulfill its intended use; whereas, verification addresses whether the work product properly reflects the specified requirements. In other words, verification ensures that “you built it right;” whereas, validation ensures that “you built the right thing". Validation activities use approaches similar to verification (e.g., test, analysis, inspection, demonstration, or simulation). Often, the end users are involved in the validation activities. Both validation and verification activities often run concurrently and may use portions of the same environment.

Where possible, validation should be accomplished using the product or product component operating in its intended environment. The entire environment may be used or only part of it. However, validation issues can be discovered early in the life of the project using work products.

When validation issues are identified, they are referred to the processes associated with the Requirements Development, Technical Solution, or Project Monitoring and Control process areas for resolution.

The specific practices of this process area build on each other in the following way. The Select Products for Validation specific practice enables the identification of the product or product component to be validated and the methods to be used to perform the validation. The Establish the Validation Environment specific practice enables the determination of the environment that will be used to carry out the validation. The Establish Validation Procedures and Criteria specific practice enables the development of validation procedures and criteria that are aligned with the characteristics of selected products, customer constraints on validation, methods, and the validation environment. The Perform Validation specific practice enables the performance of validation according to the methods, procedures, and criteria.

Specific Goals

Goal	Supporting Practices	Sub Practices
VAL-1: Prepare for Validation Preparation for validation is conducted. Preparation activities include selecting products and product components for validation and establishing and maintaining the validation environment, procedures, and criteria. The items selected for validation may include only the product or it may include appropriate levels of the product components that are used to build the product. Any product or product component may be subject to validation, including replacement, maintenance, and training products, to name a few. The environment required to validate the product or product component is prepared. The environment may be purchased or may be specified, designed, and built. The environments used for product integration and verification may be considered in collaboration with the validation environment to reduce cost and improve efficiency or productivity.	Select Products for Validation	[SP]
	Establish the Validation Environment	[SP]
	Establish Validation Procedures and Criteria	[SP]
VAL-2: Validate Product or Product Components The product or product components are validated to ensure that they are suitable for use in their intended operating environment. The validation methods, procedures, and criteria are used to validate the selected products and product components and any associated maintenance, training, and support services using the appropriate validation environment.	Perform Validation	[SP]
	Analyze Validation Results	[SP]

Institutionalizing the Processes

Basic (Managed) Goals

Advanced Goals

Establish Policy: This policy establishes organizational expectations for selecting products and product components for validation; for selecting validation methods; and for establishing and maintaining validation procedures, criteria, and environments that ensure the products and product components satisfy user needs in their intended operating environment.
Plan the Process: Typically, this plan for performing the validation process is included in (or referenced by) the project plan, which is described in the Project Planning process area.
Provide Resources: Special facilities may be required for validating the product or product components. When necessary, the facilities required for validation are developed or purchased.Examples of other resources provided include:
- Test management tools
- Test-case generators
- Test-coverage analyzers
- Simulators
- Load, stress, and performance tools
Assign Responsibility: Assign responsibility and authority for performing the process, developing the work products, and providing the services of the validation process.
Train People: Examples of training topics include:
- Application domain
- Validation principles, standards, and methods
- Intended-use environment
Manage Configurations: Examples of work products placed under configuration management include:
- Lists of products and product components selected for validation
- Validation methods, procedures, and criteria
- Validation reports
Identify and Involve Relevant Stakeholders: 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:
- Selecting the products and product components to be validated
- Establishing the validation methods, procedures, and criteria
- Reviewing results of product and product-component validation and resolving issues
- Resolving issues with the customers or end users
Issues with the customers or end users are resolved particularly when there are significant deviations from their baseline needs for:
- Waivers on the contract or agreement (what, when, and for which products, services, or manufactured products)
- Additional in-depth studies, trials, tests, or evaluations
- Possible changes in the contracts or agreements
Monitor and Control the Process: Examples of measures used in monitoring and controlling include:
- Number of validation activities completed (planned versus actual)
- Validation problem report trends (e.g., number written and number closed)
- Validation problem report aging (i.e., how long each problem report has been open)
Objectively Evaluate Adherence: Examples of activities reviewed include:
- Selecting the products and product components to be validated
- Establishing and maintaining validation methods, procedures, and criteria
- Validating products or product components
Examples of work products reviewed include:
- Validation methods, procedures, and criteria
Review Status with Higher Level Management: Review the activities, status, and results of the validation process with higher level management and resolve issues.

Defined

Establish Defined Process: Establish and maintain the description of a defined validation process.
Collect Improvement Information: Collect work products, measures, measurement results, and improvement information derived from planning and performing the validation process to support the future use and improvement of the organization’s processes and process assets.

Quantitatively Managed

Establish Quantitative Objectives for the Process: Establish and maintain quantitative objectives for the validation process that address quality and process performance based on customer needs and business objectives.
Stabilize Subprocess Performance: Stabilize the performance of one or more subprocesses to determine the ability of the validation process to achieve the established quantitative quality and process-performance objectives.

Optimizing

Ensure Continuous Process Improvement:Ensure continuous improvement of the validation process in fulfilling the relevant business objectives of the organization.
Correct Root Causes of Problems: Identify and correct the root causes of defects and other problems in the validation process.

<——— Back: Project Management

Next: Support ———>