Swiss Requirements Day 2015 – Eine Zusammenfassung

Am 17. Juni 2015 fand der alljährliche Swiss Requirements Day statt. Wir nehmen diesen Event und unsere Teilnahme zum Anlass, um einige ausgewählte Vorträge kurz zusammenzufassen und uns über die aktuellen Themen Gedanken zu machen.

Folgendes vorweg: Die Auswahl fand rein auf Grund der persönlichen Präferenzen des Autors zu den angebotenen Themen statt. Sie ist daher als zufällig zu verstehen und gibt keine Auskunft über Qualität oder Wichtigkeit!

Keynote

Der Tag begann mit einer sehr passenden Keynote von Professor Dr. Martin Glinz zum Thema „Gemeinsames Verständnis: Schlüssel für erfolgreiches Requirements Engineering“. Der geneigte Zuhörer kannte diese möglicherweise bereits vom Berliner RE Symposium 2013. Obwohl also nicht unbedingt neu, so war der Vortrag trotzdem immer noch sehr aktuell und gab den Ton für die weiteren Präsentationen vor.
Eine Schlüsselfolie zeigte grafisch die verschiedenen Formen des gemeinsamen Verständnisses. Dabei unterscheidet Glinz die Dimensionen Relevant-Irrelevant, Implizit-Explizit sowie Wahr-Falsch (Glinz und Fricker, 2013).

Mit impliziter Information ist die Information gemeint, bei der wir davon ausgehen, dass sie korrekt ist und die anderen Stakeholder im Projekt das gleiche Verständnis haben. Ein Beispiel: „Die Text-Eingabe in einem Dialog erfolgt von links nach rechts, wobei der Cursor zu Beginn links positioniert ist“. Ein solches Statement wird kaum jemals explizit spezifiziert. Stattdessen wird davon ausgegangen, dass es klar ist und ein gemeinsames Verständnis darüber existiert. Dabei gilt es zu beachten, dass der Kontext relevant ist, um zu entscheiden ob die Aussage korrekt ist. In Europa schreiben wir tatsächlich von links nach rechts. Würden wir aber die Software auch auf z.B. Hebräisch anbieten, dann ist die Annahme nicht mehr allgemeingültig.
Explizite Information ist in irgendeiner Form niedergeschrieben, oder eben: explizit gemacht. Dies heisst noch nicht, dass sich alle das gleiche darunter vorstellen. Wichtig zu verstehen ist, dass eine Spezifikation (also explizite Information) sowohl relevante wie auch irrelevante Information beinhalten kann und diese dann noch wahr oder falsch sein kann. Wert liefert natürlich nur der relevante und korrekte Teil.
Interessant ist auch die „dunkle“ Information. Dabei handelt es sich um relevante Information, die weder implizit noch explizit bekannt ist. Diesen Teil gilt es zu minimieren, da er Risiken birgt.

Die Kernbotschaft des Vortrags lautet, dass das gemeinsame Verständnis eine wichtige Voraussetzung für den Erfolg von Software-Projekten ist. Dieses gemeinsame Verständnis kann aber durchaus auch implizit sein, es muss nicht immer alles explizit spezifiziert sein. Im Gegenteil: Das Optimum an Effizienz wird erreicht, wenn man explizite Information soweit produziert und nutzt wie nötig, während man sich so weit wie möglich auf implizites Verständnis verlässt.

In 8 Monaten aus 450 Geschäftsprozessen 20 Apps mit 180 Use Cases für 22‘000 mobile Geräte der Post mit 7 Scrum Teams erstellen

Herr Bertram Schütze bot einen Erfahrungsbericht aus einem herausfordernden Grossprojekt mit einem Gesamtbudget von 76 Millionen CHF. Bei der Post waren 22‘000 End of Life Geräte abzulösen. Dabei galt es neben der Ablösung alter Funktionalität auch die bestehenden Prozesse zu optimieren und Hardware-unabhängig zu werden. Dies mit einer kurzen Time-to-Market. Wie konnte dies alles mit 6 verschiedenen Lieferanten koordiniert und umgesetzt werden?
Das Requirements Engineering hat eine wichtige Bedeutung. Denn ein agiles Vorgehen in dieser Grössenordung bedingt Anforderungen in kleinen, adressierbaren Einheiten, die innerhalb eines Sprints umsetzbar sind. Dies muss auch durch die Architektur unterstützt sein. Nicht nur dass man die Anforderungen zerlegt ist wichtig, sondern auch wie. Insbesondere gilt es die Schnittstellen zu minimieren.
Das automatisierte Testing war ein zweiter Erfolgsfaktor. Es ist für ein agiles Vorgehen bei Projekten dieser Komplexität und Grösse unabdingbar.

Eliminate and Automate – These methods can save 50% of your requirements effort

Herr Colin Hood fasste zwei der wichtigsten im oben beschriebenen Projekt eingesetzten Techniken verallgemeinert zusammen unter dem Titel „Eliminieren und automatisieren“. Insbesondere die wenig Wert generierenden Tätigkeiten, die aber trotzdem notwendig sind (zum Beispiel aus regulatorischen Gründen) gilt es wo immer möglich zu automatisieren. Als Beispiel nannte er die textuelle Beschreibung von Anforderungen, welche aus Tools generiert werden kann.
Tätigkeiten, die nicht unbedingt notwendig sind können mitunter auch ganz eliminiert werden.

Zusammenfassung

Insgesamt machte sich dieses Jahr ein Trend bemerkbar Richtung „weniger ist mehr“. Neben den aufgeführten Präsentationen schlugen auch weitere in dieselbe Bresche.
Dadurch, dass Requirements Engineering teilweise immer noch Mühe bekundet im Management als wertvolle und auch Wert generierende Disziplin akzeptiert zu werden, ist es umso wichtiger, die Prozesse schlank zu halten. Einerseits durch Fokus des Outputs auf Relevantes. Wird eine Spezifikation über mehrere hundert Seiten von den Entwicklern aus naheliegenden Gründen nicht akzeptiert, so bringt sie keinen Mehrwert. Anderseits durch Minimierung des Aufwands. Reduktion der Schnittstellen, Reduktion der Komplexität (durch Modularisierung und Zerlegung) sowie Reduktion von expliziter Information, die auch durch implizites gemeinsames Verständnis hätte abgedeckt werden können, sind dabei die notwendigen Schritte.

Wir gelangen zur Erkenntnis, dass wir nichts anderes tun müssen, als auf uns selber im Requirements Engineering die gleichen Prinzipien anzuwenden, die wir in unseren Spezifikationen an Software-Systeme vorgeben. Nämlich den Benutzer (unserer Spezifikation!) ins Zentrum zu stellen und für diesen den maximalen Wert mit minimalem Aufwand zu generieren. Daraus folgt das Weglassen von Features (wieder: unserer Spezifikation!), nach denen niemand gefragt hat (also irrelevante Anforderungen, unnötige Diagramme, überspezifiziertes Verhalten, usw.) und Automatisierung von nicht direkt Wert generierenden Tätigkeiten (Versionierung, Traceability, etc.).