Autor: Markus Unterauer, Software Quality Lab<\/p>\n
Specification by Example bedeutet, Anforderungen durch konkrete Beispiele zu spezifizieren. Dazu wird ein fixes Satzschema verwendet, welches ein einfaches Andocken von Testautomatisierung erm\u00f6glicht. So wird aus einem wertlosen Write-Only Dokument eine wertbringende lebende Spezifikation.<\/strong><\/p>\n Eine der schwierigsten Aufgaben in der Softwareentwicklung ist es herauszufinden, was das System eigentlich tun und k\u00f6nnen soll. An dieser Anforderungserhebung sind viele Stakeholder beteiligt. Die Information \u00fcber die Anforderungen des Kunden wandert dabei \u00fcber zahlreiche Stationen. Der Kunde erz\u00e4hlt es dem Business Analysten, der gibt es an den Projektleiter weiter. 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\u00fcfenden 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 \u201eStille Post\u201c (siehe Abbildung 1,\u00a0PDF<\/a>). 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\u00e4gungen unterst\u00fctzen muss.<\/p>\n Zus\u00e4tzliche Verwirrung entsteht, wenn die Information nicht m\u00fcndlich, sondern als schriftliche Spezifikation in Form von Text und Modellen weitergegeben wird. Was f\u00fcr den einen v\u00f6llig klar und verst\u00e4ndlich ist, ist f\u00fcr den anderen nur eine sinnlose Aneinanderreihung von Zeichen. Oder schlimmer noch: Der Empf\u00e4nger der Spezifikation glaubt alles verstanden zu haben, in Wirklichkeit aber weicht sein Bild von den Anforderungen deutlich von dem des Kunden ab.<\/p>\n Das Ergebnis sind oft schlecht designte Systeme, die die Bed\u00fcrfnisse der Kunden nicht erf\u00fcllen. Diese Systeme werden in vielen F\u00e4llen 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.<\/p>\n Gesucht sind also Methoden, die uns helfen, Anforderungen vom Kunden zu erheben und diese so an alle Beteiligten zu kommunizieren, dass dabei keine Information verlorengeht. Specification by Example ist so eine Methode.<\/p>\n Die Grundidee hinter Specification by Example ist, Anforderungen gemeinsam in Form von konkreten Beispielen zu spezifizieren und nach einem einfachen Schema zu dokumentieren. Das klare und immer gleiche Schema f\u00f6rdert die Verst\u00e4ndlichkeit, die konkreten Beispiele erh\u00f6hen die Eindeutigkeit und machen es leichter, die Anforderungen auf Vollst\u00e4ndigkeit zu pr\u00fcfen.<\/p>\n Specification by Example basiert dazu auf 5 Grundprinzipien:<\/p>\n 1. Scope von Zielen ableiten<\/em>: 2.\u00a0Kollaboration<\/em>: 3. Konkrete Beispiele<\/em>: 4. Lebende Dokumentation<\/em>: 5. Wiederkehrende Validierung<\/em>: Der erste Schritt ist also immer, Gesch\u00e4ftsziele und den zu erreichenden Nutzen des Systems zu definieren. Teil dieser Zieldefinition ist die \u00dcberlegung, f\u00fcr wen das Ziel wichtig ist. Dieser Aspekt des „f\u00fcr wen“ wird oft in Form von Personas, also erfundenen Beispiel-Anwendern und -Kunden, beschrieben. Im n\u00e4chsten Schritt werden Geschichten erz\u00e4hlt, wie diese Personas das System nutzen werden. F\u00fcr jede dieser Geschichten wird als Merker ein Satz mittels der User-Story-Satzschablone geschrieben:<\/p>\n \u00a0„Als <Rolle> m\u00f6chte ich <Aktion>, damit <Nutzen>“<\/em><\/p>\n Zu jeder User Story werden nun Bedingungen definiert, die erf\u00fcllt sein m\u00fcssen, damit die User Story abgenommen wird und Wert f\u00fcr den Kunden liefert. Diese Abnahmebedingungen, auch Akzeptanzkriterien genannt, werden wieder nach einer definierten Struktur, dem „Gherkin“-Schema beschrieben:<\/p>\n „Gegeben <Ausgangszustand>, wenn <Aktion>, dann <Ergebnis>“<\/em><\/p>\n Inhaltlich werden dabei keine abstrakten Sachverhalte beschrieben, sondern konkrete Beispiele gegeben. Ziel ist es, f\u00fcr jede User Story so viele Beispiele zu spezifizieren, dass alle m\u00f6glichen Szenarien, Varianten und Sachverhalte der Story abgedeckt sind. Oft gibt man den einzelnen Szenarien noch einen griffigen Titel.<\/p>\n Beispiel:<\/em><\/p>\n Ziel:<\/p>\n Bauen eines Smart Home, das einer kleinen Familie das Leben erleichtert.<\/em><\/p>\n User Story:<\/p>\n Als arbeitender Papa m\u00f6chte ich rechtzeitig geweckt werden, damit ich p\u00fcnktlich in der Arbeit bin.<\/em><\/p>\n Akzeptanzkriterien in Form von Beispielen (siehe Abbildung 2,\u00a0PDF<\/a>):<\/p>\n Die konkreten Beispiele in den Akzeptanzkriterien sollen das Verhalten des Systems in allen Varianten beschreiben. Man spricht deshalb oft auch von „Behaviour Driven Development“. Beim Schreiben von User Stories und Akzeptanzkriterien nach diesem Ansatz haben sich einige Best Practices herauskristallisiert:<\/p>\n Durch die Verwendung einer standardisierten Satzstruktur k\u00f6nnen User Story und Akzeptanzkriterien als Andockpunkt f\u00fcr automatisierte Tests verwendet werden. Tools wie Cucumber und Fitnesse erm\u00f6glichen es, User Stories und Akzeptanzkriterien zu verwalten und sie um Testcode zu erg\u00e4nzen.<\/p>\n Feature: User authentication<\/p>\n User Story: In order to protect access to the HMI<\/p>\n As a system administrator<\/p>\n I want that all users need to be authorized<\/p>\n Scenario: Autologin after 60 seconds<\/p>\n Given HMI started with default configuration<\/p>\n When user waits for 60 seconds at the login screen<\/p>\n Then Default user should be logged in automatically<\/p>\n [Given(„HMI started with default configuration“)]<\/p>\n public void GivenTheStartedHMIWithMachineConfiguration()<\/p>\n {<\/p>\n \u00a0\u00a0 TestBase.loginForm = TestBase.app.Start();<\/p>\n }<\/p>\n [Then(„(.*) user should be logged in automatically“)]<\/p>\n public void ThenLoggedInUser(string user)<\/p>\n {<\/p>\n \u00a0 Assert.That(frameFunctions.UserGroup,Is.EqualTo(user));<\/p>\n }<\/p>\n Manche \u00a0Tools erlauben es auch, die konkreten Werte f\u00fcr die Szenarien in einer Tabelle darzustellen. Das Szenario selbst beinhaltet dann Platzhalter. Dies ist k\u00fcrzer und \u00fcbersichtlicher, als w\u00fcrde man f\u00fcr jedes Szenario den vollen Satz nach dem Gherkin-Schema schreiben. Durch das Auslagern der Werte in eine Tabelle geht allerdings auch eine Spur Konkretheit in der Formulierung der Akzeptanzkriterien verloren.<\/p>\n Szenariogrundriss: Plausbilit\u00e4tspr\u00fcfung im Handbetrieb<\/p>\n \u00a0 Angenommen die Werte ‚<Werkstoff>‘, <Blechdicke>,<Biegewinkel> im Handbetrieb<\/p>\n \u00a0 Wenn der Bediener die Vorberechnung startet<\/p>\n \u00a0 Dann ist ‚UpperDeadPoint‘ <= ‚MutePoint1‘<\/p>\n \u00a0 Und ‚ClampingPoint‘ <= ‚LowerDeadPoint‘<\/p>\n \u00a0 Und ‚DecompressionPoint‘ <= ‚LowerDeadPoint‘<\/p>\n \u00a0 Und ‚ClampingPoint‘ – ‚MutePoint1‘ = ‚MuteDistance1‘<\/p>\n \u00a0 Beispiele:<\/p>\n \u00a0\u00a0\u00a0 | Werkstoff | Blechdicke | Biegewinkel |<\/p>\n \u00a0\u00a0\u00a0 | 1.0038\u00a0\u00a0\u00a0 | 0,1\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 |\u00a0 90,0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 |<\/p>\n \u00a0\u00a0\u00a0 | 1.0038\u00a0\u00a0\u00a0 | 1,0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 |\u00a0 90,0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 |<\/p>\n \u00a0\u00a0\u00a0 | 1.0038\u00a0\u00a0\u00a0 | 3,0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 |\u00a0 90,0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 |<\/p>\n Sind Anforderungen auf diese Weise mit automatisiert ausf\u00fchrbaren Testf\u00e4llen verbunden, spricht man von einer „lebenden Spezifikation“. Der gesamte Ablauf der Erstellung einer solchen von der Anforderung bis zum Test besteht aus 6 Schritten:<\/p>\n 1. Spezifizieren<\/p>\n 2. Testschritte implementieren<\/p>\n 3. Test ausf\u00fchren<\/p>\n 4. Programmcode schreiben<\/p>\n 5. Kontinuierliches Feedback von den Tests einholen<\/p>\n 6. Fertig!<\/p>\n Dieses Vorgehen unterst\u00fctzt also einen \u00a7Test-First“-Ansatz, bei dem zuerst ein vollst\u00e4ndiges Set an automatisierten Tests geschrieben wird, welche die Anforderung vollst\u00e4ndig abdecken. Danach erst wird solange Programmcode geschrieben, bis alle Tests gr\u00fcn sind.<\/p>\n Richtig angewandt erm\u00f6glicht Specification by Example, Sonderf\u00e4lle fr\u00fcher und vollst\u00e4ndiger zu beachten und dadurch Fehler zu vermeiden. Durch die Beteiligung von Kunde, PO und Team bei der Erstellung wird ein gemeinsames Verst\u00e4ndnis der Anforderungen gef\u00f6rdert. Die Automatisierung der Tests schlie\u00dflich erm\u00f6glicht es, auch bei \u00c4nderungen an Anforderungen jederzeit sicher zu sein, dass noch alle Szenarien einwandfrei funktionieren.<\/p>\n Gojko Adzic, „Specification by Example“, Manning Verlag, 2011<\/p>\n Johannes Bergsmann, Markus Unterauer, „Requirements Engineering f\u00fcr die agile Softwareentwicklung“, dpunkt.Verlag, 2014<\/p>\n Markus Unterauer, „Workshops im Requirements Engineering“, dpunkt.Verlag, 2014<\/p>\n Beitrag als PDF downloaden<\/strong><\/a><\/p>\n Wollen Sie sich auf den aktuellen Stand der Technik bringen?<\/strong><\/p>\n Dann informieren Sie sich\u00a0hier<\/strong>\u00a0<\/a>zu Schulungen\/ Seminaren\/ Trainings\/ Workshops und individuellen Coachings von MircoConsult zum Thema Requirements \/Embedded- und Echtzeit-Softwareentwicklung.<\/p>\n Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie\u00a0hier<\/a>.<\/strong><\/p>\n Wertvolles Fachwissen zum Thema Requirements\/Embedded- und Echtzeit-Softwareentwicklung steht\u00a0hier<\/strong>\u00a0<\/a>f\u00fcr Sie zum kostenfreien Download bereit.<\/p>\n
\nJede Anforderung wird auf ein Gesch\u00e4ftsziel und einen damit verbundenen Business Value zur\u00fcckgef\u00fchrt.<\/p>\n
\nAnforderungen und konkrete Beispiele werden gemeinsam erarbeitet. Entwicklungsteam, PO und Kunde sind beteiligt.<\/p>\n
\nAnforderungen werden in Form von konkreten Beispielen und nicht abstrakten Umschreibungen spezifiziert.<\/p>\n
\nDurch den Einsatz von Tools k\u00f6nnen so formulierte Anforderungen direkt automatisiert getestet werden.<\/p>\n
\nDurch eine hohe Abdeckung der Anforderungen durch automatisierte Tests ist eine erneute Pr\u00fcfung z.B. nach \u00c4nderungen leicht m\u00f6glich.<\/p>\n\n
\nGegeben es gibt keine Verkehrsbehinderungen, wenn ich ‚Arbeitstag‘ aktiviere, dann ist die Weckzeit 8:15“<\/em><\/li>\n
\nGegeben ich brauche normalerweise 30 Minuten zur Arbeit und ich habe um 9 Uhr das Daily Scrum Meeting und es gibt 20 Minuten Stau, wenn ich ‚gem\u00fctlich Fr\u00fchst\u00fccken‘ aktiviere, dann ist die eingestellte Weckzeit 6:10.“<\/em><\/li>\n
\nGegeben ich brauche 30 Minuten zur Arbeit und ich habe um 9 Uhr das Daily Scrum Meeting und es gibt keine Verkehrsbehinderungen, wenn ich ‚lange schlafen‘ aktiviere, dann ist die eingestellte Weckzeit 8:15.“<\/em><\/li>\n<\/ul>\n\n
\n(also statt „Wert eingeben“ die konkrete Zahl, z.B. „5.212,65 eingeben“)<\/li>\n<\/ul>\nQuellen<\/h2>\n
\nRequirements – MicroConsult Trainings & Coachings<\/h2>\n
\nRequirements – Fachwissen<\/h2>\n