# PROCESS PURPOSE
The purpose is to provide evidence that the end product, allowing direct end user interaction, satisfies the intended use expectations in its operational target environment.
# PROCESS OUTCOMES
O1 (Validation measure = Validation measure can be:
Operational use case testing under real-life conditions
Highly accelerated life testing (HALT)
Simulations under real-life conditions
End user trials
Panel or blind tests
Expert panels
) are selected considering criteria for the (Regression verification = Selective re-verification of elements to verify that modifications have not caused unintended effects.).
O2
The product is validated using the selected (Validation measure = Validation measure can be:
Operational use case testing under real-life conditions
Highly accelerated life testing (HALT)
Simulations under real-life conditions
End user trials
Panel or blind tests
Expert panels
), and the results of validation are recorded.
O3
Consistency and bidirectional traceability are established between (Validation measure = Validation measure can be:
Operational use case testing under real-life conditions
Highly accelerated life testing (HALT)
Simulations under real-life conditions
End user trials
Panel or blind tests
Expert panels
) and the (Stakeholder requirements = Any type of requirement for the stakeholders in the given context, e.g., customer requirement, supplier internal requirements (product-specific, platform etc.), legal requirements, regulatory requirements, statutory requirements, industry sector requirements, international standards, codes of practice etc. …), if applicable; and bidirectional traceability is established between the validation results and the (Validation measure = Validation measure can be:
Operational use case testing under real-life conditions
Highly accelerated life testing (HALT)
Simulations under real-life conditions
End user trials
Panel or blind tests
Expert panels
).
O4
The results of the validation are summarized and communicated to all affected parties.
# BASE PRACTICES
BP1
Specify validation measures for the product validation. (
O1 )
Specify the (Validation measure = Validation measure can be:
Operational use case testing under real-life conditions
Highly accelerated life testing (HALT)
Simulations under real-life conditions
End user trials
Panel or blind tests
Expert panels
) for the end product based on the (Stakeholder requirements = Any type of requirement for the stakeholders in the given context, e.g., customer requirement, supplier internal requirements (product-specific, platform etc.), legal requirements, regulatory requirements, statutory requirements, industry sector requirements, international standards, codes of practice etc. …) to provide evidence that it fulfills its intended use expectations in its operational target environment, and this may include
techniques for the (Validation measure = Validation measure can be:
Operational use case testing under real-life conditions
Highly accelerated life testing (HALT)
Simulations under real-life conditions
End user trials
Panel or blind tests
Expert panels
),
pass/fail criteria for the (Validation measure = Validation measure can be:
Operational use case testing under real-life conditions
Highly accelerated life testing (HALT)
Simulations under real-life conditions
End user trials
Panel or blind tests
Expert panels
), if applicable
a definition of entry criteria for the (Validation measure = Validation measure can be:
Operational use case testing under real-life conditions
Highly accelerated life testing (HALT)
Simulations under real-life conditions
End user trials
Panel or blind tests
Expert panels
), if applicable
necessary sequence of the (Validation measure = Validation measure can be:
Operational use case testing under real-life conditions
Highly accelerated life testing (HALT)
Simulations under real-life conditions
End user trials
Panel or blind tests
Expert panels
), and
the required validation infrastructure and environment setup.
Note 1: An example for validation-relevant (Stakeholder requirements = Any type of requirement for the stakeholders in the given context, e.g., customer requirement, supplier internal requirements (product-specific, platform etc.), legal requirements, regulatory requirements, statutory requirements, industry sector requirements, international standards, codes of practice etc. …) are homologation or legal type (Approval = Written statement that a deliverable is fit for its intended use, compliant with defined criteria.) requirements. Further examples of sources of intended use expectations are technical (Risk = The combination of the probability of occurrence and the consequences of a given future undesirable event.) (see MAN.5, SYS.3.BP4, SWE.2.BP3, HWE.2.BP6). Note 2: Where (Stakeholder requirements = Any type of requirement for the stakeholders in the given context, e.g., customer requirement, supplier internal requirements (product-specific, platform etc.), legal requirements, regulatory requirements, statutory requirements, industry sector requirements, international standards, codes of practice etc. …) cannot be specified comprehensively or change frequently, repeated validation of (often rapidly developed) increments in product evolution may be employed to refine (Stakeholder requirements = Any type of requirement for the stakeholders in the given context, e.g., customer requirement, supplier internal requirements (product-specific, platform etc.), legal requirements, regulatory requirements, statutory requirements, industry sector requirements, international standards, codes of practice etc. …), and to mitigate (Risk = The combination of the probability of occurrence and the consequences of a given future undesirable event.) in the correct identification of needs. Note 3: Validation may also be conducted to confirm that the product also satisfies the often less formally expressed, but sometimes overriding, attitudes, experience, and subjective tests that comprise stakeholder or end user satisfaction.
BP2
Select validation measures. (
O1 )
Document the selection of (Validation measure = Validation measure can be:
Operational use case testing under real-life conditions
Highly accelerated life testing (HALT)
Simulations under real-life conditions
End user trials
Panel or blind tests
Expert panels
) considering the selection criteria including criteria for regression validation. The documented selection of (Validation measure = Validation measure can be:
Operational use case testing under real-life conditions
Highly accelerated life testing (HALT)
Simulations under real-life conditions
End user trials
Panel or blind tests
Expert panels
) shall have sufficient coverage according to the (Release = A product delivered to a customer, including a defined set of functionalities and properties.) scope. Note 4: Examples for criteria for selection can be the (Release = A product delivered to a customer, including a defined set of functionalities and properties.) purpose of the delivered product (such as test bench, test track, validation on public roads, field use by end users), homologation/ type (Approval = Written statement that a deliverable is fit for its intended use, compliant with defined criteria.), confirmation of requirements, or the need for regression due to, e.g., changes to (Stakeholder requirements = Any type of requirement for the stakeholders in the given context, e.g., customer requirement, supplier internal requirements (product-specific, platform etc.), legal requirements, regulatory requirements, statutory requirements, industry sector requirements, international standards, codes of practice etc. …) and needs.
BP3
Perform the validation and evaluate the results. (
O2 )
Perform the validation of the integrated end product using the selected (Validation measure = Validation measure can be:
Operational use case testing under real-life conditions
Highly accelerated life testing (HALT)
Simulations under real-life conditions
End user trials
Panel or blind tests
Expert panels
). Record the validation results including pass/fail status. Evaluate the validation results. Note 5: Validation results can be used as a means for identifying stakeholder or (System = A collection of interacting components organized to accomplish a specific function or set of functions within a specific environment.) requirements, e.g., in the case of mock-ups or concept studies. Note 6: See SUP.9 for handling the validation results which deviate from expected results.
Linked Knowledge Nuggets: arrow_forward "Archiving test results"
personAuthor: Process Fellows
Don’t lose your evidence. With perspective to testing, SUP.8.BP1 in combination with SUP.8.BP8 expects structured storage of test logs, verdicts, anomalies, and configuration info. This is not only a formality: It enables you to later on reproduce details about a certain system version.
BP4
Ensure consistency and establish bidirectional traceability. (
O3 )
Ensure consistency and establish bidirectional traceability, if applicable, from (Validation measure = Validation measure can be:
Operational use case testing under real-life conditions
Highly accelerated life testing (HALT)
Simulations under real-life conditions
End user trials
Panel or blind tests
Expert panels
) to the (Stakeholder requirements = Any type of requirement for the stakeholders in the given context, e.g., customer requirement, supplier internal requirements (product-specific, platform etc.), legal requirements, regulatory requirements, statutory requirements, industry sector requirements, international standards, codes of practice etc. …) from which they are derived. Establish bidirectional traceability between the validation results and the (Validation measure = Validation measure can be:
Operational use case testing under real-life conditions
Highly accelerated life testing (HALT)
Simulations under real-life conditions
End user trials
Panel or blind tests
Expert panels
). Note 7: Examples of sources of (Validation measure = Validation measure can be:
Operational use case testing under real-life conditions
Highly accelerated life testing (HALT)
Simulations under real-life conditions
End user trials
Panel or blind tests
Expert panels
) from which they can be derived are legal requirements, homologation requirements, results of technical (Risk = The combination of the probability of occurrence and the consequences of a given future undesirable event.) analyses, or stakeholder and (System = A collection of interacting components organized to accomplish a specific function or set of functions within a specific environment.) requirements (see SYS.1 and SYS.2). Note 8: If sources of (Validation measure = Validation measure can be:
Operational use case testing under real-life conditions
Highly accelerated life testing (HALT)
Simulations under real-life conditions
End user trials
Panel or blind tests
Expert panels
) are, e.g., legal or homologation requirements, then direct bidirectional traceability from those sources to the (Validation measure = Validation measure can be:
Operational use case testing under real-life conditions
Highly accelerated life testing (HALT)
Simulations under real-life conditions
End user trials
Panel or blind tests
Expert panels
) are not possible. In such a case, unidirectional traceability is sufficient. Note 9: Bidirectional traceability supports consistency, and facilitates impact analyses of change requests, and demonstration of validation coverage. Traceability alone, e.g., the existence of links, does not necessarily mean that the information is consistent.
Linked Knowledge Nuggets: arrow_forward "Consistency vs. Traceability – What’s the Difference?"
personAuthor: Process Fellows
Consistency ensures that related content doesn’t contradict itself – e.g., requirements align with architecture and test. Traceability, in contrast, is about links: can you follow a requirement through to implementation and verification? Both are needed – consistency builds trust, traceability enables control. Typically, traceability strongly supports consistency review.
arrow_forward "The role of traceability in risk control"
personAuthor: Process Fellows
Traceability isn’t just about completeness — it’s about managing impact. When a requirement changes, trace links tell you what’s affected. That’s your early-warning system.
arrow_forward "The true benefit of traceability
"
personAuthor: Process Fellows
Sometimes the creation of traceability is seen as an additional expense, the benefits are not recognized.
Traceability should be set up at the same time as the derived elements are created. Both work products are open in front of us and the creation of the trace often only takes a few moments.
In the aftermath, the effort increases noticeably and the risk of gaps is high.
If the traceability is complete and consistent, the discovery of dependencies is unbeatably fast and reliable compared to searching for dependencies at a later stage, when there may also be time pressure.
It also enables proof of complete coverage of the derived elements and allows the complete consistency check.
BP5
Summarize and communicate the results. (
O4 )
Summarize the validation results and communicate them to all affected parties. Note 10: Providing all necessary information from the test case execution in a summary enables other parties to judge the consequences.
# OUTPUT INFORMATION ITEMS
13-52
Communication evidence (
O4 )
Evidence of interpersonal communication.Identifies:
Scope of information
Need for feedback, for example an expected confirmation within one week
Meta data, for example time when communication was done or how information was distributed.
Includes:
Personal information
Work-flows, for example within tools
Examples and References:
E-mails and other forms of memos
Verbal statements
Meeting minutes, for example in standups
Electronic media, for example webcasts, blog posts intranet forum
Chat protocols
Wiki pages
Photo protocol
Used by these processes:
ACQ.4 Supplier Monitoring
HWE.1 Hardware Requirements Analysis
HWE.2 Hardware Design
HWE.3 Verification against Hardware Design
HWE.4 Verification against Hardware Requirements
MAN.3 Project Management
MLE.1 Machine Learning Requirements Analysis
MLE.2 Machine Learning Architecture
MLE.3 Machine Learning Training
MLE.4 Machine Learning Model Testing
PIM.3 Process Improvement
REU.2 Reuse of Products
SUP.1 Quality Assurance
SUP.11 Machine Learning Data Management
SWE.1 Software Requirements Analysis
SWE.2 Software Architectural Design
SWE.3 Software Detailed Design and Unit Construction
SWE.4 Software Unit Verification
SWE.5 Software Component Verification and Integration Verification
SWE.6 Software Verification
SYS.1 Requirements Elicitation
SYS.2 System Requirements Analysis
SYS.3 System Architectural Design
SYS.4 System Integration and Integration Verification
SYS.5 System Verification
VAL.1 Validation
Used by these process attributes:
PA2.1 Process performance management process attribute
13-51
Consistency evidence (
O3 )
Evidence of information to be semantically coherent alongrelevant artifacts, ensuring completeness, purpose maturity of processes, (Task = A definition, but not the execution, of a coherent set of atomic actions.) and products throughout their lifecycle.Identifies:
Traceability information, for example hyperlinks, repository location or editorial references.
Naming conventions
Relevant artifacts
Revision and revision history information
Change documentation and analysis information
Includes:
Meta-information, for example database identifiers notes in Git commits comments
Examples and References:
Evidence of Definition of Done (DoD) adherence.
Used by these processes:
HWE.1 Hardware Requirements Analysis
HWE.2 Hardware Design
HWE.3 Verification against Hardware Design
HWE.4 Verification against Hardware Requirements
MAN.3 Project Management
MLE.1 Machine Learning Requirements Analysis
MLE.2 Machine Learning Architecture
MLE.3 Machine Learning Training
MLE.4 Machine Learning Model Testing
SUP.8 Configuration Management
SUP.10 Change Request Management
SWE.1 Software Requirements Analysis
SWE.2 Software Architectural Design
SWE.3 Software Detailed Design and Unit Construction
SWE.4 Software Unit Verification
SWE.5 Software Component Verification and Integration Verification
SWE.6 Software Verification
SYS.2 System Requirements Analysis
SYS.3 System Architectural Design
SYS.4 System Integration and Integration Verification
SYS.5 System Verification
VAL.1 Validation
08-59
Validation Measure (
O1 )
Tool or method used to ensure the accuracy and reliability of a (Measurement = The activity to find the size, quantity or degree of something.) or test under realistic conditions to validate the intended use.Identifies:
Description of test scope
(Measurement = The activity to find the size, quantity or degree of something.) to be performed during the test
Test steps description
Pass/fail criteria, for example from end user survey
Includes:
Simulation scenarios
Emulation
Entry criteria
Techniques and resources
Validation environment setup and configuration
Sequences
Used by these processes:
VAL.1 Validation
08-57
Validation Measure Selection Set (
O1 )
A set of (Validation measure = Validation measure can be:
Operational use case testing under real-life conditions
Highly accelerated life testing (HALT)
Simulations under real-life conditions
End user trials
Panel or blind tests
Expert panels
) selected for a specific purpose.Identifies:
(Validation measure = Validation measure can be:
Operational use case testing under real-life conditions
Highly accelerated life testing (HALT)
Simulations under real-life conditions
End user trials
Panel or blind tests
Expert panels
)
Scope of their application, for example a variant regression or a subcomponent
Includes:
Identification of the (Validation measure = Validation measure can be:
Operational use case testing under real-life conditions
Highly accelerated life testing (HALT)
Simulations under real-life conditions
End user trials
Panel or blind tests
Expert panels
)
Criteria for re-validation, for example in the case of changes
Dependencies
Used by these processes:
VAL.1 Validation
13-24
Validation Results (
O2 )
Documented evidence confirming whether the end product meets the intended use expectations.Identifies:
Data, logs, feedback, or documentation
(Measure = An activity to achieve a certain intent.) passed
(Measure = An activity to achieve a certain intent.) not passed
(Measure = An activity to achieve a certain intent.) not executed
Rationale, for example security claims
Information about the execution (date, participants etc.)
VAL.1
Validation
