Ein Angebot von

Specification by Example: Wie bekomme ich genaue Anforderungsvorgaben?

| Autor / Redakteur: Markus Unterauer * / Sebastian Gerstl

Bild 1: Bei der Weitergabe von Anforderungen geht oft Information verloren. Diese humoristische Darstellung ist leider oft näher an der Software-Entwickler-Realität, als einem lieb ist.
Bild 1: Bei der Weitergabe von Anforderungen geht oft Information verloren. Diese humoristische Darstellung ist leider oft näher an der Software-Entwickler-Realität, als einem lieb ist. (Bild: http://www.smart-jokes.org/how-it-projects-really-work.html)

Specification by Example bedeutet, Anforderungen durch konkrete Beispiele zu spezifizieren. Dazu wird ein fixes Satzschema verwendet, welches ein einfaches Andocken von Testautomatisierung ermöglicht. So wird aus einem wertlosen Write-Only-Dokument eine wertbringende lebende Spezifikation.

Eine der schwierigsten Aufgaben in der Softwareentwicklung ist es, herauszufinden, was das System eigentlich tun und können soll. An dieser Anforderungserhebung sind viele Stakeholder beteiligt. Die Information über die Anforderungen des Kunden wandert dabei über zahlreiche Stationen. Der Kunde erzählt es dem Business Analysten, der gibt es an den Projektleiter wieder. Dieser bespricht es mit dem Architekten und vielleicht externen Beratern und gibt es dann an den Entwickler weiter. Der baut das System und gibt es gemeinsam mit den zu prüfenden Anforderungen an den Tester weiter. Schlussendlich landen System und Spezifikation bei der Wartungs- und Betriebsmannschaft. Bei jedem Schritt in dieser Kommunikationskette geht Information verloren, wie beim Spiel „Stille Post“. Erschwert wird die Anforderungsanalyse noch dadurch, dass es meist nicht nur einen Kunden gibt, sondern viele und somit das System viele Szenarien, Varianten und Ausprägungen unterstützen muss.

Zusätzliche Verwirrung entsteht, wenn die Information nicht mündlich, sondern als schriftliche Spezifikation in Form von Text und Modellen weitergegeben wird. Was für den einen völlig klar und verständlich ist, ist für den anderen nur eine sinnlose Aneinanderreihung von Zeichen. Oder schlimmer noch: Der Empfänger der Spezifikation glaubt alles verstanden zu haben, in Wirklichkeit aber weicht sein Bild von den Anforderungen deutlich von dem des Kunden ab.

Das Ergebnis sind oft schlecht designte Systeme, die die Bedürfnisse der Kunden nicht erfüllen. Diese Systeme werden in vielen Fällen trotzdem in Betrieb genommen und erst im laufenden Betrieb richtiggestellt. Man spricht hier auch von „Bananensoftware“. Wie eine Banane reift auch die Software erst beim Kunden.

Gesucht sind also Methoden, die uns helfen, Anforderungen vom Kunden zu erheben und diese so an alle Beteiligten zu kommunizieren, dass dabei keine Information verloren geht. Specification by Example ist so eine Methode.

Specification by Example: Anforderungen in die Form konkreter Beispiele bringen

Die Grundidee hinter Specification by Example ist, Anforderungen gemeinsam in Form von konkreten Beispiele zu spezifizieren und nach einem einfachen Schema zu dokumentieren. Das klare und immer gleiche Schema fördert die Verständlichkeit, die konkreten Beispiele erhöhen die Eindeutigkeit und machen es leichter, die Anforderungen auf Vollständigkeit zu prüfen.

Specification by Example basiert dazu auf 5 Grundprinzipien:

  • 1. Scope von Zielen ableiten: Jede Anforderung wird auf ein Geschäftsziel und einen damit verbundenen Business Value zurückgeführt.
  • 2. Kollaboration: Anforderungen und konkrete Beispiele werden gemeinsam erarbeitet. Entwicklungsteam, PO und Kunde sind beteiligt.
  • 3. Konkrete Beispiele: Anforderungen werden in Form von konkreten Beispielen und nicht abstrakten Umschreibungen spezifiziert.
  • 4. Lebende Dokumentation: Durch den Einsatz von Tools können so formulierte Anforderungen direkt automatisiert getestet werden.
  • 5. Wiederkehrende Validierung: Durch eine hohe Abdeckung der Anforderungen durch automatisierte Tests ist eine erneute Prüfung z.B. nach Änderungen leicht möglich.

Vorgehensweise in der Praxis

Der erste Schritt ist also immer, Geschäftsziele und den zu erreichenden Nutzen des Systems zu definieren. Teil dieser Zieldefinition ist die Überlegung, für wen das Ziel wichtig ist. Dieser Aspekt des „für wen“ wird oft in Form von Personas, also erfundenen Beispiel-Anwendern und -Kunden beschrieben. Im nächsten Schritt werden Geschichten erzählt, wie diese Personas das System nutzen werden. Für jede dieser Geschichten wird als Merker ein Satz mittels der User Story Satzschablone geschrieben:

„Als <Rolle> möchte ich <Aktion>, damit <Nutzen>“

Zu jeder User Story werden nun Bedingungen definiert, die erfüllt sein müssen, damit die User Story abgenommen wird und Wert für den Kunden liefert. Diese Abnahmebedingungen, auch Akzeptanzkriterien genannt, werden wieder nach einer definierten Struktur, dem „Gherkin“-Schema beschrieben:

„Gegeben <Ausgangszustand>, wenn <Aktion>, dann <Ergebnis>“

Inhaltlich werden dabei keine abstrakten Sachverhalte beschrieben, sondern konkrete Beispiele gegeben. Ziel ist es, für jede User Story so viele Beispiele zu spezifizieren, dass alle möglichen Szenarien, Varianten und Sachverhalte der Story abgedeckt sind. Oft gibt man den einzelnen Szenarien noch einen griffigen Titel.

Inhalt des Artikels:

Kommentar zu diesem Artikel abgeben
Wirklich sehr embedded dieser Artikel... Der Kunde erzählt es dem Business Analysten,...  lesen
posted am 17.10.2018 um 09:30 von mjahn


Mitdiskutieren
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 45533548 / Requirements)