The V-model is a systems engineering framework that pairs every requirement with a matching verification or validation activity. For medical device startups under MDR, it is the fastest way to produce the traceable evidence that EN ISO 13485:2016+A11:2021 clause 7.3 and MDR Annex II demand — without rebuilding your whole project six months before a Notified Body audit.

By Tibor Zechmeister and Felix Lenhard.

TL;DR

  • The V-model sits on the left-hand side of a V with decomposition (user needs, system requirements, subsystem design, unit design) and on the right-hand side with integration (unit test, integration test, system verification, validation).
  • EN ISO 13485:2016+A11:2021 clause 7.3 (design and development) does not name the V-model, but its required outputs map almost one-to-one onto a V-shaped flow.
  • EN 62304:2006+A1:2015 describes the software lifecycle in terms that are structurally identical to a V-model — planning, requirements, architecture, detailed design, implementation, then verification climbing back up.
  • MDR Annex II requires a complete design and manufacturing record with traceable verification and validation evidence. The V-model produces that record as a by-product of how you already work.
  • A startup does not need a dedicated systems engineer to use the V-model. It needs an artefact map — one page that lists every left-side artefact and its matching right-side evidence.

Why the V-model matters for medical device startups

Most early medical device teams do not fail because they cannot build their device. They fail because six months before the Notified Body audit they discover that the user needs in the pitch deck, the requirements in Jira, the schematics on the wall, and the test reports in a Dropbox folder cannot be linked to each other. The Notified Body asks one question — "show me how this requirement was verified" — and the founder spends three weeks reconstructing the answer.

The V-model is old. It comes from aerospace and defence systems engineering of the 1980s. It has survived because it answers exactly that question. Every item on the decomposition side of the V has a partner on the integration side. A user need is validated. A system requirement is verified at system level. A subsystem requirement is verified at subsystem level. A unit is tested in isolation. Nothing is orphaned.

For a two-person hardware-plus-software startup, that structure is not bureaucracy. It is the cheapest possible way to avoid retroactive documentation.

What MDR and EN ISO 13485 actually say

MDR Annex II §4 requires the technical documentation to contain "information to allow the design stages applied to the device to be understood" together with "complete information and specifications […] including manufacturing processes and their validation". Verification and validation results must be present in a form a Notified Body reviewer can trace.

EN ISO 13485:2016+A11:2021 clause 7.3 structures design and development in six sub-clauses that sit naturally on a V:

  • 7.3.2 Design and development planning
  • 7.3.3 Design and development inputs
  • 7.3.4 Design and development outputs
  • 7.3.5 Design and development review
  • 7.3.6 Design and development verification
  • 7.3.7 Design and development validation
  • 7.3.8 Design and development transfer
  • 7.3.9 Design and development changes
  • 7.3.10 Design and development files

Clause 7.3.3 requires inputs to be "functional, performance, usability and safety requirements". Clause 7.3.6 requires verification to "ensure that the design and development outputs have met the design and development input requirements". Clause 7.3.7 requires validation to confirm that the device meets "the requirements for the specified application or intended use". That is the V. Inputs on the left. Verification against inputs, and validation against intended use, on the right.

EN 62304:2006+A1:2015 mirrors the same shape for the software side. Clause 5 of EN 62304 walks through software development planning, requirements analysis, architectural design, detailed design (for Class B and C), unit implementation, integration and integration testing, system testing, and release. The hardware V and the software V run in parallel, meeting at system level.

EN ISO 14971:2019+A11:2021 sits across the V, not beside it. Risk controls identified in the risk management file become additional inputs on the left side and additional verification items on the right. MDR Annex I GSPR 1–9 are the upstream source of those risk-control inputs.

A worked example: a Class IIa wearable ECG patch

A three-person startup is developing a Class IIa single-lead ECG patch with a companion mobile app. They have eight months of runway and a Notified Body slot booked in nine months. Here is how a lean V-model looks in practice.

Left side — decomposition

  1. User needs — captured in a two-page document. Example: "A patient with suspected paroxysmal atrial fibrillation can wear the patch for up to 7 days and the treating cardiologist receives a report sufficient to confirm or exclude AF."
  2. Intended purpose — a one-paragraph statement. Intended purpose is defined in MDR Article 2(12) as "the use for which a device is intended according to the data supplied by the manufacturer on the label, in the instructions for use or in promotional or sales materials or statements and as specified by the manufacturer in the clinical evaluation".
  3. System requirements — roughly 60 items covering performance, electrical safety (tied to EN 60601-1), EMC (EN 60601-1-2), usability (EN 62366-1), biocompatibility (EN ISO 10993-1), battery life, data integrity, and cybersecurity (EN IEC 81001-5-1:2022).
  4. Hardware subsystem requirements and software subsystem requirements — derived from the system level, roughly 30 items each.
  5. Unit-level design — analog front-end specification, firmware module specification, app module specification.

Right side — integration

  1. Unit tests — bench tests on the analog front-end, unit tests on firmware modules, unit tests on app modules.
  2. Integration testing — hardware-in-the-loop tests, firmware on real hardware, app against firmware over BLE.
  3. System verification — full performance testing against the 60 system requirements. Includes third-party electrical safety and EMC testing.
  4. System validation — summative usability evaluation against intended use, plus the clinical evaluation that feeds MDR Article 61 evidence.

