Requirement Engineering: Gute Healthcare-Software beginnt lange vor dem ersten Code

Genau darum geht es im Requirement Engineering, kurz RE. Gemeinsam mit Benutzer:innen, Fachpersonen und Stakeholdern schaffen wir ein klares Verständnis für Anforderungen, Ziele und Bedürfnisse.

In diesem ersten Teil unserer RE-Serie zeigen wir, warum diese Phase für erfolgreiche Softwareprojekte im Gesundheitswesen entscheidend ist und weshalb wir bei healthinal Benutzer:innen von Anfang an aktiv einbeziehen.

Warum Requirement Engineering wichtig ist

Requirement Engineering bildet die Grundlage jedes Softwareprojekts. Ziel ist es, gemeinsam zu verstehen, was gebaut werden soll und warum.

Gerade im Gesundheitswesen treffen viele unterschiedliche Anforderungen aufeinander. Prozesse sind komplex, Rollen verschieden und Bedürfnisse nicht immer deckungsgleich. Genau deshalb braucht es einen offenen und nachvollziehbaren Austausch zwischen allen Beteiligten.

RE hilft dabei, Anforderungen sichtbar zu machen, Prioritäten zu klären und Entscheidungen gemeinsam zu treffen. So entstehen Lösungen, die nicht nur technisch funktionieren, sondern im Alltag wirklich unterstützen.

Klar definierte Anforderungen reduzieren das Risiko, am tatsächlichen Bedarf vorbeizuentwickeln. Gleichzeitig braucht nicht jedes Detail von Beginn an eine endgültige Entscheidung. Wichtig ist ein pragmatisches Gleichgewicht zwischen klarer Richtung und iterativer Weiterentwicklung.

Deshalb dokumentieren wir Entscheidungen transparent und entwickeln Anforderungen laufend weiter, sobald neue Erkenntnisse dazukommen.

Benutzerzentriert statt theoretisch

Bei healthinal orientieren wir uns stark an den Prinzipien von Design Thinking und der internationalen Norm für menschenzentrierte Gestaltung interaktiver Systeme (ISO 9241-210). Im Zentrum steht ein iteratives und nutzerorientiertes Vorgehen, damit eine gute User-Experience (UX) entsteht.

Das bedeutet: Anforderungen entstehen nicht einmalig und verschwinden danach in einem Dokument. Wir überprüfen und schärfen sie laufend gemeinsam mit Benutzer:innen und Stakeholdern.

Konkret beinhaltet der benutzerorientiere Prozess folgende Phasen:

• Kontext der Benutzer:innen verstehen
• Anforderungen erheben und spezifizieren
• Lösungsansätze entwickeln mittels Prototypen
• früh mit Benutzer:innen testen und evaluieren

‍

Diese Schritte wiederholen wir bewusst mehrfach. So entstehen Lösungen, die verständlich, anwendernah und prozessintegriert sind.

Gleichzeitig entspricht dieses Vorgehen auch zentralen agilen Prinzipien: enger Austausch, frühe Validierung und die Bereitschaft, Annahmen zu hinterfragen und Lösungen weiterzuentwickeln.

Design Sprints machen Anforderungen greifbar

Eine Methode, die wir im Requirement Engineering oft einsetzen, sind Design Sprints.

Dabei konkretisieren wir Anforderungen, Prozesse und erste Lösungsansätze gemeinsam mit Stakeholdern innerhalb kurzer Zeit. Statt lange über theoretische Konzepte zu diskutieren, entstehen schnell greifbare Resultate wie Workflows, Skizzen oder erste Prototypen. Diese können wir direkt mit Benutzer:innen testen und weiterentwickeln.

Der grosse Vorteil: Alle Beteiligten arbeiten gemeinsam an derselben Herausforderung. Fachbereich, UX, Entwicklung und weitere Stakeholder bringen ihre Perspektiven früh ein. Offene Fragen werden direkt diskutiert und Risiken sichtbar gemacht.

So entsteht schneller ein gemeinsames Verständnis und eine klare Richtung für das Projekt. Besonders wirkungsvoll sind Design Sprints dann, wenn offen, kollaborativ und interdisziplinär gearbeitet wird.

Flexibel statt starr: Design Sprints in der Praxis

Design Sprints müssen nicht immer exakt nach Lehrbuch in 5 Tagen ablaufen. Je nach Projekt passen wir einzelne Phasen flexibel an.

So sind wir auch beim Projekt SMC:Patient vorgegangen.

Gemeinsam mit allen relevanten Stakeholdern haben wir zuerst Vision, Ziele und Risiken definiert. Danach analysierten wir bestehende Workflows und entwickelten erste Lösungsansätze. Weitere Priorisierungen und Entscheidungen folgten später in zusätzlichen Sessions.

Auf dieser Basis entstand ein Figma-Prototyp, den wir anschliessend in mehreren Usability-Tests überprüften. Die Resultate bestätigten zentrale Annahmen und gaben uns Sicherheit für die weitere Entwicklung.

Heute ist die SMC:Patient live und stösst bei Praxen und Patient:innen auf positive Resonanz. https://www.healthinal.com/smart-managed-care#section-for-doctors

Das Projekt zeigte, wie wertvoll ein gemeinsames, praxisnahes und transparentes Vorgehen bereits in frühen Projektphasen ist.

Fazit

Requirement Engineering ist weit mehr als reine Anforderungsaufnahme.

Es schafft die Grundlage dafür, dass digitale Lösungen im Gesundheitswesen verständlich, langlebig und alltagstauglich werden.

Bei healthinal verstehen wir RE als partnerschaftlichen Prozess. Offen, praxisnah und immer gemeinsam mit den Menschen, die später mit der Software arbeiten.

In den nächsten Teilen unserer RE-Serie zeigen wir, wie aus ersten Anforderungen Schritt für Schritt konkrete und überprüfbare Lösungen entstehen.