Acquisition Requirements Development: An Acquisition Engineering Process Area at Maturity Level 2
Purpose
The purpose of Acquisition Requirements Development (ARD) is to elicit, develop, and analyze customer and contractual requirements.
X-Ref
REQM addresses management of requirements once they have been developed.
Introductory Notes
This process area describes two types of requirements: customer requirements, which address the needs of relevant stakeholders for which one or more products and services will be acquired, and contractual requirements, which are the requirements to be addressed through the acquirer’s relationship with suppliers and other appropriate organizations. Both sets of requirements should address needs relevant to later product lifecycle phases (e.g., operation, maintenance, support, disposal) and key quality attributes (e.g., safety, reliability, maintainability).
Tip
Customer needs can prescribe particular solutions (e.g., a particular service-oriented architecture to facilitate interoperability) as well as describe the problem to be solved.
In some acquisitions, the acquirer assumes the role of overall systems engineer, architect, or integrator for the product. In these acquisitions, the Requirements Development process area of CMMI-DEV should be used. Requirements Development in CMMI-DEV includes additional information helpful in these situations, including deriving and analyzing requirements at successively lower levels of product definition (e.g., establishing and maintaining product component requirements).
Requirements are the basis for the selection and design or configuration of the acquired product. The development of requirements includes the following activities:
• Elicitation, analysis, and validation of stakeholder needs, expectations, constraints, and interfaces to establish customer requirements that constitute an understanding of what will satisfy stakeholders
• Development of the lifecycle requirements of the product (e.g., development, maintenance, transition to operations, decommissioning)
• Establishment of contractual requirements consistent with customer requirements to a level of detail that is sufficient to be included in the solicitation package and supplier agreement
• Development of the operational concept
• Analysis of needs and requirements (for each product lifecycle phase), the operational environment, and factors that reflect overall customer and end-user needs and expectations for quality attributes
• Identification of quality attributes, which are non-functional properties of a product or service (e.g., responsiveness, availability, security) and are critical to customer satisfaction and to meeting the needs of relevant stakeholders (see the definition of “quality attributes” in the glossary)
The requirements included in the solicitation package form the basis for evaluating proposals by suppliers and for further negotiations with suppliers and communication with the customer. The contractual requirements for the supplier are baselined in the supplier agreement.
Requirements are refined throughout the project lifecycle. Design decisions, subsequent corrective actions, and feedback during each phase of the project’s lifecycle are analyzed for their impact on contractual requirements.
Requirements analyses aid understanding, defining, and selecting requirements at all levels from competing alternatives. Analyses occur recursively at successively more detailed levels until sufficient detail is available to produce contractual requirements and to further refine these requirements, if necessary, while the supplier builds or configures the product.
Involvement of relevant stakeholders in both requirements development and analyses gives them visibility into the evolution of requirements. Participation continually assures stakeholders that requirements are being properly defined.
The Acquisition Requirements Development process area includes three specific goals. The Develop Customer Requirements specific goal addresses eliciting and defining a set of customer requirements. The Develop Contractual Requirements specific goal addresses defining contractual requirements that are based on customer requirements and are included in the solicitation package and supplier agreement. The specific practices of the Analyze and Validate Requirements specific goal support the development of the requirements in the first two specific goals. The specific practices associated with this specific goal cover analyzing and validating requirements with respect to the acquirer’s intended environment.
X-Ref
Requirements validation is addressed in ARD because it is critical to align project and customer expectations.
Related Process Areas
Refer to the Acquisition Technical Management process area for more information about evaluating technical solutions.
Refer to the Acquisition Validation process area for more information about validating selected products and product components.
Refer to the Solicitation and Supplier Agreement Development process area for more information about establishing a solicitation package and establishing supplier agreements.
Refer to the Requirements Management process area for more information about managing requirements.
Refer to the Risk Management process area for more information about identifying and analyzing risks.
Tip
Stakeholder needs are rarely communicated fully in an official document. They are communicated in documentation, conversations, meetings, demonstrations, and so on. Thus this information must be translated into requirements that the project and the customer can agree to.
Hint
Pay particular attention to nonfunctional requirements or other architecturally significant quality attributes or “ilities” (e.g., security, interoperability, maintainability, extendibility).
X-Ref
For help in facilitating the discovery of quality attributes, see “Quality Attribute Workshops, Third Edition,” at www.sei.cmu.edu/library/abstracts/reports/03tr016.cfm.
Specific Practices by Goal
SG 1 Develop Customer Requirements
Stakeholder needs, expectations, constraints, and interfaces are collected and translated into customer requirements.
Stakeholders (e.g., customers, end users, suppliers, testers, integrators, maintainers, operators, supplier agreement management staff, manufacturers, logistics support staff) are sources of requirements. Their needs, expectations, constraints, interfaces, operational concepts, and product concepts are analyzed, harmonized, refined, and elaborated for translation into a set of customer requirements.
Hint
Rarely do customers know exactly what they want. Plan to use an iterative process to uncover the requirements for the product or service to be acquired.
Frequently, stakeholder needs, expectations, constraints, and interfaces are poorly identified or conflicting. Since these needs, expectations, constraints, and interfaces should be clearly identified and understood throughout the project lifecycle, an iterative process is used throughout the life of the project to accomplish this objective. To facilitate the required interaction, relevant stakeholders are frequently involved throughout the project lifecycle to communicate their needs, expectations, and constraints, and to help resolve conflicts. Environmental, legal, and other constraints should be considered when creating and evolving the set of requirements to be used in acquiring products or services.
SP 1.1 Elicit Stakeholder Needs
Elicit stakeholder needs, expectations, constraints, and interfaces for all phases of the product lifecycle.
Tip
In the case of acquiring product lines or product families, SP 1.1 is sometimes implemented across the product line or product family. A special infrastructure project may establish core assets used in developing each product in the family. In such an organization, requirements come from the organization, the individual acquisition programs, and the core asset development project.
Eliciting goes beyond collecting needs by proactively identifying additional needs not explicitly provided by stakeholders. Relevant stakeholders who represent all phases of the product lifecycle in the acquirer’s intended environment should include business as well as technical functions. Using this approach, needs for all product related lifecycle processes are considered concurrently with concepts for acquired products.
An analysis of business processes is a common source of stakeholder needs, expectations, constraints, and interfaces. Additional needs typically address project lifecycle activities and their impact on the product.
X-Ref
For more information on acquiring products and services in a product line environment, see “Acquisition Organizations and Product Lines” at www.sei.cmu.edu/productlines/start/acquisition/index.cfm.
Hint
Ask what the product must do and how it will behave. Also determine what is required to produce it (if it is a physical product), license it, install it, train end users, maintain the product, migrate to new versions, support its use, retire it, and dispose of it.
Hint
Never underestimate the value of reviewing other sources of requirements. A large number of acquisition projects incur cost and schedule impacts because one or more sources of requirements were not considered.
Example Work Products
1. Stakeholder needs, expectations, constraints, and interfaces
Subpractices
1. Engage relevant stakeholders using methods for eliciting needs, expectations, constraints, and external interfaces.
Hint
Significant changes to requirements may occur during different phases in the project lifecycle. It may be useful to think about your acquisition strategy differently (e.g., evolutionary or incremental approaches), especially if the project lifecycle is lengthy.
SP 1.2 Develop and Prioritize Customer Requirements
Transform stakeholder needs, expectations, constraints, and interfaces into prioritized customer requirements.
The customer typically describes requirements as capabilities expressed in broad operational terms concerned with achieving a desired effect under specified standards and regulations. Customer requirements can also include needs, expectations, constraints, and interfaces with regard to verification and validation. Inputs from the customer and other stakeholders should be aligned to the acquisition strategy. Missing information should be obtained and conflicts should be resolved as customer requirements are developed and prioritized.
X-Ref
The acquisition strategy is described in detail in SP 1.1 of the Project Planning process area.
Customer requirements can also exist as an output of another activity such as a previous project that delivered the initial capability; or a possible earlier customer or system-of-systems office related activity establishing architectural principles, interoperability standards, and common design constraints.
Example Work Products
1. Prioritized customer requirements
2. Customer constraints on the conduct of verification
3. Customer constraints on the conduct of validation
Subpractices
1. Translate stakeholder needs, expectations, constraints, and interfaces into documented customer requirements.
2. Establish and maintain a prioritization of customer functional and quality attribute requirements.
Having prioritized customer requirements guides the acquirer in determining project scope and which requirements and requirements changes to include in supplier agreements. This prioritization ensures that functional and quality attribute requirements critical to the customer and other relevant stakeholders are addressed quickly. Determining priorities and resolving conflicts among them can be addressed when eliciting stakeholder needs, as described in the previous specific practice.
3. Define constraints for verification and validation.
SG 2 Develop Contractual Requirements
Customer requirements are refined and elaborated into contractual requirements.
Tip
The relationships among customer and contractual requirements should be investigated and recorded (see REQM SP 1.4).
Customer requirements are analyzed in conjunction with the development of the operational concept to derive more detailed and precise sets of requirements, called contractual requirements, to be included in the solicitation package for potential suppliers and eventually in the supplier agreement. The level of detail of contractual requirements is based on the acquisition strategy and project characteristics.
Contractual requirements arise from constraints, consideration of issues implied but not explicitly stated in the customer requirements baseline, and factors introduced by design constraints and supplier capabilities. Contractual requirements include both requirements documented in contracts between an acquirer and supplier and requirements addressed through formal agreements between the acquirer and other organizations (e.g., partners, subcontractors, government agencies, internal organizational units). (See the definition of “contractual requirements” in the glossary.) Requirements are reexamined throughout the project lifecycle.
The requirements are allocated to supplier deliverables. The traceability across levels of requirements and supplier deliverables (and planned supplier delivery increments) is documented.
Refer to the Requirements Management process area for more information about maintaining bidirectional traceability of requirements.
SP 2.1 Establish Contractual Requirements
Establish and maintain contractual requirements that are based on the customer requirements.
Customer requirements can be expressed in the customer’s terms and can be nontechnical descriptions. Contractual requirements are the expression of these requirements in technical terms that can be used for design decisions.
Tip
Translating requirements (i.e., from customer to contractual) introduces opportunities for misinterpretation and risk. Spend extra time ensuring that the contractual requirements accurately reflect the customer need.
In addition to technical requirements (e.g., requirements specifying interfaces with other products or applications, functional and operationally related quality attribute requirements and their validation, technical performance measures, verification requirements such as product acceptance criteria), contractual requirements cover nontechnical stakeholder needs, expectations, constraints, and interfaces.
The modification of requirements due to approved requirement changes is covered by the maintain aspect of this specific practice; whereas, the administration of requirement changes is covered by the Requirements Management process area.
Refer to the Requirements Management process area for more information about managing requirements.
Example Work Products
1. External interface requirements
2. Prioritized contractual requirements
Subpractices
1. Develop functional and quality attribute requirements necessary for the determination of alternative solutions and the development of the product by the supplier.
Priorities can be assigned to product requirements to provide a basis for future requirements tradeoffs should such tradeoffs become necessary. Acquirers may assign priorities using categories such as Essential, Important, or Desirable.
Tip
Identifying the interfaces for which requirements will be developed is not a one-time event, but rather continues for as long as new interfaces are established.
2. Develop requirements for the interfaces between the acquired product and other products in the intended environment.
Requirements for interfaces are defined in terms of origination, destination, stimulus, data characteristics for software, and electrical and mechanical characteristics for hardware.
Hint
If multiple systems are being acquired to provide the needed capability, recognize that the interfaces may change as these systems evolve.
3. Develop design considerations and constraints necessary for supplier activities that include: determination of alternative solutions, development and evaluation of architectures, and the development of the product.
Design considerations and constraints address the quality attributes and technical performance that are critical to the success of the product in its intended operational environment. They account for customer requirements relative to product interoperability, implications from the use of commercial off-the-shelf (COTS) products, safety, security, durability, and other mission critical concerns.
Tip
Previous acquisitions may have had somewhat different needs to fulfill, so requirements and test cases to be reused may need to be analyzed and possibly modified for the current acquisition.
To achieve high levels of reuse and interoperability, acquirers can establish common design constraints for products or product families that can be deployed in one or more domains. Alternatively, acquirers can accelerate the development of technical requirements and design constraints by reusing shared or common constraints or requirements and their associated test cases from previous acquisitions or leverage the supplier’s previous product developments.
Common design constraints can also be established and maintained by a customer organization or system-of-systems office for a group of acquisitions collectively intended to establish a major capability (e.g., for systems-of-systems, product lines, standard services).
4. Develop requirements for verification and validation of the product to be developed by the supplier.
Requirements for verification and validation typically include types and coverage of testing and review to be carried out in the supplier’s and acquirer’s environments.
Tip
If the satisfaction of a requirement cannot be ensured through some verification process, the requirement should be restated or eliminated.
5. Establish and maintain relationships among the requirements under consideration during change management and requirements allocation.
Relationships between requirements can affect evaluating the impact of requirements changes. Expected requirements volatility is a key factor in anticipating scope changes and supporting the acquirer’s selection of the appropriate acquisition type.
6. Identify nontechnical requirements.
Contractual requirements consist of both technical and nontechnical requirements. Examples of nontechnical requirements are listed in the example box in this specific practice.
7. Establish and maintain a prioritization of contractual requirements.
Priority can be based on a combination of several factors that include customer desires, costs, timeframe for when the capabilities are needed, and length of time to satisfy a particular requirement.
When cost estimates can be determined for contractual requirements, their priority and costs can be used to guide contract and budget negotiations and to determine which changes should be made to the contract.
Priority can also help when developing a release strategy (e.g., first release only addresses high priority requirements; lower priority requirements are deferred to a later release or maintenance phase).
Refer to the Project Planning process area for more information about establishing the acquisition strategy and estimating effort and cost.
SP 2.2 Allocate Contractual Requirements
Allocate contractual requirements to supplier deliverables.
Contractual requirements are allocated, as appropriate, to supplier deliverables. The requirements for each supplier deliverable are documented. In some cases, technical requirements are allocated to third-party products that are used by the supplier (e.g., COTS products).
Tip
Sometimes a seemingly insignificant requirements change can greatly improve the merits of a COTS-based solution, especially with regard to cost and schedule risks. Conversely, the use of a COTS product may constrain the overall solution’s performance and the support that can be offered later in the product’s life. A relationship with a vendor may need to be maintained.
Example Work Products
1. Requirement allocation sheets
Subpractices
1. Allocate requirements to supplier deliverables.
In the case of an evolutionary acquisition lifecycle, the requirements for the initial capability can also be allocated to suppliers’ initial iterations or increments based on stakeholder priorities, technology issues, supplier capabilities, and acquirer project objectives.
X-Ref
See www.sei.cmu.edu/acquisition/tools/methods/cotsintro.cfm for more information about using COTS products.
2. Allocate design constraints to supplier deliverables.
3. Document relationships among allocated requirements and design constraints.
Relationships include dependencies (i.e., a change in one requirement can affect other requirements).
Tip
Sometimes a higher-level requirement specifies performance that is satisfied by multiple supplier deliverables or even across multiple supplier teams.
4. Allocate requirements to suppliers.
In situations where multiple suppliers are involved in developing the technical solution, different products or product components may be allocated to different suppliers.
Tip
The allocation of a higher-level requirement to supplier deliverables is not necessarily fixed. Often, a provisional allocation of a higher-level requirement to a supplier is made, but is later revised to account for the unique or emerging capabilities of individual suppliers, teams, or new COTS products.
5. Develop an approach to address requirements that by their nature are shared among multiple stakeholders (e.g., the acquirer, multiple suppliers, customers, end users).
Some requirements (in particular, for some quality attribute requirements) should be shared among multiple stakeholders and maintained through the life of the product (e.g., security requirements often cannot be allocated to a single supplier). An approach that addresses such requirements should be devised and appropriately incorporated in customer and supplier agreements.
Hint
Pay close attention to integration issues when you allocate contractual requirements to multiple suppliers. You may inadvertently end up filling the role of product integrator.
Refer to the Solicitation and Supplier Agreement Development process area for more information about establishing supplier agreements.
SG 3 Analyze and Validate Requirements
Requirements are analyzed and validated.
Tip
The purpose of requirements validation is to ensure that you have a clear understanding of what the customer wants and needs. Often, this understanding evolves over time and requires a series of requirements validation activities.
Analyses are performed to determine the impact the intended operational environment will have on the ability to satisfy stakeholder needs, expectations, constraints, and interfaces. Considerations such as feasibility, mission needs, cost constraints, potential market size, and acquisition strategy should all be taken into account, depending on the product context.
The objectives of these analyses are (1) to determine candidate requirements for product concepts that will satisfy stakeholder needs, expectations, constraints, and interfaces and (2) to translate these concepts into requirements. In parallel with these activities, the parameters to be used to evaluate the effectiveness of the product are determined based on customer input and the preliminary product concept.
Tip
Requirements analyses examine requirements from different perspectives (e.g., feasibility, cost, risk) and using different abstractions (e.g., functional, data flow, entity relationship, state diagrams, temporal).
Requirements are validated to increase the probability that the resulting product will perform as intended in the acquirer’s intended environment.
Hint
Identify technical performance measures and other measures that help in assessing or predicting performance, usability, cost, schedule, risk, and other aspects of the product. Use them to state contractual requirements, establish quality objectives, evaluate progress, manage risk, and conduct trade studies. They provide a data-driven approach to engineering the product.
SP 3.1 Establish Operational Concepts and Scenarios
Establish and maintain operational concepts and associated scenarios.
Operational concepts or concepts of operation are overall descriptions of the problems to be solved in operational terms and the ways in which the products to be acquired are intended to be used or operated, deployed, supported (including maintenance and sustainment), and disposed. The acquirer explicitly accounts for design constraints.
X-Ref
Technical performance measures are covered in more detail in the Measurement and Analysis process area.
In contrast, a scenario is a description of a sequence of events that might occur in the use, transition, or sustainment of the product to be acquired and makes explicit some stakeholder functionality and quality attribute needs. Typically, scenarios are derived from business process descriptions and operational concepts.
X-Ref
For more information about technical performance parameters, see “Using CMMI to Improve Earned Value Management” at www.sei.cmu.edu/library/abstracts/reports/02tn016.cfm.
Operational concepts and scenarios can assist in the elicitation of needs and the analysis and refinement of requirements. Operational concepts and scenarios can be further refined as solution decisions are made and more detailed requirements are developed. They are evolved to facilitate the validation of technical solutions delivered by the supplier.
Hint
Think of an operational concept as a picture that portrays the product, the end user, and other entities in the intended environment. Think of an operational scenario as a story describing a sequence of events and end-user and product interactions. An operational concept provides a context for developing or evaluating a set of scenarios.
Example Work Products
1. Operational, maintenance, support, and disposal concepts
2. Use cases, user stories
3. New requirements
Subpractices
1. Develop operational concepts and scenarios that include operations, installation, maintenance, support, and disposal as appropriate.
Augment scenarios with quality attribute considerations for the functions (or other logical entities) described in the scenario.
Tip
Operational concepts and scenarios are a way to demonstrate or bring to life what the requirements are trying to capture.
2. Define the environment in which the product will operate, including boundaries and constraints.
3. Review operational concepts and scenarios to refine and discover requirements.
Operational concept and scenario development is an iterative process. Reviews should be held periodically to ensure that the operational concepts and scenarios agree with the requirements. The review can be in the form of a walkthrough.
Tip
Functionality is typically documented using diagrams and descriptions. The diagrams provide a high-level picture of the overall functionality, whereas the descriptions provide the finer details.
4. Develop a detailed operational concept, as candidate solutions are identified and product and product component solutions are selected by the supplier, that defines the interaction of the product, the end user, and the environment, and that satisfies operational, maintenance, support, and disposal needs.
Tip
Requirements analyses help to answer questions such as whether all requirements are necessary, whether any are missing, whether they are consistent with one another, and whether they can be implemented and verified.
SP 3.2 Analyze Requirements
Analyze requirements to ensure they are necessary and sufficient.
As contractual requirements are defined, their relationship to customer requirements should be understood. In light of the operational concepts and scenarios, the contractual requirements are analyzed to determine whether they are necessary and sufficient to meet customer requirements. The analyzed requirements then provide the basis for more detailed and precise requirements throughout the project lifecycle.
X-Ref
When analyzing requirements, look at some of the characteristics described in REQM SP 1.1 subpractice 2 to understand the many factors that can be considered.
Also, which key requirements will be used to track technical progress is determined. For instance, the weight of a product or size of a software product can be monitored through development based on its risk or its criticality to the customer or end user.
Refer to the Acquisition Technical Management process area for more information about conducting technical reviews.
Example Work Products
1. Requirements defects reports
2. Proposed requirements changes to resolve defects
3. Key requirements
4. Technical performance measures
Subpractices
1. Analyze stakeholder needs, expectations, constraints, and external interfaces to organize into related subjects and remove conflicts.
Hint
As conflicts are removed, inform the relevant stakeholders of changes that affect the requirements they provided.
2. Analyze requirements to determine whether they satisfy higher level requirements.
3. Analyze requirements to ensure that they are complete, feasible, realizable, and verifiable.
4. Analyze and propose the allocation of requirements.
5. Identify key requirements that have a strong influence on cost, schedule, performance, or risk.
These key requirements often reflect cross-cutting (i.e., system-level) concerns and often address quality attributes that will be a major driver to a supplier’s architecture definition and evaluation activities. A clear understanding of such quality attributes (also known as “architecturally significant quality attributes”) and their importance based on mission or business needs is essential to an effective analysis of requirements and to effective technical performance measurement.
6. Identify technical performance measures to be tracked during the acquisition.
Technical performance measures are precisely defined measures based on a product requirement, product capability, or some combination of requirements and capabilities. Technical performance measures are chosen to monitor requirements and capabilities that are considered key factors in a product’s performance. Data for technical performance measures are provided by the supplier as specified in the supplier agreement.
Refer to the Measurement and Analysis process area for more information about specifying measures.
7. Analyze operational concepts and scenarios to refine customer needs, constraints, and interfaces and to discover new requirements.
This analysis can result in more detailed operational concepts and scenarios as well as support the derivation of new requirements.
SP 3.3 Analyze Requirements to Achieve Balance
Analyze requirements to balance stakeholder needs and constraints.
Stakeholder needs and constraints can address such things as cost, schedule, product or project performance, functionality, reusable components, maintainability, or risk.
Tip
One senior DoD program manager on a development project containing 7 million lines of code mused, “We need to find a way to suppress our appetite. We’re developing millions of lines of code for functionality that will never be used.” Although “gold plating” or overpromising may be a good way to justify a project early on, eventually the products need to be built in a reasonable amount of time.
Requirements are analyzed to determine whether they reflect an appropriate balance among cost, schedule, performance, and other factors of interest to relevant stakeholders. Models and simulations can be used to estimate the impacts that requirements will have on these factors. By involving stakeholders from different phases of the product’s lifecycle in analyzing these impacts, risks can be determined. If the risks are considered unacceptable, the requirements can be revised or reprioritized to improve the balance of cost, schedule, and performance.
Example Work Products
1. Assessment of risks related to requirements
2. Proposed requirements changes
Subpractices
1. Use proven models, simulations, and prototyping to analyze the balance of stakeholder needs and constraints.
Results of analyses can be used to reduce the cost of the product and the risk in acquiring and using the product.
2. Perform a risk assessment on requirements and design constraints.
Refer to the Risk Management process area for more information about identifying and analyzing risks.
3. Examine product lifecycle concepts for impacts of requirements on risks.
Tip
In these subpractices, you determine whether the requirements serve as an adequate basis for product development and decide how to track progress in achieving key requirements.
4. Perform a cost benefit analysis to assess impact of the requirements on the overall acquisition strategy and acquisition project costs and risks.
This assessment of impact often focuses on an evaluation of requirements addressing architecturally significant quality attributes. As an example, a combination of tight response time requirements and high reliability requirements could prove expensive to implement. Once the possible impacts are better understood, the requirements can be adjusted to achieve a better balance among cost, schedule, performance, and risk; and thus enable a more affordable capability to be acquired.
SP 3.4 Validate Requirements
Validate requirements to ensure the resulting product performs as intended in the end user’s environment.
Requirements validation is performed early in the acquisition with end users or their representatives to gain confidence that the requirements are capable of guiding a development that results in successful final validation. This activity should be integrated with risk management activities. Mature organizations typically perform requirements validation in a more sophisticated way using multiple techniques and broaden the basis of the validation to include other stakeholder needs and expectations. These organizations typically perform analyses, prototyping, and simulations to ensure that requirements will satisfy stakeholder needs and expectations.
Tip
Requirements validation in this SP focuses on the adequacy and completeness of the requirements. Product and service validation in AVAL focuses on predicting at multiple points in development how well the product or service will satisfy user needs.
Example Work Products
1. Records of analysis methods and results
Example Supplier Deliverables
1. Requirements and validation methods (e.g., prototypes, simulations)
Subpractices
1. Analyze the requirements to determine the risk that the resulting product will not perform appropriately in its intended-use environment.
2. Explore the adequacy and completeness of requirements by developing product representations (e.g., prototypes, simulations, models, scenarios, storyboards) and by obtaining feedback about them from relevant stakeholders.
Refer to the Acquisition Validation process area for more information about preparing for validation and validating selected products and product components.
3. Assess product and product component solutions as they are developed by the supplier in the context of the validation environment to identify issues and expose unstated needs and customer requirements.