Risk Analysis Mid-Section, During Design and Development
Design and Development, Design Validation, Design Verification, Risk Analysis
In a previous Device Tip, I discussed the value of putting mitigations derived from Risk Analysis into the product requirements and specifications to ensure that the mitigations will be implemented in the actual product design. Continuing on this topic, in this tip I want to address the “mid-section” of Risk Analysis – verification and validation (V&V).
Risk Analysis V&V takes place at three stages in the product lifecycle:
- during design and development (design risk mitigation)
- during design transfer (process risk mitigation)
- during manufacturing and commercial shipment (design and process risk mitigation)
This Device Tip will focus on the 1st stage in the product lifecycle (design and development). Here’s the tip:
- during and at the completion of design, utilize Design Verification to confirm that design risk mitigations have been implemented and operate correctly
- at the completion of design, utilize Design Validation to confirm that design risk mitigations are effective to mitigate the specified risk cause
The implementation and operation of risk reduction measures should be done no differently from any other requirement or specification. In the 2nd case, the specific hazards being mitigated (i.e. operational hazards or failure modes) will be intentionally created to be able to confirm that design mitigations are effective to mitigate the specified risk cause. Thus Design V&V ensures that the product design itself has reduced risks from use hazards and design failure modes, to acceptable levels.
More details on Risk Management during Design and Development
During Design and Development, similar to well written requirements and specifications, well written risk reduction measures (aka “mitigations”) will pay big dividends when it comes to Design Verification and Design Validation. Again, the standard of “complete, clear and non-conflicting” is a good test.
For instance, say your device uses software to control key functions such that, if a critical variable used by the software gets corrupted, a significant hazard would exist. And say, the initial risk assessment (combination of probability of occurrence and severity of resulting harm) is unacceptable, and thus risk reduction is required. And say the risk analysis team decides to implement redundant, inverted storage and checking of this critical variable prior to use in calculations.
If the mitigation is written as “internal software check”, it’s next to impossible to write a Design Verification test to confirm that mitigation has been implemented and operates correctly. On the other hand, if the mitigation is written as “Implement redundant, inverted storage and checking of variable <variable name> prior to use in calculations”, the resulting Product Requirement would be “Implement redundant, inverted storage and checking of variable <variable name> prior to use in calculations”.
The resulting Software Requirement in the SRS would be “The software shall implement redundant, inverted storage and checking of variable <variable name> prior to use in calculations”, and the Software Verification Test would be “Verify that the software implements redundant, inverted storage and checking of variable <variable name> prior to use in calculations”.
This seems almost too simple to be “technical enough”, but I guarantee it’s clear (aka unambiguous) and complete. And since the actual variable name (or at least name for the variable) is used, it can be cross-checked to ensure it doesn’t conflict with another requirement for that variable.
Now when it comes to designing the actual Design Verification for this mitigation:
- Code Review can be adequate to verify that the mitigation has been implemented correctly.
- A Software Verification test can be created wherein the variable is actually corrupted (the actual cause of the hazard) and the software function is verified to ensure that the implementation of the mitigation operates correctly.