Every item on the right points back to the item on the left that it covers. That pointer is the trace link. When the Notified Body asks "how did you verify that the device detects AF with the stated sensitivity", the team points at a single test report line that traces back to a single requirement that traces back to a single user need.

The Subtract to Ship playbook — a lean V for a three-person team

A startup does not have a systems engineering department. It has a founder wearing three hats and a contractor who shows up on Thursdays. The V-model still works — but only if you subtract ruthlessly.

Step 1 — Draw the artefact map on one page. List every artefact the V requires: user needs document, system requirements specification, hardware requirements, software requirements (per EN 62304 clause 5.2), hardware architecture, software architecture (per EN 62304 clause 5.3), unit designs, unit test reports, integration test reports, system verification report, validation report, risk management file. One page. Print it. Stick it on the wall.

Step 2 — Pick exactly one tool for traceability. Not three. Not a mix of spreadsheets and Jira and Confluence. One tool where every requirement has an ID and every test points at requirement IDs. Polarion, Jama, Matrix Requirements, or even a disciplined spreadsheet are all acceptable. The worst choice is multiple tools.

Step 3 — Write requirements you can actually verify. A requirement that says "the device shall be safe" is worthless. A requirement that says "the device shall isolate the patient circuit from mains to 4 kV AC per EN 60601-1 clause 8.5" is verifiable. If you cannot write a test for it, it is not a requirement, it is a wish.

Step 4 — Plan verification at the same time as you write requirements. For each requirement, the author writes a single sentence: "how will I know this is met?" That sentence becomes the test. Doing this at requirement-writing time, not six months later, is the single biggest time saving in the V-model.

Step 5 — Treat risk controls as first-class requirements. Every risk control from EN ISO 14971 becomes a numbered requirement on the left side of the V, with a matching verification activity on the right. This is how you avoid the "risk file says we mitigated X but there is no test for it" finding that shows up in almost every first Notified Body audit.

Step 6 — Integrate in small cycles, not one big-bang. Hardware-in-the-loop integration every sprint, not once before the audit. You will find integration bugs that would otherwise ambush you in month nine.

Step 7 — Keep the V document-light. Clause 7.3 does not require separate documents for every sub-clause. A single design and development file that contains the plan, inputs, outputs, review minutes, verification reports, validation reports, and change records satisfies clause 7.3.10. For a Class IIa device this can be under 80 pages total, not 800.

Step 8 — Baseline before verification starts. Once you start running verification tests, the requirements are frozen under change control (clause 7.3.9). Any change after that point triggers an impact analysis. Without this discipline the trace matrix rots within a month.

The goal is not "we did the V-model perfectly". The goal is "at any point a Notified Body auditor can pull a thread from intended purpose down to a unit test and back up to validation, in under ten minutes". If that thread exists, you pass. If it does not, you fail — regardless of how thick your binders are.

Reality Check

  1. Can you draw your V on one page today, with every artefact listed and every trace link identified?
  2. Do you have a single source of truth for requirement IDs, or are requirements scattered across Jira, spreadsheets, and Word documents?
  3. For each of your top 20 system requirements, can you point at a single test report line that verifies it?
  4. Have the risk controls from your EN ISO 14971 risk management file been promoted into numbered requirements on the left side of the V?
  5. Does every software requirement trace down to a specific architectural element as required by EN 62304 clause 5.3?
  6. Is your design and development file a single controlled artefact under clause 7.3.10, or a folder of loose files?
  7. If your Notified Body booked an audit for next month, how many person-days would it take to reconstruct full traceability?

Frequently Asked Questions

Is the V-model required by MDR? No. MDR Annex II and EN ISO 13485:2016+A11:2021 clause 7.3 require design controls and traceable evidence, not a specific lifecycle model. The V-model is simply the most efficient way to satisfy those requirements for hardware-plus-software devices.

Can we use Agile inside the V-model? Yes. Agile sprints deliver work packages within each level of the V. The V describes the structure of artefacts; Agile describes the cadence of work. They do not conflict. The key is that at each baseline point the traceability is consistent.

How many requirements should a Class IIa device have? There is no correct number. A simple wearable may have 60 system-level requirements. A surgical robot may have 2,000. The rule is: enough requirements that every GSPR from MDR Annex I that applies, every risk control from EN ISO 14971, and every performance claim in your intended purpose is covered.

Does the V-model apply to software-only devices (SaMD)? Yes. EN 62304:2006+A1:2015 clause 5 is structurally a V. For a SaMD the hardware side of the V collapses to the hosting platform, and the software V becomes the whole lifecycle.

What is the biggest mistake startups make with the V-model? Writing requirements and tests in parallel but in different tools. The moment the trace link lives only in someone's head, the V has failed.

When should we start the V-model in a startup? Before you write your first line of production code or commit to a first hardware prototype. Starting earlier is always cheaper than starting later. The two-phase development approach treats early exploratory work as outside the V, then enters the V when the architecture is stable.

Sources

  1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex II, Annex I.
  2. EN ISO 13485:2016+A11:2021 — Medical devices — Quality management systems — Requirements for regulatory purposes, clause 7.3.
  3. EN 62304:2006+A1:2015 — Medical device software — Software lifecycle processes, clause 5.
  4. EN ISO 14971:2019+A11:2021 — Medical devices — Application of risk management to medical devices.