Agile Compliance - IEC 62304 explained for agile teams

Below is an overview picture taken from 62304 explaining what you need to do from a regulatory view.

Each of these boxes above become documents to deliver together with other documents with the proof that you followed some processes mentioned in the standards.

Let’s look at one example “5.2 Software requirements analysis”

Before you start ‘analyzing’ the requirements you need to have the software development plan in place, which tells you where the software requirements come from (e.g. product requirements, risk analysis, etc), how these software requirements are reviewed to ensure they are complete, correct, don’t contradict each other etc. Besides planning these activities the standard requires you to document the results and prove (“objective evidence”) that you followed your plan:

Example: documentation related to 5.2 software requirements analysis

The principle is the same for all levels of your software development activities, you need documents which:

• describe what you want to do (development plans, verification plans …);

• the results of following the plans (requirements, tests descriptions, …);

• proof that the results are correct (verification and validation) and processes have been followed (minutes, reviews, …).

Types of documents to be created

One important aspect in the above documents is the traceability, so for example you need to be able to list all requirements for your software and link them to their sources (are these coming from the user, intended use or are risk controls?) and their children (e.g. how are they tested, how does that translate in architecture or do I need some third party libraries).

A common view to visualize these two needs (the documents and the traceability between) is the V-Model. There’s many variations of that but the principle is this:

Common visualization: A simplified V-model

Coming from the agile world there this obviously conflicts with the agile manifesto that says “Working software over comprehensive documentation”. And indeed, if you need to comply with the standards there is no way you can avoid the documentation. If you are not willing to create some documentation, change the industry... BUT you can achieve this working with modern agile software development principles, adding only a small extra effort to create up-to-date documentation needed for certification.