Das Zusammenführen der Softwareanforderungen

Du planst die Entwicklung einer digitalen Gesundheitsanwendung? Eine Software für Präventionsangebote, eine App auf Rezept, eine DiGA oder DiPA? Die Entwicklung eines Medizinproduktes als Software ist allein aufgrund der Regulatorik, den Gesetzen und Verordnungen in Deutschland ein großes und potenziell kostspieliges Vorhaben. Ein DiGA- oder DiPA-Projekt muss gut durchdacht und geplant sein. In unserer Serie möchten wir dir die wesentlichen Themen und Schritte aufzeigen, die bei der Planung, Konzeption und Umsetzung von eHealth-Lösung zu beachten sind.

In vorherigen Folgen haben wir erarbeitet, wie eine Produktvision entsteht. Dabei haben wir über Zielgruppen und Stakeholder, Usecases und User-Journey gesprochen und am Ende einen Funktionsumfang, Struktur und Inhalt der App definiert. All diese Beschreibungen und Anforderungen an die Software gehören nun dokumentiert.

Insbesondere bei der Entwicklung von Medizinprodukten erwartet die Regulatorik die Erstellung eines sogenannten Softwareanforderungsdokumentes, kurz SRS (englisch für Software Requirement Specification). In diesem Dokument werden all die Arbeitsergebnisse der Konzeptions- bzw. Design Thinking-Phase zusammengetragen und ergänzt durch die Wireframes, Screenflows und Designs. Das Ziel ist eine möglichst klare fachliche Beschreibung der Produktvision, des Produktes inkl. der fachlichen als auch nicht-fachlichen Anforderungen an das Endprodukt.

Das Dokument ist dann gut, wenn Dritte, die bisher nicht am Projekt beteiligt waren, mithilfe dieses Dokuments eine klare und möglichst unmissverständliche Vorstellung der Produktvision und des Funktionsumfangs erhalten.

Die größte Herausforderung dabei ist, sich nicht in einer Granularität der Beschreibungen und Dokumentation zu verlieren. Ja, es braucht eine gesunde Tiefe an Erklärung, aber zu detailliert sollte es noch nicht sein, denn die „Feinspezifikation“ folgt bei einer agilen Softwareentwicklung zu einem späteren Zeitpunkt.

Auch technische Aspekte sind nur dann in dem SRS zu definieren, wenn diese für die Beschreibung von Funktionalitäten oder Anforderungen notwendig sind. Ansonsten sollten diese Spezifikationen eher in einem Softwarearchitektur-Dokument einfließen, was wir in einer späteren Folge nochmal genauer erklären.

Ein Tipp: Das Dokument ist eine lebende Dokumentation. Selbstverständlich kommt es im Laufe des Projektes bzw. in der Umsetzung dazu, dass nochmal nachgesteuert werden muss oder Spezifikationen sich verändern. Wichtig ist, dass auf eine saubere Versionierung früherer Spezifikationen geachtet wird. Nur so stellen wir nicht nur sicher, dass man Veränderungen jederzeit nachvollziehen kann, sondern auch die regulatorischen Anforderungen an der Entwicklung von Medizinprodukten beachtet werden.

Das SRS Dokument ist die Grundlage für jegliche weitere Feinspezifikation und Vorbereitung von sogenannten Epics und Userstories für die Entwicklung bzw.

Umsetzung. Was genau da vorbereitet werden sollte und wie genau dies funktioniert, erklären wir in einer der späteren Folge.