Kategorie: Anforderungen

Das 10. Treffen der User Group Requirements Engineering der Softwareforen Leipzig hatte den Themenschwerpunkt „Effektive Anforderungserhebung und Ideenfindung im Requirements Engineering“ (hier gibt es die vollständigen Veranstaltungshinweise als PDF). Zum Auftakt der Veranstaltung wurde die Erhebung von Anforderungen oder Informationen im Allgemeinen zunächst einmal nicht aus dem Blickwinkel der Informatik oder des Software Engineerings betrachtet.

Der Radio-Journalist Christian Bollert (BEBE Medien GmbH, detektor.fm) berichtete von seinen Erfahrungen beim Vorbereiten und Durchführen von Interviews fürs Radio. Radiohörer haben leider nicht die Möglichkeit bei einem Wort, das sie nicht verstehen kurz anzuhalten und das Wort nachzuschlagen. Auch können sie nicht einfach einige Seiten zurückblättern, um noch einmal etwas nachzuschlagen. Daher müssen Texte im Radio einfach zu verstehen sein. Ich sehe jedoch keinen Grund, warum geschriebene Texte komplizierter sein sollten, schon gar nicht wenn es um Anforderungen geht. Die 10 Grundregeln für Texte im Radio, die Christian Bollert vorgestellt hat, können somit für jegliche Art von Text angewendet werden:

1. Kurze, verständliche Sätze, möglichst wenig Nebensätze
2. Gesprochene Sprache, keine Kunstsprache. Nach dem Motto: Wie erzähle ich es einem Freund – mündlich!
3. Sätze zum Vorlesen sprechend entwickeln (laut vorlesen)
4. Aktiv statt Passiv; kein Nominalstil, verbal schreiben
5. Sätze nicht mit Informationen überfrachten
6. Eines nach dem Anderen erklären
7. Fremdwörter oder Fachbegriffe sofort erklären oder ganz darauf verzichten
8. Namen und zentrale Begriffe wiederholen – Redundanz erwünscht! („Redundanz statt Varianz“)
9. Bildlich vergleichen: So groß wie ein Fußballfeld
10. Füllwörter nutzen. Sie ermöglichen Atempausen und verbinden (Beispiele: „deshalb“, „darum“, „aus diesem Grund“)

Gerade technische Texte beschreiben oftmals eine überaus komplexe Fachlichkeit. Daher sehe ich überhaupt keinen Grund, warum diese Texte durch umständliche Formulierungen weiter verkompliziert werden sollen.

Requirements Engineers verwenden oftmals leider nicht allzu viel Zeit auf die Vorbereitung von Interviews mit Stakeholdern. Zudem wird bei der Vorbereitung meist nur festgelegt WAS man von einem Stakeholder wissen möchte und leider nicht WIE man eigentlich danach fragt. Auch hier hatte Christian Bollert nützliche Hinweise. Er hat 12 verschiedene Typen von Fragen vorgestellt und dabei neben Beispiele auch beschrieben, unter welchen Umständen man den jeweiligen Fragentyp einsetzen sollte. So soll beispielsweise die Entscheidungsfrage „Was brauchen Kinder ihrer Meinung nach mehr: mehr Freiheit in der Erziehung oder mehr Struktur?“ verhindern, dass der Befragte um den heißen Brei herumredet oder sich einfach herausreden kann. Mehrfachfragen sollten gar nicht gestellt werden, da Befrage eigentlich nur die Einzelfragen beantworten, die ihnen am besten zusagen und sowieso nie alle Einzelfragen beantworten.

Auf die Frage „Was macht einen guten Interviewer aus?“ gab Christian Borschert die folgende Antwort:

• Empathie
• Geduld
• Höflichkeit
• Rollendistanz zum Thema

Der letzte Punkt seiner Antwort warf dann jedoch die Frage auf, ob Fachwissen für Interviewer bzw. Requirements Engineers hilfreich oder schädlich ist. Darauf antwortete Christian Borschwert: „Manchmal ist es gut, wenn man ein Experte ist, sich aber traut trotzdem wieder naive Fragen zu stellen. Wenn das gelingt, dann ist man einer der Großen.“ Also: „Sei schlau, stell Dich dumm.“ Aus eigener Erfahrung kann ich mich hier uneingeschränkt anschließen. Es lohnt sich eigentlich immer auch grundlegende Konzepte noch einmal zu klären. So sollte man nicht davor zurückschrecken, z.B. in einem Versicherungsunternehmen noch einmal zu fragen „Was ist eigentlich ein Tarif?“ Darauf folgt leider nicht selten die Antwort „Solche grundsätzlichen Fragen müssen wir hier nicht mehr klären. Jeder von uns weiß, was ein Tarif ist.“ Lassen sie sich nicht abschrecken und fragen sie ruhig weiter nach: „OK, dann erklären Sie es mir bitte dennoch einmal. Ich kenne mich in Ihrer Domäne nicht so gut aus.“ Meist stellt sich dann heraus, dass es doch nicht so klar ist, was ein Tarif tatsächlich ist. Sollten mehrere Personen an der Befragung teilnehmen, so haben diese fast immer ein unterschiedliches Verständnis, selbst (oder gerade) von grundsätzlichen und vermeidlich einfachen Dingen. Es lohnt sich immer mutig zu sein und naive Fragen zu stellen.

In seinem tollen Vortrag „Kultur, Methode, Werkzeug – Drei Bausteine effektiver Anforderungserhebung“ verglich Sebastian Adam (Osseno Software GmbH) Requirements Engineering mit einer Autofahrt von Kaiserslautern nach Leipzig. Auf äußerst unterhaltsame Weise veranschaulichte er die Herausforderungen und Entscheidungen, die beim Aufsetzen und der Durchführung eines unternehmensspezifischen Requirements Engineerings getroffen werden müssen. Immer wieder wurde der Vergleich zu einer Autofahrt gezogen:

