Folge #59 – Requirements Engineering

Kommt zum Hauptthema Requirements Engineering und lösen später auch warum das überhaupt was mit eHealth zu tun hat. Das ist hier eigentlich etwas was klassisch in die ganz normale Informatik reingehört und vielleicht am Anfang was ist Requirements Engineering. Erst mal Requirement ist der englische Begriff für Anforderungen. Anforderungen sind wünsche Vorstellungen, Ideen, was dann ein zukünftiges Softwaresystem leisten soll. Und Requirements Engineering nennt man dann den Prozess, wie man diese Anforderungen ermittelt, wie man die dokumentiert, wie man die vielleicht so spezifiziert, dass nachher die Entwickler damit etwas anfangen können. Und genau darum kümmern wir uns heute damit. 

Vielleicht eine Vorwarnung vorweg. Ich finde das ist ein super, super wichtiges Thema und spannendes Thema und ich glaube, dass zumindest bei den Projekten, die ich so vielleicht auch nebenberuflich betreue oder auch in meiner Zeit in der Industrie betreut habe, dass ein Großteil der Projekte gescheitert, oder die gescheitert sind daran gescheitert sind, dass man sich eben am Anfang nicht die Zeit genommen hat und sich genau anzuschauen, was braucht in der Benutzer später. Gibt er so einen so einen schönen Informatik-Spruch-Garbage In, Garbage Out, wenn man sich am Anfang die Zeit nimmt, sondern einfach losentwickelt und schlechte Anforderungen hat, dann kann natürlich am Ende kein vernünftiges System herauskommen. Und wie cool solche Methoden sind zum Requirements Engineering habe ich selbst noch festgestellt, es gab mal einen Studentenprojekt und die haben als Anforderungen gehabt, ich möchte auf meinem Handy den Stundenplan haben. Dann habe ich mit den Interview gemacht und nachher ist rausgekommen, dass die den Stundenplan brauchen, weil sie abhängig vom Campus, wo die Vorlesung am nächsten Morgen stattfindet, abhängig von der Uhrzeit und abhängig vom Wetter, wissen wollen, wann sie morgen aufstehenden wollen. Das ist also die Anforderung. Sie brauchen die Informationen, um zu entscheiden, wann sie den Wecker stellen wollen. Die haben jetzt da leider die Lösung beschrieben, nämlich ich will einen Stundenplan auf dem Handy haben. Wenn man nicht direkt die Lösung aufschreibt, sondern die Anforderungen, dann können vielleicht eine viel kühlerere Lösung rauskommen. Zum Beispiel, dass das Handy sich abends meldet, um 21 Uhr und sagt pas mal auf, du hast morgen am Campus süd, um 9 Uhr eine Vorlesung, das Wetter soll gut sein, deswegen kannst du dann beim Fahrrad fahren, soll ich für dich den Wecker auf 7.30 stellen. Das ist ja eigentlich nur eine viel bessere Lösung und sowas kommt heraus, wenn man dann wirklich sauberer Anforderungserhebungsmethoden nutzt. Da war ich dann total begeistert, hab gedacht, bau wie cool ist es, wenn man also wirklich den Prozess durchgeht, kann so eine innovative Lösung herauskommen. Gott sei Dank, haben wir danach, bevor die das entwickelt haben. Noch mal die Kano-Umfrage gemacht, dass es eine Methode zu validieren, ob das tatsächlich eine gute Anforderung ist und da hast dann herausgekommen. Nee, das interessiert die Studenten gar nicht. Warum? Weil die alle in Studenten wohnen, haben rund um den Campus wohnen und die nach zwei Wochen sowieso wissen, dass sie dann Dienstags um 9.30 an der Fachhochschule sein müssen zum Beispiel. Und da hat es mir gezeigt, wenn man sich ein bisschen Zeit, ein bisschen sich damit beschäftigt, kann man erstens auf richtig coole Lösung kommen für die Probleme. Könnte richtig gute Software bauen und wenn man nachher noch validiert, die Ideen, die man hatte, ob die tatsächlich relevant sind, kann man sich auch Entwicklungszeit sparen, also dass man nicht nachher irgendwelche goldene Wasserhähne oder sowas baut. So genug jetzt hier gefaselt, mach du mal weiter, du bist jetzt wieder für den theoretischen Teil. Okay, da mach ich mal weiter mit dem theoretischen Teil. Es geht also um das Engineering und das beschreibt so ein bisschen eine ingenieursmäßige Vorgehensweise. Das klingt jetzt so ein bisschen Theorie lastig, aber man kann das ganze relativ praxisnah aufziehen und sagen, also wenn etwas methodisch und fundiert und systematisch ist, dann hat es zumindest den Vorteil, dass es auch gut erlernbar ist. Das heißt, um jetzt Requirements Engineering sauber betreiben zu können, muss ich jetzt nicht irgendwie dazu geboren sein oder eine besondere Begabung haben, sondern ich kann mich in Prinzip fit machen, einen großen Methodenkoffer von ganz ganz vielen Verfahren und Methoden mehr aneignen. Es gibt viele gute Lehrbücher, es gibt gute und schlechte Praxisbeispiele, die einen zeigen, wie man das Ganze anwenden kann. Und ich kann mich also sehr gut in dem Bereich fit machen. Und das ist natürlich das, was wir auch beide in unseren Vorlesung mit in Studierenden machen. Was bedeutet Engineering noch? Ideal wäre natürlich das ganze auch Kosten und Qualitätsbewusstsein zu haben, also auf der einen Seite will man natürlich Anforderungen haben, auf die ich mich verlassen kann, die valide sind, die auch passen. Also nicht vielleicht eine Umfrage mit nur 120 Leuten, das wäre für eine Requirements Engineering sicherlich zu wenig, um daraus ein Software zu bauen. Auf der anderen Seite kann ich natürlich nicht alle meine potentiellen Kunden, sondern dreitägigen Workshop einladen. Das wäre dann auf der Kosten Ebene sicherlich viel zu viel. Und im Bereich Engineering bedeutet auch den vorgegebenen Normen zu folgen. Denn neben den ganzen Wünschen und Anforderungen von Anwendern und Kunden gibt’s da auch noch so ein paar Normen, die beachtet werden wollen. Zum Beispiel im Bereich Software Requirements, da gibt’s entsprechende Spezifikationen von IEEE, DIN und ISO, wo zum Beispiel Charakteristica von Requirements beschrieben werden, dass diese Anforderungen zum Beispiel korrekt, vollständig, widerspruchsfrei, nachverfolgbar und verifizierbar sein müssen. Und dann hat man wirklich Dinge, mit denen man sehr konkret arbeiten kann. 

