# 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 (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 unidirectional 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 (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 consistency and bidirectional traceability is established between validation results and (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
Results of the validation are summarized and communicated to all affected parties.
# BASE PRACTICES
BP1
Specify validation measures for 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
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 (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
),
a definition of entry and exit 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
),
necessary sequence 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
), 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, and 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 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 physical 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 physical 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, and 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 validation and evaluate 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 requirements e.g, in the case of mock-ups or concept studies. Note 6: See SUP.9 for handling (Verification = Verification is confirmation through the provision of objective evidence that an element fulfils the specified requirements.) results that 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 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 validation results and (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 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 (Verification = Verification is confirmation through the provision of objective evidence that an element fulfils the specified requirements.) coverage. Traceability alone, e.g., the existence of links, does not necessarily mean that the information is consistent with each other.
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 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 )
All forms of interpersonal communication such as
e-mails, also automatically generated ones
tool-supported workflows
meeting, verbally or via meeting minutes (e.g., daily standups)
podcast
blog
videos
forum
live chat
wikis
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 Management of Products for Reuse
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 Performance Management
13-51
Consistency Evidence (
O3 )
Demonstrates bidirectional traceability between artifacts or information in artifacts, throughout all phases of the life cycle, by e.g.,
tool links
hyperlinks
editorial references
naming conventions
Evidence that the content of the referenced or mapped information coheres semantically along the traceability chain, e.g., by
performing pair working or group work
performing by peers, e.g., spot checks
maintaining revision histories in documents
providing change commenting (via e.g., meta-information) of database or repository entries
Note: This evidence can be accompanied by e.g., Definition of Done (DoD) approaches.
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 )
A (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
) can be a test case, a (Measurement = “The activity to find the size, quantity or degree of something”.), a simulation, an emulation, or an end user survey
The specification of a (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
) includes
pass/fail criteria for (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
) (completion and end criteria)
a definition of entry and exit 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
), and abort and re-start criteria
Techniques
Necessary validation environment and infrastructure
Necessary sequence or ordering
Used by these processes:
VAL.1 Validation
08-57
Validation Measure Selection Set (
O1 )
Include criteria for re-validation in the case of changes (regression).
Identification 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
), also for regression
Used by these processes:
VAL.1 Validation
13-24
Validation Results (
O2 )
Validation data, logs, feedback, or documentation
(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
) passed
(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
) not passed
(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
) not executed, and a rationale
Information about the validation execution (date, participants etc.)
VAL.1
Validation
