What you need
Use a requirements table, versioned configuration records and raw test data. Assign a responsible reviewer for safety-related work.
Read the diagram as a data table
| Condition or component | requirements |
|---|---|
| Passed | 18 |
| Unresolved | 2 |
The calculation
verified_fraction = passed_requirements / total_requirements
This fraction is a project-tracking measure, not a safety score. Requirements differ in importance and unresolved critical items cannot be averaged away.
Worked example
If 18 of 20 requirements pass, the verified fraction is 90%. If either remaining item concerns a dangerous power-loss condition, the robot is not ready for release despite the high percentage. Report the unresolved items by name.
Try it step by step
- Give each requirement an identifier, measurable acceptance condition and a planned test or analysis method.
- Record hardware, firmware, calibration and test-environment versions with the evidence for every result.
- Test abnormal conditions and recovery deliberately under an approved procedure, preserving raw observations and unresolved issues.
- Release only after required reviews are complete, and define which changes trigger recalibration, retesting or renewed safety assessment.
How to check the result
A reviewer should be able to trace a requirement to its raw evidence and reproduce the configuration that produced the result.
Common mistake to avoid
A checklist cannot certify itself. Independent expertise, applicable standards and legal obligations remain necessary where the real application requires them.
Reference reading
Primary references for the underlying models, APIs or application context. The worked numbers and plots above are educational calculations, not results reported by these sources.