• Auto = Tool / Methode:
  Man kann einen Laster, einen Kombi oder einen Sportwagen verwenden. Mit allen Fahrzeugen (Tools) kommt man ans Ziel. Jedoch hat jeder Autotyp vor und Nachteile. Wenn man genug Zeit hat, kann man sogar mit dem Fahrrad fahren und die Landschaft genießen. Möchte man weniger Aufwand betreiben, kann man auch mit der Bahn fahren (= einen Dienstleister beauftragen).
• Straßenbeschaffenheit = Firmenkultur (bzgl. RE)
  Man kann über Autobahnen, Landstraßen oder Feldwege ans Ziel kommen. Genauso kann eine Firmenkultur die Arbeiten im Requirements Engineering beschleunigen oder verlangsamen.
• Strecke = Prozess
  Viele Wege führen ans Ziel bzw. im Beispiel führen viele Wege von Kaiserslautern nach Leipzig. Es gibt auch nicht den einen besten Weg, alle haben ihre Vor- und Nachteile.
• Ziel (z.B. Leipzig) = Produkt-/ Projektumfang

Alle vier Punkte müssen jedoch zusammenpassen und aufeinander abgestimmt. Zwar kann man sicherlich mit einem Ferrari über Feldwege von Kaiserslautern nach Leipzig fahren, aber wer will das schon? Sebastian Adam stellte zudem die provokante Frage (natürlich in Bezug auf RE): „Würden Sie mit jemanden von Kaiserslautern nach Leipzig fahren, der keinen Führerschein hat, nicht weiß wo Leipzig ist, nie in einer Fahrschule war und nur sehr selten Auto fährt?“

Ein wichtiger Punkt fehlt jedoch im obigen Vergleich. Wenn wir heute unterwegs sind, möchten wir unser Navigationssystem nicht mehr vermissen. Das Navigationssystem sagt uns genau, wo wir gerade sind, wie lange es noch dauert und wann wir wohin abbiegen müssen. Zudem reagiert unser Navigationssystem auf unvorhergesehene Probleme und bietet uns alternative Routen an. Außerdem bringt uns unser Navigationssystem immer wieder auf die Stecke zurück, falls wir einen kurzen Abstecher gemacht haben. Aber wo ist das Navigationssystem fürs Requirements Engineering? Genau dieser Frage hat sich das Fraunhofer IESE Spin-Off OSSENO angenommen, das Sebastian Adam mit seinen beiden Kollegen Norman Riegel und Özgür Ünalan gegründet hat.

Mit seinem enthusiastischen Vortrag „Von der Idee bis zum Code: Flüssige Anforderungen fließen besser“ eröffnete Kurt Schneider (Leibniz Universität Hannover) den zweiten Tag der Veranstaltung. Insbesondere ging es dabei um die Erstellung von Informationsflussmodellen mit der FLOW (kein Akronym) Notation. Dabei unterscheidet man feste und flüssige Informationen. Feste Informationen (z.B. Dokumente, Bilder, Mitschriften, …) haben den Vorteil, dass sie langfristig zugänglich sind, an viele Empfänger weitergegeben werden können, und vor allem können Dritte ohne Hilfe etwas damit anfangen. Ein großer Nachteil ist jedoch, dass die Erstellung und auch der Abruf (z.B. das Auffinden) von festen Informationen sehr viel Zeit kostet. Flüssige Informationen sind nicht persistiert und somit nur in den Köpfen von Mitarbeitern vorhanden. Diese können jedoch schnell und effizient übergeben werden. Nachteilig ist jedoch, dass diese Informationen an Individuen gebunden sind, kapazitätsbeschränkt sind und mit der Zeit „versickern“. Bei der Informationsflussmodellierung mit der FLOW Notation wird für jede Information angegeben, ob diese fest oder flüssig ist. Kurt Schneider gibt auch nicht vor, wie flüssig oder wie fest ein Informationsfluss sein sollte. Sieht man sich jedoch einen Informationsfluss an, so ist oft leicht zu erkennen, welche Abschnitte „verflüssigt“ werden sollten, da sie zu starr und unflexibel sind. Genauso leicht ist zu erkennen, welche Abschnitte „verfestigt“ werden sollten.

Wenn es ums „Verfestigen“ geht, sollten wir nicht immer gleich an epische Dokumente denken. Informationen können auch auf andere Art persistiert werden. Kurz Schneider schlägt hierzu auch vor, Videos zu verwenden. Videos können auf effiziente Art und Weise Dokumente ersetzen. Dem kann ich mich nur anschließen. Auch wir haben schon sehr positive Erfahrungen mit Videos gemacht. Dabei ist ganz wichtig, dass diese Videos nicht OSCAR-reif gespielt, gedreht, geschnitten und produziert werden müssen. Dem Verwendungszweck angemessen können auch einfach erstellte Videos einen großen Nutzen bringen. Es muss aber auch nicht immer (gleich) Video sein. Ich bevorzuge beispielsweise auch Fotoprotokolle von Meetings. Einfach die Whiteboards, Flipcharts oder sonstigen Ergebnisse, die im Meeting erarbeitet wurden abfotografieren und in einem PDF-Dokument zusammenfassen. Der Aufwand einer manuellen Digitalisierung (d.h. Abtippen der Bilder) bietet oft keinen Mehrwert, der den Aufwand rechtfertigt.

Alles in allem war es wieder mal eine tolle Veranstaltung bei den Softwareforen. Ich freue mich schon auf meinen nächsten Besuch in Leipzig.