Development process: Lean and compliant with standards


Laws and standards formulate requirements on how medical device manufacturers must define and document development processes. Notified bodies check these requirements during audits.

This article on development processes provides tips on how to design the processes and how to align it with other processes, such as the risk management process.

1. Development process: Basics

a) Definition

Development processes define how the roles involved in the development perform which activities and in which order in order to transform given inputs into outputs.

Elements to be determined


Activities (what?)

Verify the system requirements

Define the architecture

Derive test cases

Perform tests

Order of activities (when?)

Sequential (waterfall model), parallel or iterative

Methods and procedures


Inspection with checklist to review a document

Modeling with UML to describe an architecture

Black box test procedure for the systematic derivation of test cases

Roles involved (who?)

Head of engineering

Software architect

Software developer



Stakeholder requirements

Organizational requirements


Construction plans (e.g., architecture)

Software code

Test results

Tab. 1: Elements that a development process must determine


b) Objectives

Defining a development process is part of the constructive quality assurance, i.e., quality assurance with the objective of avoiding errors.

From a regulatory point of view, the process for medical devices should ensure that the devices have the specified safety, performance, and effectiveness.

Furthermore, the process should contribute to efficiency:

  • For example, resources are used in the best possible way.
  • The people involved in the development process are coordinated in the best possible way.
  • The development project is completed in the planned time.
  • Last but not least, development risks are identified at an early stage.

2. Regulatory requirements for the development process


Most regulations and standards follow a process-oriented approach. They therefore impose requirements on the processes.

Regulatory documents

Requirements for the processes

Medical Device Regulation (MDR)

The QM system describes the processes and procedures. The software-lifecycle processes must be defined.

IEC 62304

The standard requires the establishment of five processes, including a development process.

ISO 13485

The standard follows a process-oriented concept. It requires a total of 25 procedures, among others for development.

ISO 14971

The standard requires a risk management process. This should be coordinated with the development process (see chapter 4).

IEC 62366-1

The standard requires a usability engineering process. This should be coordinated with or integrated into the development process (see chapter 5).

IEC 60601-1

At least for programmable electrical medical systems, the standard insists on a development process. In the appendix, it shows a process model similar to the V-model (see Fig. 1).

Tab. 2: Regulatory requirements for the development process


None(!) of the regulations requires a specific process model.

Read below how you can avoid redundant efforts and problems in the audit by aligning the development process and the risk management and usability engineering process.

3. Practical tips for the development process

Tip 1: Use the V-model as a documentation model

Most companies work according to a waterfall, V-model, or agile process model.

Further information

Read more about agile software development.

No matter which process model you decide on, you must


1. commit to one model (at least per project) and document your decision,

2. work according to this process model and thereby

3. perform and document the activities required by the regulations.


These activities must result in documents as they would in the V-model (see Fig. 2). However, this does not mean that manufacturers must develop according to the V-model.


Be sure to note!

Note that you complete all activities on the left side in Fig. 2 (i.e., all documents) with a verification before releasing them.

Tip 2: Benefit from agile development process and avoid pitfalls

In practice, iterative-incremental approaches prove their worth. This is because it is usually not possible to achieve the outputs of a phase / activity completely and correctly right away. This is evident, for example, when eliciting stakeholder requirements and creating the architecture. For example, it is usually not possible to determine the time behavior and resource consumption (e.g., CPU) without experimentation.

However, even with an iterative and incremental approach, the manufacturer must not refrain from verifying the outputs of a previous activity before starting the next one. Nor is it efficient to replace systematic requirements engineering with a try-and-error approach.

Read more about the pitfalls in this article on agile (software) development.

Tip 3: Scoping the development process correctly

Fig. 2 suggests that the development process covers all activities. While the manufacturer must cover all activities through a process; it makes perfect sense that the development team is only responsible for the activities that come after the elicitation and validation of stakeholder requirements.

In addition, the development team can limit the description of the development process to its area of responsibility (see Fig. 3). Then the elicitation of the requirements would be regulated by another process.

Tip 4: Separate research and development

It is helpful to free the research team as much as possible from regulatory constraints. After all, its objective should also be to minimize development risks by testing (researching) solutions and technologies.

4. Interaction with the risk management process

a) Problem definition

Most standards relevant to medical device development, such as ISO 13485, ISO 14971, IEC 62304, and IEC 62366-1, impose requirements on processes.

To meet these requirements, many medical device manufacturers formulate process and procedure descriptions (SOPs) - separately for each of these processes. As a result, those involved in development must follow several of these SOPs at the same time. Errors are then almost inevitable.

b) Solution