Ganz genau, jetzt vorhin habe ich dir schon angekündigt, was hat es damit E-Health zu tun? Also es ist jetzt tatsächlich kein Thema, reines E-Health-Thema, geht jetzt nicht nur um Patientenarten, sondern um einen Prozess in der Informatik. Aber wir beide brennendvoll für Requirements Engineering, wir haben beide dazu Vorlesungen und wir haben beide glaube ich festgestellt, dass das häufig die Ursache ist für Sachen, die leider in die Hose gehen. Deswegen, warum ist das Thema hier Bernhard? Ja, jetzt hast du ja die Antwort schon vorweg genommen. Projekte, die in die Hose gehen, da muss man natürlich zwangsweise in Deutschland auch eben an Projekte zur Digitalisierung und Gesundheitswesen denken. In die Hose gehen kann ja auch bedeuten, dass sie vielleicht nicht nur komplett scheitern, sondern auch einfach länger dauern als geplant oder nicht in der Form umgesetzt werden wie geplant. Und das Ganze kann, wie du gerade schon richtigerweise gesagt hast, natürlich vielfach damit zusammenhängen, dass am Anfang einfach nicht klar genug erhoben wird, was denn die Anforderungen an ein solches System sind und dass man das Ganze auf wirklich ja Lösungsneutral formuliert. Und weil jetzt man Beispiel aus dem E-Health-Bereich nehmen, dann wäre sicherlich eine Anforderung von Ärzten, dass die elektronisch Daten austauschen wollen und die entsprechende Technik dahinter ist den meisten relativ egal, oder dass Patienten Zugriff auf ihre Dokumentation haben, ob das Ganze jetzt über eine Karte, über eine Akte, über irgendwelche weiteren Dinge auf dem Smartphone, über eine App und so weiter funktioniert. Das wären alles schon Teile der Lösung. Zunächst habe ich eine Lösungsneutrale Anforderung, als Patient möchte ich Zugriff auf meine medizinische Dokumentation haben. Und dann kann ich in einem nächsten Schritt schauen, wie wichtig ist mir das im Vergleich zu anderen Dingen und was wäre eine mögliche technische Lösung, die das Ganze erfüllen könnte. Jans, genau. Wie schon angekündigt, kommen wir zu typischen Phasen in diesem Requirement-Prozess. Am Anfang ist die Kontextanalyse. Was ist da wichtig? Man sollte den Leuten, die nachher für die Anforderungen verantwortlich sind, sollte man auch Zeit geben, sich den Kontext anzuschauen. Wenn es also zum Beispiel um KIS geht und die Leute, die die Anforderungen erheben sollen, keine Ahnung vom Krankenhaus haben, wäre es gemein, den zu sagen, dass sie direkt das Software-System spezifizieren sollen, sondern dann sollen sie sich damit beschäftigen. Was gibt es also für Akteure zum Beispiel im Krankenhaus? Wie laufen dort die Prozesse ab, dass man sich überhaupt erst mal damit beschäftigt? Als nächstes kommt dann die Anforderungsermittlung. Das heißt, wo dann tatsächlich die Anforderungen erhoben werden. Da gibt es unterschiedliche Methoden, die wollen wir ja gar nicht weiter ausführen. Also man kann natürlich ein Interview machen, also man kann zum Beispiel mit den Ärzten sprechen und fragen, was störtlich besonders an deiner Arbeit, was sind die Hauptaufgaben, die du jeden Tag immer wieder machen musst, und solche Fragen, die kann man schon ein bisschen vorbereiten, muss dann gucken, dass man natürlich irgendwelche offenen Fragen stellt und nicht immer nur Fragen mit ja und nein beantwortet werden können und nachher purzeln, dann Anforderungen heraus. Die muss man dann dokumentieren, die muss man aufschreiben, die muss man spezifizieren. Also noch mal am Anfang ein bisschen anschauen, sich warm machen mit dem Bereich in dem man nachher die Software entwickeln möchte und sich da noch mal reindenken, was gibt es für Stakeholder, was gibt es für Prozesse, dann die Anforderungen ermitteln, z. B. Mit einem Interview oder in dem man einfach die Leute beobachtet, vielleicht auch mit einem Fragebogen und dann die Anforderungen aufschreiben, am besten auch mit was sind Fehlerfälle, etc., dass man das dokumentiert und das Ganze dann spezifiziert. 

