Systematisches Requirements-Engineering (Teil 2)
Mit System zum Erfolg
Softwareintensive medizinische Systeme stehen unter einem immensen Marktdruck. Während sie technologisch und hinsichtlich Sicherheit kompromisslos innovativ sein müssen, fordern die Krankenhäuser und auch Gesundheitsreformen eine immer kürzere Zykluszeit bei gleichzeitig angespannten Budgets. Daher nimmt das Requirements-Engineering eine Schlüsselrolle als Erfolgsfaktor für Projekte und Produkte im Gesundheitswesen ein. Nachdem der erste Teil dieses Beitrags systematisches Requirements-Engineering allgemein näher beleuchtete [1], folgen nun einige Tipps aus der Praxis.
Bei medizinischen Systemen sind traditionelle Entwicklungsprozesse kaum noch zeitgemäß, da Innovation und Qualität über einen schwerfälligen Prozess erreicht werden. Viele Unternehmen ändern daher ihre Entwicklungsansätze in Richtung iterativer und Concurrent-Engineering-Ansätze [4]. Diese Fallstudie zeigt Erfahrungen und bietet Orientierung hin zu Requirements-Engineering in medizinischen Systemen.
Im Gesundheitswesen beschleunigt sich die Innovationsrate ständig, und entsprechend wachsen die Anforderungen an die Medizintechnik. Heute sind ein Drittel aller Produkte jünger als drei Jahre, Tendenz sinkend. Beispielsweise stieg die Verbreitung von medizinisch-technischen Geräten um 52 Prozent im Zeitraum von 2000 bis 2009.
Software ist demnach heute die Schlüsselkomponente in der Automatisierung von klinischen Abläufen schlechthin. Der Softwaregehalt eines medizinisch-technischen Geräts lag im Jahr 2000 etwa bei 30 Prozent, aktuell liegt dieser Wert bei mehr als 60 Prozent. Während Medizingeräte global entwickelt werden, müssen regulatorische Freigaben pro Markt erreicht werden. Ohne ein systematisches Requirements-Engineering ist die Wahrscheinlichkeit hoch, dass ein Projekt scheitert.
Werden beispielsweise die Qualitätsanforderungen missverstanden, entstehen zum Beispiel Probleme in der Benutzbarkeit und der Performance. Ärzte und Krankenpfleger sind Entscheidungsträger für oder gegen ein Produkt. Ist beispielsweise das Portfoliomanagement für das Produkt von der Entwicklung entkoppelt, passen die Funktionen nicht zu den Marktanforderungen.
Anforderungsänderungen werden erst zu spät erkannt und führen zu unnötigen Kosten für die Nacharbeiten (Non-Conformance-Kosten). Da klinische Abläufe aufgrund der hohen kombinatorischen Komplexität und einer eher geringen Standardisierung sowie ihres Ad-hoc-Charakters nur schwer zu modellieren sind, muss das Requirements-Engineering spezifische Techniken für die Medizintechnik und das Gesundheitswesen entwickeln.
Konkretes Beispiel
Im Folgenden wollen wir den Nutzen des systematischen Requirements-Engineering anhand der Entwicklung der Benutzerschnittstelle (User Interface, UI) für ein klinisches Abrechnungssystem darstellen. Das Projekt wurde in 18 Monaten mit vierzig Mitarbeitern in sechs Scrum-Teams bestehend aus Requirements-Ingenieuren, UI-Designern, Architekten, Produktmanagern und Subject-Matter-Experten umgesetzt (siehe auch Kasten »Was bedeutet Scrum?«).
| Was bedeutet »Scum« ? |
|---|
| Scrum (engl. Gedränge) ist ein Vorgehensmodell der Softwaretechnik. Der Ansatz von Scrum ist empirisch, inkrementell und iterativ. Er beruht auf der Ansicht, dass die meisten modernen Entwicklungsprojekte zu komplex sind, um durchgängig planbar zu sein. Scrum versucht, die Komplexität durch drei Prinzipien zu reduzieren: Transparenz (der Fortschritt und die Hindernisse eines Projektes werden täglich und für alle sichtbar festgehalten), Überprüfung (in regelmäßigen Abständen werden Produktfunktionen geliefert und beurteilt) und Anpassung (die Anforderungen an das Produkt werden nicht ein und für allemal festgelegt, sondern nach jeder Lieferung neu bewertet und bei Bedarf angepasst). |
Projektziele waren das Redesign der Schnittstelle hin zu besserer Benutzbarkeit, da dies das Schlüsselkriterium der Kaufentscheidung bei klinischen Informationssystemen darstellt. Lean-Development wurde mit Requirements-Engineering kombiniert, um die Anforderungen kundenorientiert zu spezifizieren und schrittweise zu verfeinern. Zudem musste ein innovativer klinischer Workflow beispielsweise für das Bettenmanage-ment umgesetzt werden.
Erfahrungswerte
In dem beschrieben Projekt wurden die folgenden Erfahrungen (Best Practices) gemacht, die auch in anderem Kontext nutzbar sind:
- Saubere Trennung von Problem- und Lösungsraum: Die Entwicklung einer Lösung beeinflusst die Sicht auf eine Problemstellung und kann somit zu falschen Lösungen führen (Bild 1). Trennt man Problem- und Lösungsraum sauber, reduziert dies die späteren Änderungswünsche effektiv.
- Entwickeln eines geeigneten Verständnisses von Kundenanforderungen: Kunden haben oft implizites komplettes Verständnis für
- die Anforderungen. Dazu kommt ein Glossar zum Einsatz, das immer den Bezug zur Nutzersprache gewährleistet, sowie Rapid-Prototyping zur Erstellung von Benutzerschnittstellen-Konzepten.
- Nutzung von Storyboards für Workflows mit hohem User-Interface-Anteil: Dabei dient das Storyboard als Container für Anforderungen, UI-Visualisierung sowie Testfälle.
- Verwendung strukturierter Anforderungen zur Planung und Budgetierung: Am Projektanfang muss man einiges für die Strukturierung spendieren. Die Erfahrung zeigt, dass Projektleiter dafür etwa acht bis zehn Prozent des Projektbudgets veranschlagen sollten. Die Anforderungen sollten am besten entlang bestimmter funktionaler (z.B. klinischer) Domänen hierarchisch organisiert werden [4].
- Entwicklung eines geeigneten Traceability-Modells: Traceability muss mit einer klaren Zielstellung und inhaltlichen Orientierung aufgebaut sein (Tabelle 1). Dies ist bei medizinisch-technischen Anwendungen von entscheidender Bedeutung, um die Marktzulassung zu erhalten. Wesentlich ist dabei, die Abhängigkeitsbeziehungen zu pflegen. Vorab sind daher die Verantwortungen festzulegen und der nötige Aufwand einzuplanen.
- Disziplinierter Einsatz von Standards und Reviews: Vector
- empfiehlt den Einsatz von Industriestandards, die an die Notwendigkeiten des Projektes angepasst werden. Dokumentenvorlagen erlauben es, die Dokumentationsstandards einzuhalten.
- Mit System zum Erfolg
- Mit System zum Erfolg
Lesen Sie mehr zum Thema