Although the following figure shows a V-model, the considerations are independent of it.


The description of the development process should include references to the relevant activities in the risk management process at each stage. This ensures that risk management is not forgotten.

Individual phases



Phase in the development process

Activities in the development process

Activities in the risk management process


 Context   and  business   model

Define the business expectations and context for the device
Formulate intended purpose / use

Start the risk analysis with a preliminary hazard analysis. It is already obvious from the intended purpose / use which hazards and risks the device causes.


 Stakeholder   requirements

Identify stakeholder requirements

Determine state of the art

Determine risk policy and the risk acceptance criteria


 System   specification

Derive system requirements and system specifications. In doing so, define requirements for the device from a black box view and thus its inputs and outputs.

The input and output analysis helps to identify further hazards and risks. With this part of the risk analysis, manufacturers should be able to complete the preliminary hazard analysis and, thus, the identification and assessment of the most important hazards or risks.


 System design

Design product or system, e.g., create architecture, create software design, design isolation diagrams

The risk analysis can be completed when requirements have been transformed into a solution. The way the device is to be built introduces additional risks or helps to minimize them.

Risks can be identified with an FMEA. At the same time, planning of the measures that minimize the risk and with which the functional safety of the device must be achieved begins at this stage at the latest.


 Implementation   and verification

Programming software

Build first devices (prototypically)

Verify both with tests, e.g., software system test

Verify effectiveness of risk mitigation measures



Validate device, e.g., with summative evaluation (usability tests) and clinical evaluation

The purpose of validation is to demonstrate not only the safety of the devices, but also their benefits, and thus that the risk-benefit ratio is acceptable.


 Production and   post-production   phase

No longer subject to development

Identifying risks during production, shipping and putting into service

As part of post-market surveillance, ongoing inspection to ensure that all risks are fully and correctly assessed and are still acceptable in comparison to the benefit

Tab. 3: "Mapping" of activities in the development process and risk management process

5. Interaction with the usability engineering process


Quality management and usability engineering are closely interrelated as well: While ISO 13485 formulates general concepts and requirements, IEC 62366-1 provides concrete requirements in the context of usability. This article shows the mapping of both standards.

Quality Management

ISO 13485

IEC 62366-1

Chapter 6.1: Provision of resources

4.3 Adjusting the usability engineering effort

Chapter 6.2: Human resources

4.1.1 Usability engineering development process

Chapter 7.1: Product realization planning

4.3 Adjusting the usability engineering effort

Chapter 7.3.2 Development planning

5.5 Selecting the hazard-related use scenarios for the summative evaluation

5.7 Creating a plan for the user interface evaluation

Chapter 7.3.3 Development inputs

5.1 Creating the use specification

5.2 Determine characteristics of the user interface with respect to safety and possible

use errors

5.3 Identify known or foreseeable hazards and hazardous situations.

5.4 Identify and describe hazard-related use scenarios.

5.6 Create the user interface specification

Chapter 7.3.4 Development outputs

5.8 Performing user interface design, implementation, and formative evaluation

Chapter 7.3.5 Development review

5.8 Performing user interface design, implementation, and formative evaluation

Chapter 7.3.6 Development verification

5.8 Performing user interface design, implementation, and formative evaluation
5.9 Performing the summative evaluation of the usability of the user interface

Chapter 7.3.7 Development validation

5.8 Performing user interface design, implementation, and formative evaluation
5.9 Performing the summative evaluation of the usability of the user interface

Tab. 4: Interaction of the processes according to ISO 13485 and IEC 62366-1

6. Conclusion and summary


Manufacturers should spend enough energy to describe their development process(es) precisely and specifically. Because otherwise, problems are imminent.


Possible consequences

In the worst case, the process is not described at all or not described completely.

This leads to non-conformity (notified bodies react sensitively when processes are not defined and lived).

There is a risk of chaos in development

The process is described inaccurately.

Regulatory requirements are not met, and discrepancies loom in audits.

The team does not know how to proceed, resulting in unsafe devices and delayed projects.

The process is described accurately but inappropriately.

The team (rightly) perceives the process as bureaucratic and obstructive.

The team either deviates from the process (non-conformance) or it works inefficiently and ineffectively.


The effort pays off: With a good development process, development projects lead quickly and predictably to safe devices, satisfied customers and economic success.


Prof. Dr. Christian Johner

Find out what Johner Institute can do for you

A quick overview: Our


Learn More Pfeil_weiß

Always up to date: Our


Learn More Pfeil_grau

Privacy settings

We use cookies on our website. Some of them are essential, while others help us improve this website and your experience.