Ja und dann geht es weiter als nächsten Schritt ganz wichtig ebenfalls die Anforderungsvalidierung, also passend diese Anforderungen überhaupt zudem Kontext, den ich vorermittelt habe, sind die Anforderungen gültig. Passt das von der Zielgruppe, die ich analysiert habe, kann ich das Ganze wirklich auf eine komplette Software übertragen oder habe ich da vielleicht nur eine spezifische Subgruppe von Anwendern analysiert. Nach der Validierung oder Parallel dazu auch zur Spezifikation die Anforderungsmodellierung als eigene Phase manchmal reicht das reine Textuelle aufschreiben nicht aus, sondern es ist sinnvoll bestimmte Aspekte auch in Diagramm in Modellen mal abzubilden, mal den Ablauf zu skizieren, wie sieht denn der typische Nutzer einer App beispielsweise oder einer Anwendung, diesen Ablauf, wie findet der sich dazu recht. Also im Bereich der Anforderungsmodellierung gibt es sehr, sehr viele Möglichkeiten an Diagramm, also die UML bietet dann ein breites Spektrum, mit denen ich diese Anforderungen dann entsprechend zu Papier bringen kann, ohne jedes mal einen mehrseitigen Text zu schreiben. Und als letzten Punkt, das ist quasi so eine Querschnittsdisziplin des Anforderungsmanagement, das begleitet eigentlich diesen gesamten Requirements-Engineering-Prozess diese Anforderungen, die ich irgendwann mal erhoben habe, dokumentiert habe, die muss ich weiter pflegen, irgendwann kommt es zu einer Priorisierung, da verschiebt sich vielleicht auch mal die Reihenfolge der Anforderungen, das bedeutet, ich muss also diese Anforderungen von der allerersten Dokumentation bis zur finalen Umsetzung eigentlich komplett managen und das ist sicherlich auch noch mal einen ganz wichtiger spannender Bereich. 

Was meinst du, wie häufig immer bisher Anforderungen gesagt, ich tipp mal auf 35. Bietet ich weniger, aber ich schneide ja, ich kann ja dann passend machen, du kannst hier mal mehr zählen und dann veröffentlichten auf Twitter. 

Ein vielleicht noch zwei Sachen, wir werden irgendwann, ich habe es vorhin schon mal erwähnt, wenn man nachher saubere Anforderungen, Anforderungen, Anforderungen, Anforderungen hat, das kann man auch doch auf 35. Dann ist ja auch wichtig, dass man die irgendwie priorisiert und weiß, was man als erstes machen soll, das ist auch ein großes Problem, was ich selbst auch kannte aus meiner Zeit in der Industrie, dazu gibt es auch coole Verfahren, z. B. Kano, werden wir uns vielleicht mal anschauen, andere Verfahren, die dort auch relevant sind, ist sowas wie Personas und es gibt unterschiedliche Techniken, wie man die Anforderungen nachher da erheben kann. Ein flammdespläte wie von mir noch, bevor ich mich verabschiede. Liebe Leute, wenn ihr verantwortlich seid für Software wie auch immer, ob ihr nachher Entwickler seid, ob ihr Produktmanager seid, ob ihr bei der gematik sitzt wie auch immer, auch wenn ihr Agil entwickelt, nach Scrum z. B. Scrum empfindet euch nicht davon sich vorher zumindest grob mit den Anforderungen zu beschäftigen. Es ist ungerecht, den Entwicklern gegenüber, den Spezifikation zu geben, die noch nicht durchdacht ist. Ihr wollt nicht, dass alle zwei Wochen nach einem Sprint die Software komplett ungeschrieben wird. Von daher, nein, auch wenn man Agil entwickelt, muss man vorher zumindest grob verstehen, um was es geht. Deswegen, solange ihr das nicht verstanden habt, fangt nicht an zu entwickeln, noch mal garbage in, garbage out und out bin ich jetzt auch. 

Dem kann ich mich nahtlos anschließen, und es wird sicherlich nicht unsere letzte Podcastfolge mit Themen des Requirements Engineering sein. Wir werden euch da weiter mit Verfahren und Methoden nochmal auf den laufenden halten und verabschieden uns jetzt.