Verification coverage audit

The problem this solves

Coverage looks fine until someone reads it from the other side. A requirement can carry a linked test case that has never run, a test case can exist that proves nothing, and a hazard can rest on a mitigation whose latest run failed. The gaps only show when requirements and test cases are each read against the other, which is exactly what nobody has time to do by hand before an assessment.

How it works

Which requirements have no evidence, from both directions, with safety requirements first. Reads every requirement and its verification links, every test case and its runs, and reports coverage both ways: requirements without evidence, and test cases that prove nothing or have never been run.

Where this sits in the Regulation

Regulation (EU) 2023/1230 applies from 20 January 2027, and the technical file's test reports item is where this evidence lands; the file is kept for ten years after the machine is placed on the market. This audit reads the model and reports gaps: it is a readiness check, not a conformity assessment.

Audit verification coverage in the connected Dalus model. Do not modify the model.

Step 1. Read all requirements with customer ID, type, priority, status, verifications and assigned systems; all test cases with type, purpose, linked requirements and rationale, systems under test, procedure, runs, step results and attachments; and all hazards with mitigating requirements.

Step 2. Requirement side. For each requirement, determine evidence status:
- "verified": at least one linked test case with a run of status Passed, or a declared analysis, inspection or demonstration verification with a description
- "planned": linked test case exists, no Passed run
- "failed" or "blocked": latest run has that status
- "no verification": no verification declared and no test case linked

Step 3. Test case side. For each test case: linked requirements, whether each link has a rationale, systems under test, number of runs, latest run status, attachments present. Flag test cases with no linked requirements, no runs, or runs with failed or blocked steps.

Step 4. Safety view. For each hazard, list its mitigating requirements with evidence status. Flag any hazard where a mitigating requirement is not "verified".

Step 5. Findings, ranked: safety requirements not verified, then hazards with unverified mitigations, then other requirements with no verification, then test cases with no runs, then runs with failed or blocked steps, then links without rationale.

Step 6. Provenance: element IDs behind each finding.

Output: a findings report with coverage counts (requirements by evidence status, test cases by run status), the ranked findings, and provenance.

What you get

Common questions