Fachliche Anforderungen in der Softwareentwicklung: Verstehen und verstanden werden
Wie Domain Storytelling Entwickler und Fachexperten zusammenbringt
Über fachliche Anforderungen an Software redet man am besten in der Sprache der Fachexperten. Aber wie schaffen es Entwickler, Anforderungsermittler oder Product Owner, diese Fachsprache zu lernen? Dieser Artikel zeigt Ihnen eine Interview- und Modellierungstechnik, die dabei hilft, eine Domäne zu verstehen und eine gemeinsame Fachsprache zu etablieren.
Stellen Sie sich vor, sie wollen Spanisch lernen. Also lesen Sie erst ein Wörterbuch von A-Z und lernen dann die Grammatik. Klingt lächerlich? Sie haben Recht. Sicherlich werden Sie ein Wörterbuch brauchen und Sie müssen sich früher oder später mit Satzstellung und Zeitformen auseinandersetzen. Aber gerade am Anfang lernen Sie am besten durch den direkten Kontakt mit "Muttersprachlern": Sie hören ihnen zu, wiederholen das Gehörte und beobachten ihre Reaktion. Erst lernen Sie einzelne Wörter, dann Phrasen und schließlich ganze Sätze. Je mehr Sie sprechen, desto schneller lernen Sie.
Domain Storytelling überträgt dieses Vorgehen auf die Fachsprache der Fachbereiche in Unternehmen. Wir bringen Fachexperten dazu, fachliche "Geschichten" über ihre Arbeitsabläufe zu erzählen. Keine Aktenordner voller Dokumentation, keine abstrakten Geschäftsprozessmodelle, sondern konkrete, nachvollziehbare Beispiele – fachliche Geschichten (Domain Stories). Schon nach wenigen Domain Stories können wir uns mit den Experten sicher in ihrer Fachsprache darüber unterhalten, wie sie arbeiten und wie Software sie dabei unterstützen kann.
Gehen Sie gern ins Kino? Ein erstes Beispiel.
Stellen wir uns vor, dass wir eine App für ein Kino entwickeln sollen. Mit dieser App sollen Kinobesucher unter anderem Kinokarten reservieren können. Natürlich haben auch wir schon mal ein Kino besucht und Karten reserviert. Aber wie eine Reservierung in diesem Kino abläuft, wissen wir noch nicht. Daher befragen wir einen Ticketverkäufer, die Kinomanagerin und den IT-Administrator zu diesem Anwendungsfall und erfahren, dass Tickets telefonisch, per Webseite oder am Schalter reserviert werden können. Wir bitten die drei Experten, uns zunächst zu erzählen, wie Kinobesucher direkt vor Ort reservieren. Das Ergebnis – eine fachliche Geschichte oder Domain Story – ist im folgenden Bild zu sehen. Um sie nachzulesen, folgen wir einfach den Nummern:
- Eine Kundin fragt den Ticketverkäufer nach einer Reservierung für eine bestimme Anzahl von Plätzen für eine bestimmte Vorstellung (Film, Uhrzeit).
- Der Ticketverkäufer sucht die Vorstellung im Saalplan.
- usw.
Diese kurze, einfache Geschichte lehrt uns wichtige Fachbegriffe wie Vorstellung, Saalplan und Reservierungsnummer. Außerdem erfahren wir, dass es ein Ticketsystem gibt, in dem Reservierungen erfasst werden. Und durch die Symbole sehen wir, welche Informationen verbal ausgetauscht werden (Symbol: Gesprächsblase) und in welchen Schritten (digitale) Dokumente eine Rolle spielen (Symbol: Dokument). Die Symbole dienen nicht bloß der Optik, sondern sie formen eine Bildsprache, die im Folgenden genauer erläutert wird.
Wie entsteht das Bild zur Geschichte?
Domain Storytelling beschränkt sich nicht auf das gesprochene Wort. Während wir zuhören, zeichnen wir die Domain Stories vor den Augen der Fachexperten mit Hilfe einer Bildsprache auf. Dadurch können alle Beteiligten unmittelbar sehen, ob sie richtig verstanden wurden. Die Bildsprache hilft den Fachexperten dabei, die Geschichte zu strukturieren. Die wesentlichen Aufgaben, Rollen, Werkzeuge, Arbeitsgegenstände und Ereignisse einer Domäne treten dadurch klar hervor.
Im Domain Storytelling unterscheiden wir drei Arten von Symbolen:
- Akteur: Akteure wie Personen, Gruppen und Softwaresysteme sind die Protagonisten einer Geschichte. Üblicherweise bezeichnen wir Akteure mit ihrer Rolle, nicht ihrem Namen (d. h. Kinobesucherin statt Maria Müller).
- Arbeitsgegenstand: Akteure bearbeiten Arbeitsgegenstände wie Reservierung, Saalplan und Vorstellung. Außerdem kommunizieren sie mittels Arbeitsgegenständen mit anderen Akteuren, indem sie beispielsweise die Gegenstände an diese weitergeben. Das Symbol eines Arbeitsgegenstands drückt das Medium aus, das den Arbeitsgegenstand repräsentiert, etwa ein Dokument oder ein Telefonanruf. In diesem Artikel verwende ich einige Google Material Icons [1], die gut zu typischen Bürotätigkeiten passen und sich in vielen Domänen bewährt haben. Je nach Einsatzkontext werden die Symbole angepasst. In der Logistik ist z. B. ein Symbol für einen Container nützlich, wenn in der Domain Story abgebildet wird, wie Container verladen werden.
- Aktivität: Die Aktivitäten der Akteure werden als Pfeile dargestellt. Abb. 2 zeigt drei typische "Satzformen", die mit Pfeilen ausgedrückt werden können.
Annahmen, Varianten und Ausnahmen einer Domain Story und der Zweck einer Aktivität können mit Notizen festgehalten werden. Notizen werden meist nicht mit einem Symbol dargestellt, sondern rein textuell erfasst. Vollständigkeit ist dabei aber nicht das Ziel – Domain Stories sind nämlich keine Spezifikationen! Um eine Domäne zu verstehen und mit Fachexperten darüber zu sprechen, reicht es in der Regel aus, 80 Prozent der Fälle abzudecken – also die wichtigsten, häufigsten, schwierigsten und aufwändigsten Varianten eines Geschäftsprozesses.
Mit den drei Ausdrucksmitteln "Akteur", "Arbeitsgegenstand" und "Aktivität" können wir einzelne Sätze formulieren. Alle Symbole – auch die Pfeile! – werden beschriftet, sodass man einen Satz fast wie Text lesen kann. Damit aus einzelnen Sätzen eine Geschichte wird, müssen wir die Sätze aneinanderreihen. Dazu nummerieren wir die Aktivitäten (also die Pfeile). Da eine Geschichte ohne Fallunterscheidungen erzählt wird, benötigt die Bildsprache keine Symbole für Verzweigungen, wie man sie aus Ablauf-orientierten Modellierungssprachen (z. B. BPMN, EPK oder UML Aktivitätsdiagramme) kennt.
Jeder Akteur kommt in einer Domain Story nur einmal vor. Um sie deutlich hervorzuheben, sind die Symbole etwas größer als die anderen. Arbeitsgegenstände können mehrfach auftauchen, weil sie zu unterschiedlichen Zeitpunkten der Geschichte eine Rolle spielen. Im Lauf der Geschichte können Arbeitsgegenstände ihr Symbol verändern, beispielsweise kann eine Reservierung erst als E-Mail verschickt und später auf Papier gedruckt werden.
Kommen wir zum Thema "Werkzeug". Domain Stories lassen sich "analog" auf Flip Chart oder Whiteboard aufzeichnen. Weil man am Anfang einer Geschichte aber noch nicht weiß, in welche Richtung sie sich entwickelt und wie umfangreich sie wird, hat das abwischbare Whiteboard einen klaren Vorteil gegenüber Papier. Weil es aufwändig wäre, die Symbole jedes Mal per Hand zu zeichnen, empfiehlt sich, mit vorgedruckten Kärtchen zu arbeiten (zum Beispiel mit laminierten, auf der Rückseite mit Magneten versehenen Karten).
Um Domain Stories digital aufzuzeichnen, eignen sich Werkzeuge wie yEd und draw.io [2]. Für einen Vorläufer von Domain Stories gibt es ein kostenloses Modellierungswerkzeug [3]. Noch ein Hinweis zur Darstellung von Aktivitäten: Viele Modellierungswerkzeuge können nur zwei Modellelemente miteinander verbinden. Eine Aktivität mit drei Modellelementen muss daher über zwei Pfeile abgebildet werden (s. Abb. 3 oben). Verwendet man ein Zeichenwerkzeug oder zeichnet per Hand, kann man solche Aktivitäten durch einen Pfeil ausdrücken (s. Abb. 3 unten). Die beiden Darstellungsweisen unterscheiden sich nicht in ihrer Bedeutung.
Werden Domain Stories "analog" aufgezeichnet, beschränkt der verfügbare Platz die Größe des Bildes. In der Praxis bedeutet das meist keinen Nachteil. Im Gegenteil, der beschränkte Platz hilft dabei, die Domain Stories übersichtlich zu halten. Digitale Werkzeuge erfordern mehr Disziplin, weil sie oft "unendlich" große Flächen anbieten. Als Faustregel hat sich bewährt, Domain Stories auf eine DIN A4-Seite oder ca. 15 Aktivitäten zu begrenzen.
Wie läuft Domain Storytelling ab?
Domain Stories werden in Workshops erzählt. Neben einem Moderator braucht es für einen guten Workshop die richtigen Fachexperten – sprich, die Personen, die aus erster Hand zur Geschichte beitragen können. Es ist dabei häufig von Vorteil, wenn die Teilnehmergruppe abteilungsübergreifend zusammengesetzt ist. Je umfangreicher die Geschäftsprozesse einer Domäne sind, desto seltener gibt es jemanden, der eine Geschichte alleine von Anfang bis Ende kennt. Versammelt man aber Vertreter verschiedener Fachabteilungen und der IT, können diese gemeinsam die Geschichte erzählen. Daher ist es wichtig, dass die Domain Story jederzeit für alle sichtbar ist – sei es am Whiteboard oder von einem Beamer an eine Wand geworfen. Während die Teilnehmer die Domain Story Schritt für Schritt erzählen, visualisiert der Moderator (oder erfahrene Teilnehmer auch selbst) diese mit dem gewählten Werkzeug. Die Teilnehmer greifen korrigierend in die Modellierung ein, wenn sie ihre Aussagen im Modell nicht richtig umgesetzt sehen, und stimmen sich in dem Workshop auch wechselseitig über ihre Sichten auf den Prozess ab. Nicht auflösbare Unterschiede werden durch Notizen sichtbar gemacht. Am Ende eines Workshops stehen daher Domain Stories, die eine eingehende Qualitätssicherung erfahren haben. Die Beteiligten nehmen aber nicht nur die visualisierten Domain Stories als Foto oder Bilddatei als Ergebnis mit. Das gemeinschaftliche Modellieren ist für sie ein Verständnisprozess, in dem sie ihre eigene Arbeitswelt reflektieren und die Arbeitswelt von Kollegen und anderen Abteilungen anschaulich erklärt bekommen.
Aufgabe des Moderators ist es, zu Beginn allen Beteiligten den Zweck des Workshops zu erklären. Häufig ist der Moderator der wichtigste Nutznießer der Domain Stories – etwa wenn er als Product Owner, Softwareentwickler oder Business Analyst das erworbene Wissen für ein neues Softwareentwicklungsprojekt nutzt. Je nachdem, was mit dem Workshop bezweckt wird, müssen die Geschichten mal oberflächlich und breit und mal mit klarem Fokus und detailliert erzählt werden. Der Moderator sorgt durch seine Fragen dafür, dass der Erzählfluss der Beteiligten nicht versiegt. Typische Fragen sind:
- Was passiert als nächstes?
- Woher haben Sie diese Informationen?
- Wieso wissen Sie, dass Sie das als nächstes machen müssen?
Außerdem muss ein Moderator gegensteuern, wenn ein Teilnehmer die anderen nicht zu Wort kommen lässt oder sich Diskussionen entwickeln, die das Fortschreiten der Geschichte verhindern. Ein typisches Beispiel: An einem Punkt der Geschichte diskutieren die Teilnehmer, was alles passieren könnte. Solche Diskussionen lassen sich auflösen, in dem die Geschichte konkretisiert wird und Annahmen ergänzt werden: "Nehmen wir an, es sind genügend freie Sitze nebeneinander frei. Was passiert als nächstes?". So verzetteln sich die Teilnehmer nicht in Sonderfällen.
Wichtige Varianten, die sich nicht mit einer kurzen Notiz beschreiben lassen, verdienen eine eigene Domain Story. Beispielsweise könnten die Teilnehmer unseres Kino-Workshops feststellen, dass die Reservierung per Telefon fast identisch abläuft wie die Reservierung vor Ort – kleine Unterschiede halten wir mit einer Notiz fest. Die Reservierung per Webseite läuft hingegen völlig anders ab. Hier lohnt es sich, gemeinsam eine zweite Domain Story auszuarbeiten.
In den Workshops steht der gemeinsame Erkenntnisgewinn über dem Erstellen von Dokumentation. Die abfotografierten oder digital erstellten Domain Stories dienen als Gedächtnisstütze für die Teilnehmer eines Workshops. Sie können die Teilnahme am Workshop nicht ersetzen. Aus den Domain Stories entstehen oft weitere Dokumente, wie im nächsten Abschnitt erläutert wird.
Wozu kann ich Domain Storytelling einsetzen?
Domain Storytelling ist branchenunabhängig und wurde unter anderem in der Logistik, im eCommerce, in der öffentlichen Verwaltung, in Krankenhäusern und in Versicherungen erfolgreich eingesetzt.
Oft wird Domain Storytelling am Beginn eines Entwicklungsprojekts genutzt. Alle Beteiligten machen sich mit der Fachlichkeit vertraut und verstehen, wie die zu entwickelnde Software in existierende Arbeitsprozesse integriert werden kann. Besonders nützlich ist Domain Storytelling, wenn die Software so gebaut wird, dass sie tief in der Fachlichkeit wurzelt. Der populäre Entwicklungsansatz Domain Driven Design (DDD) fordert genau das:
- Entwickler unterhalten sich mit ihren Anwendern in deren Fachsprache.
- Begriffe und Zusammenhänge der Anwendungsdomäne strukturieren die Softwaresysteme.
Um die Fachsprache einer Domäne (im DDD "ubiquitous language" genannt) zu erlernen, modellieren Entwickler und Fachexperten gemeinsam die Domäne. Dabei kommen Techniken wie "Scenario Whirlpool" und "Event Storming" zum Einsatz. Domain Storytelling ergänzt die Werkzeugkiste um ein Werkzeug, das sich besonders eignet, um kooperative Arbeitsabläufe zu verstehen.
Auch ohne DDD hilft Domain Storytelling dabei, über Anforderungen zu sprechen – und zwar unabhängig davon, ob man Individualsoftware entwickelt (bzw. entwickeln lässt) oder ob Standardsoftware zugekauft wird. Stellen wir uns vor, unser Kino möchte seinen Vertrieb stärken und die online registrierten Kunden mittels Newsletter und vertrieblichen Aktionen an sich binden. Ein klassischer Fall für ein Customer Relationship Management (CRM)-System. Der Markt für CRM-Systeme ist groß. Wie stellt man fest, welches System für unser Kino passend ist?
Die fachliche Eignung hängt wesentlich davon ab, wie das CRM-System die Geschäftsprozesse des Kinos unterstützt. Daher erarbeiten sich die Mitarbeiter des Kinos mit Hilfe von Domain Storytelling eine gemeinsame Vorstellung davon, wie sie zukünftig mit einem CRM-System arbeiten wollen. Die aufgezeichneten Domain Stories, gemeinsam mit funktionalen, technischen und Qualitätsanforderungen, werden mehreren Anbietern von CRM-Systemen zur Verfügung gestellt. Die Anbieter müssen dann beschreiben, wie die Geschichten verlaufen würden, wenn ihre Software darin eine Rolle spielt. Hat man den Kreis der Anbieter auf wenige Favoriten eingeschränkt, eignen sich Domain Stories auch sehr gut als "Drehbuch" für Produktdemonstrationen. Da alle Anbieter die gleichen Geschichten wiedergeben müssen, treten Unterschiede im Umgang mit den verschiedenen CRM-Systemen deutlich hervor.
Die gute Verständlichkeit der Domain Stories versetzt die Anbieter in die Lage, alternative "Geschichten" zu erzählen, die zum gleichen Ende führen, aber effizienter sind, als die von den Kinomitarbeitern vorgeschlagenen Abläufe. Außerdem können die Kinomitarbeiter erkennen, bei welchen Prozessen und Prozessschritten ein CRM-System nicht zu ihren Arbeitsabläufen passt. Das ermöglicht die Diskussion, ob die Standardsoftware an die Abläufe angepasst werden soll oder umgekehrt.
In agilen Softwareentwicklungsprojekten helfen Domain Stories dabei, eine Product Backlog initial mit Epics und User Stories zu befüllen. Man kann die User Stories in der Regel direkt aus den Domain Stories ableiten. Ein Beispiel: Will eine Kundin unseres Kinos vor Ort Karten reservieren, sucht der Ticketverkäufer nach dem passenden Saalplan für die Vorstellung und bietet die freien Plätze an. Dazu kann man folgende User Story (ohne Akzeptanzkriterien) formulieren: "Als Ticketverkäufer will ich die freien Plätze für eine Vorstellung ermitteln, damit ich diese Plätze meinen Kunden anbieten kann."
Zum Abschluss noch ein Beispiel
Blicken wir zum Abschluss in die Zukunft. Wir stecken mitten in der Entwicklung der Kino-App. Folgende Domain Story beschreibt, wie Tickets per App gekauft werden. Wir sehen den Erfolgsfall, von der Bestellung bis zur Kaufbestätigung: Eine Kundin bestellt Tickets und bezahlt mit ihrer Kreditkarte. Da die Kunden schon einmal Karten über die App gekauft hat, sind ihre Kreditkartendaten bereits bekannt.
Dieses Beispiel zeigt, dass auch die Kooperation zwischen technischen Akteuren abgebildet werden kann und abstrakte Arbeitsgegenstände nicht unbedingt ein bildhaftes Symbol haben müssen. Der externe Zahlungsdienstleister ist für uns eine Blackbox – was genau sich hinter Schritt 5 verbirgt, wissen die Kinomitarbeiter und wir nicht. Wenn jedoch Eingabe (Schritt 4) und Ausgabe (Schritt 6) für alle von uns gewünschten Zahlungswege ähnlich sind, werden wir vermutlich keine weiteren Domain Stories für den Erfolgsfall aufzeichnen. Mindestens ein Fehlerfall sollte aber noch betrachtet werden. Wie könnte die Geschichte ablaufen, wenn der Zahlungsdienstleister die Kreditkarte nicht belasten kann?
Probieren Sie es doch einfach selbst aus!
