Im Stich gelassen - Requirements for Software Architects

Slide 1

Slide 1 text

Im Stich gelassen? Dr. Gernot Starke Dr. Peter Hruschka

Slide 2

Slide 2 text

Der Workshop zum Thema... CPSA-A Modul „Requirements For Architects“ (REQ4ARC) https://arc42.de/req4arc-requirements-fuer-architekten „The goal of this module is to equip architects with enough requirements know-how, so they can take educated architecture decisions, based on real needs of stakeholders.“

Slide 3

Slide 3 text

Peter Hruschka, Gernot Starke Requirements Skills erfolgreicher Softwareteams Hanser-Verlag, (voraussichtlich 2. Quartal 2020) X Requirements-Skills erfolgreicher Softwareteams peter HRUSCHKA gernot STARKE LIKE NEED WANT ALT A S Z

Slide 4

Slide 4 text

Dr. Gernot Starke INNOQ Fellow • Architecture-Improver • Coach, Trainer • Founder arc42, aim42 • iSAQB e.V.

Slide 5

Slide 5 text

Dr. Peter Hruschka Atlantic Systems Guild • Agile Requirements Engineer & Architect • Coach, Trainer, Autor • Founder arc42, req42 • Founding Member IREB e.V, iSAQB e.V.

Slide 6

Slide 6 text

garbage in, garbage out

Slide 7

Slide 7 text

f(x) Exkurs: Mathematik (genauer: Analysis)

Slide 8

Slide 8 text

y = f(t) transformieren Eingabedaten Funktionen ...

Slide 9

Slide 9 text

Input Requirements Output Software

Slide 10

Slide 10 text

sw = t(req) sw : Software req : Anforderungen t : Team Funktionen ...

Slide 11

Slide 11 text

Input Output

Slide 12

Slide 12 text

Input Output ? Photo by John Cameron on Unsplash

Slide 13

Slide 13 text

Requirements-Chaos Statt „echter“ Product-Owner: • Konkurrierende Fachabteilungen • Ständig wechselnde Prioritäten • Unklare Vorgaben • Diffuse Begriffe

Slide 14

Slide 14 text

Wer bekommt Prügel? Entwicklungsteam L Photo by Aimee Vogelsang on Unsplash

Slide 15

Slide 15 text

Ziele: Entwicklungsteams („Architekt*innen) in die Lage versetzen, • fehlende, • schlechte, • unpassende Anforderungen verbessern, gemeinsam mit Stakeholdern! Architektur analysieren + bewerten Anforderungen und Randbedingungen klären Querschnittliche Konzepte entwerfen Umsetzung begleiten Architektur kommunizieren Strukturen entwerfen

Slide 16

Slide 16 text

Nicht-Ziele Requirements-Engineering oder Business-Analyse: • ersetzen • abschaffen • vom Entwicklungsteam übernehmen lassen

Slide 17

Slide 17 text

dann geht‘s! Foto: Peter Hruschka

Slide 18

Slide 18 text

Anforderungen klären gehört zur Architekturarbeit Architektur analysieren + bewerten Anforderungen und Randbedingungen klären Querschnittliche Konzepte entwerfen Umsetzung begleiten Architektur kommunizieren Strukturen entwerfen

Slide 19

Slide 19 text

Architecturally Significant Requirements Architektur analysieren + bewerten Anforderungen und Randbedingungen klären Querschnittliche Konzepte entwerfen Umsetzung begleiten Architektur kommunizieren Strukturen entwerfen Anforderungen, die besondere Auswirkung auf Architektur haben (können).

Slide 20

Slide 20 text

Architektur- relevante Anforderungen

Slide 21

Slide 21 text

Architekturrelevante Anforderungen • Ziele/Vision • Stakeholder • Kontextabgrenzung • Funktionale Anforderungen • Qualitätsanforderungen • Randbedingungen • Nicht-Anforderungen Was soll das System/ Produkt tun? Wie schnell, sicher, flexibel, zuverlässig, teuer, ......? Unter welchen Einschränkungen entwickeln und betreiben (Technik, Team, Ressourcen, Prozessen, bestehenden Systemen...)? Was nicht tun/leisten? externe Schnittstellen, Scope? W o wollen wir hin? Wer hat Anforderungen?

Slide 22

Slide 22 text

Scope (Abgrenzung des Umfangs) Stakeholder Vision /Ziele Der erfolgreiche (Projekt-) Start Auch agile Projekte brauchen etwas „upfront“

Slide 23

Slide 23 text

Ziele / Vision The vision describes why the project is being undertaken and what the desired end state is.” (Ken Schwaber 2004) Sie sollten verstehen: • Wie sich Ihr Produkt mit existierenden Produkten in der Fima oder beim Mitbewerb vergleicht? Was sind die „unique selling points“ (USPs) • Was für den Produkterfolg kritisch ist?

Slide 24

Slide 24 text

Ziele sind Anforderungen welche sich im Laufe des Projekts nicht dauernd ändern (sollen L) die Eine Firma für Telekonferenzsysteme: • Überragende Audioqualität – mehr als einer kann gleichzeitig sprechen und wird immer noch verstanden • Einfach zu benutzen – ohne viele Knöpfe und Strippen • Erstklassiges Aussehen – muss in Vorstandszimmer passen. Beispiel:

Slide 25

Slide 25 text

Nicht die Form, der Inhalt zählt P Produktname Verkaufsargument1 Verkaufsargument 2 Verkaufsargument 3 Logo/ Symbol „News from the Future“ Fiktiver Artikel aus der Zukunft, beschreibt den Tag nach der Produktpräsentation. Der Artikel beschreibt warum das Produkt „Klasse ist“ und Sie es kaufen (oder das System beauftragen) sollten. P Purpose: Beschreiben Sie den Zweck Advantage: Welche Vorteile soll das Produkt bringen? Measure: wie kann man die Vorteile messen? Der „Produktkoffer“ 3 – 5 PAM-Kärtchen

Slide 26

Slide 26 text

Stakeholder Photo by Yiran Ding on Unsplash Management, Auftraggeber, Projekt-Steuerkreis, sonstige Projekt-Gremien, PMO, Projektmanager, Produktmanager, Fachbereich, Unternehmens-/Enterprise- Architekt, Architektur- Abteilung, Methoden- Abteilung, QS-Abteilung, IT- Strategie, Software-Architekt, Software-Designer, Entwickler, Tester, Konfigurationsmanager, Build- Manager, Release-Manager, Wartungsteam, externe Dienstleister, Zulieferer, Hardware-Designer, Rollout- Manager, Infrastruktur-Planer, Sicherheitsbeauftragter, Behörde, Aufsichtsgremium, Auditor, Mitbewerber/Konkurrent, Endanwender, Fachpresse, Fachadministrator, Systemadministrator, Operator, Hotline, Betriebsrat, Lieferant von Standardsoftware, verbundene Projekte, Normierungsgremium, Gesetzgeber...

Slide 27

Slide 27 text

Photo by Yiran Ding on Unsplash kennen wir deren Anforderungen?

Slide 28

Slide 28 text

Stakeholder vergessene Stakeholder bedeuten vergessene Anforderungen Photo by Yiran Ding on Unsplash

Slide 29

Slide 29 text

Tipp (mehrere!) Stakeholder involvieren: • Fachbereiche • User • Betrieb / Hardware • (Top-)Management • Verantwortliche von Nachbarsystemen

Slide 30

Slide 30 text

No content

Slide 31

Slide 31 text

Klassische Notation und Alternativen IMMER 3 Bestandteile: mein System ALLE Nachbarsysteme die Schnittstellen Das Kontextdiagramm ist DAS wichtigste Bild, das Sie in Ihrem Projekt zeichnen sollten

Slide 32

Slide 32 text

CHEESEBURGER HERSTELLEN Sesame Bun Beef Patty Cheese Veggies SCHÄTZEN SIE DEN PROJEKTAUFWAND

Slide 33

Slide 33 text

CHEESEBURGER HERSTELLEN Eier, Milch, Fleisch Bauernhof Tomaten, Salat Bio-Bauer Mehl Bäcker Gewürze Gewürz- regal WOLLEN SIE IHRE SCHÄTZUNG KORRIGIEREN?

Slide 34

Slide 34 text

CHEESEBURGER HERSTELLEN Eier, Milch, Fleisch Bauernhof Tomaten, Salat Bio-Bauer Mehl Bäcker Gewürze Gewürz- regal ANNOTIEREN SIE POTENTIELLE SCHNITTSTELLENPROBLEME Achtung: Schlachtung nur am Freitag Pattern 43: Die VERFLIXTEN SCHNITTSTELLEN

Slide 35

Slide 35 text

Business-SCOPE vs. PRODUCT SCOPE CONTEXT YOUR BUSINESS YOUR Product Fangen SIE MIT DEM BUSINESS SCOPE AN LEGEN SIE ERST DANN DEN PRODUCT SCOPE FEST

Slide 36

Slide 36 text

Tipps Externe Schnittstellen kennen: • fachliche Bedeutung • „Gegenstelle“ • Volatilität • Q-Anforderungen: Volumen, Durchsatz, Reaktionszeit, Verfügbarkeit

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Granularität von funktionalen Anforderungen Für Entwicklungsteams wichtig: Überblick! (Details brauchen wir erst „Just in Time“)

Slide 39

Slide 39 text

YOUR BUSINESS YOUR Product Teile und beherrsche - aber wie?

Slide 40

Slide 40 text

Was haben die folgenden Dinge GEMEINSAM? Programmablaufpläne (Flussdiagramme) NASSI-SHNEIDERMAN- DIAGRAMME DATENFLUSS- DIAGRAMME USE-CASES ACTIVITY- DIAGRAMME User Stories BPMN Ereignis- Prozess- Ketten (EPK)

Slide 41

Slide 41 text

ERRATEN? DENKEN in durchgängigen Prozessen von AUSSEN AUSGELÖST (Externer Trigger oder Zeittrigger) Quer durch das System erzeugt Mehrwert für EINEN STAKEHOLDER

Slide 42

Slide 42 text

Prozesse - die natürlichste Zerlegung eines großen Systems

Slide 43

Slide 43 text

Zusammenarbeit im Team DISCOVER DELIVER https://www.discovertodeliver.com/index.php Nach: Ellen Gottesdiener

Slide 44

Slide 44 text

Zusammenarbeit - konkreter DISCOVER DELIVER Story Map Top Level Epics Selected Stories Release https://www.discovertodeliver.com/index.php

Slide 45

Slide 45 text

Tipps • Business-Ziele explizit aufschreiben (lassen) • High-Level („Ende-zu-Ende“) Prozesse kennen • Mehrwert für Nutzer*innen kennen • Iterativ verfeinern

Slide 46

Slide 46 text

Qualitäts- anforderungen

Slide 47

Slide 47 text

Qualität: Erfüllung von Eigenschaften.

Slide 48

Slide 48 text

Qualität: Erfüllung von Eigenschaften.

Slide 49

Slide 49 text

Erfüllung von Eigenschaften. n meistens groß.

Slide 50

Slide 50 text

Erfüllung von Eigenschaften. Beispiel: Hotel. Anzahl-Zimmer, Konferenzräume, Essen, Preis- pro-Übernachtung, Tagungspreis, Fitness-Raum, WLAN, Verfügbarkeit.

Slide 51

Slide 51 text

Erfüllung von Eigenschaften. n meistens groß. Und abhängig von Stakeholdern.

Slide 52

Slide 52 text

Erfüllung von Eigenschaften. Beispiel: Hotel. Stakeholder: Anzahl-Zimmer, Konferenzräume, Essen, Preis-pro-Übernachtung, Tagungspreis, Fitness-Raum, WLAN, Verfügbarkeit. Zahlung per PayPal/Diners? Veganes | Gluten-freies Essen? Sauna-für-Damen? Ohne-Vorauszahlung-für-Tagung? Mit Ladestation für e-Auto? VPN-fähiges WLAN?

Slide 53

Slide 53 text

Erfüllung von Eigenschaften. n meistens groß. Und abhängig von Stakeholdern. Für Software?

Slide 54

Slide 54 text

Sicherheit, Zuverlässigkeit, Benutzbarkeit, Einfachheit, Korrektheit, Robustheit, Skalierbarkeit, Wartbarkeit, Fehlertoleranz, Betreibbarkeit, Laufzeiteffizienz, Speichereffizienz, Wiederherstellbarkeit, Ausfallsicherheit, Safety, Vertraulichkeit, Nicht-Abstreitbarkeit, Anpassbarkeit, Installierbarkeit, Kapazität, Durchsatz, Latenz, Antwortzeit, Analysierbarkeit, Testbarkeit, Vertraulichkeit, Integrität, Funktionale Vollständigkeit, Reife, Erlernbarkeit, Nützlichkeit, Ästhetik, Administrierbarkeit, Austauschbarkeit, Barrierefreiheit, Genauigkeit, Glaubwürdigkeit, Interoperabilität, Kompatibilität, Koexistenz, Portierbarkeit, Konformität, Konsistenz, Lokalisierbarkeit, Modularität, Nachvollziehbarkeit, Nichtangreifbarkeit, Normgerechtigkeit, Personalisierbarkeit, Reaktionszeit, Startup-Zeit, Strapazierfähigkeit, Überprüfbarkeit, Verteilbarkeit

Slide 55

Slide 55 text

Orientierungshilfe für {heiten|keiten}

Slide 56

Slide 56 text

Nachteil des ISO-Modells... unspezifisch: Begriffen lassen Raum für Interpretation. Beispiel: „Availability“.

Slide 57

Slide 57 text

Anti-Beispiel „Availability“ neulich, im Urlaub:

Slide 58

Slide 58 text

Anti-Beispiel „Availability“ neulich, im Urlaub:

Slide 59

Slide 59 text

Anti-Beispiel „Availability“ neulich, im Urlaub:

Slide 60

Slide 60 text

Zweiter Versuch: Spezifischer... • Eine Benutzerin sucht verfügbare Flüge für gegebenen Abflug- und Zielort sowie Datum. • Das System liefert in 99% der Fälle die ersten Resultate innerhalb von einer Sekunde innerhalb der Website.

Slide 61

Slide 61 text

Beispiel „Laufzeit" Die Ladezeit der Titelseite darf für Benutzer, die auf die Website per Smartphone über LTE zugreifen, höchstens 2 Sekunden betragen.

Slide 62

Slide 62 text

Beispiel „Änderbarkeit“ (1) Spätestens 4h nach dem Erscheinen von Reisewarnungen des Auswärtigen Amtes müssen diese bei der Suche nach Flugreisen berücksichtigt werden.

Slide 63

Slide 63 text

Beispiel „Änderbarkeit“ (2) Die Integration eines neuen Lieferdienstes von Lebensmitteln (LLD) in unsere Website muss innerhalb von max 1PT möglich sein, sofern dieser LLD eine JSON/Rest API anbietet.

Slide 64

Slide 64 text

Qualitäts-Szenarien beschreiben (konkret, messbar), wie System auf bestimmte Ereignisse reagieren soll. System Nutzung Ereignis, Stimulus Reaktion Metrik Änderung

Slide 65

Slide 65 text

aber...

Slide 66

Slide 66 text

Manche Qualitätsanforderungen widersprechen oder beeinflussen sich gegenseitig.

Slide 67

Slide 67 text

Beispiel: Höchste Sicherheit und großartige Useability.

Slide 68

Slide 68 text

Daher: Entwicklungsteams (Sie!) müssen Qualitätsanforderungen detailliert auf Nebenwirkungen analysieren.

Slide 69

Slide 69 text

Vorschlag Workshop mit Stakeholdern. • “Q-Themen“ auf „Radar“ eintragen • Stakeholder schreiben Post-It-Notes mit Szenarien... • ... und priorisieren (wichtig: weiter innnen) Reliability Testability Security Performance Availability Modiﬁability Operability Usability <…> <…> <…> Quality Attribute Web [Keeling-17] …. …. …. …. …. …. …. ….

Slide 70

Slide 70 text

Tipps zu Qualitätsanforderungen So spezifisch wie möglich: 1. Konkret mess- oder testbar 2. An Funktionen oder Features orientieren

Slide 71

Slide 71 text

Quellen (1) • Peter Hruschka: Business Analysis und Requirements Engineering: Produkte und Prozesse nachhaltig verbessern. Hanser- Verlag. • S+J. Robertson: Mastering the Requirements Process: Getting Requirements Right. Addision-Wesley. • T+A Hathaway: Getting and Writing IT Requirements in Lean and Agile World. Leanpub.

Slide 72

Slide 72 text

Quellen (2) • arc42 Beispiele für Qualitätsanforderungen: https://github.com/arc42/quality-requirements

Slide 73

Slide 73 text

Behaviour Driven Development

Slide 74

Slide 74 text

No content

Slide 75

Slide 75 text

Behaviour Example Driven Development

Slide 76

Slide 76 text

Business Ziele Scope, Kontext Schlüssel- Beispiele Speziﬁkation mit Beispielen gemeinsam speziﬁzieren Beispiele statt Abstraktionen

Slide 77

Slide 77 text

Hierarchie von Anforderungen... ausführbar Vision ausführbare Speziﬁkationen (Code) konkret abstrakt …..

Slide 78

Slide 78 text

Hierarchie von Anforderungen... ausführbar

Slide 79

Slide 79 text

Domain-Storytelling... Funktionen / Prozesse aus Sicht der Akteure Schlüssel- Beispiele Speziﬁkation mit Beispielen Schüler (Franz) oﬄine nutzt App Regulärer Stundenplan zeigt an Schülerin (Lea) online nutzt App Stundenplan zeigt an aktuelle Vertretungen aktuelle Raumzuordnung Siehe: https://www.domainstorytelling.org

Slide 80

Slide 80 text

ausführbare Specs als Verfeinerung verfeinert durch unterstützt durch Business- Ziel Features Szenario (Beispiele) ausführbare Szenarien Low-Level Speziﬁkationen verfeinert durch verfeinert durch Quellcode des Systems verwendet Vision ausführbare Speziﬁkationen (Code) konkret abstrakt …..

Slide 81

Slide 81 text

Given-When-Then... Business- Ziel Features Szenario (Beispiele) ausführbare Szenarien Low-Level Speziﬁkationen Given a web browser is on the Google page When the search phrase "panda" is entered Then results for "panda" are shown

Slide 82

Slide 82 text

Meta Beispiel Beispiel für ein Beispiel – aus „The Cucumber for Java Book“

Slide 83

Slide 83 text

Ein Feature... Feature: Checkout Scenario: Checkout a banana Given the price of a "banana" is 40c When I checkout 1 "banana" Then the total price should be 40c

Slide 84

Slide 84 text

Feature: Google Searching As a web surfer, I want to search Google, so that I can learn new things. Scenario: Simple Google search Given a web browser is on the Google page When the search phrase "panda" is entered Then results for "panda" are shown And the result page displays the text ""“ Scientific name: Ailuropoda melanoleuca Conservation status: Endangered (Population decreasing) """ https://automationpanda.com/2017/01/27/bdd-101-gherkin-by-example/ Noch ein Feature...

Slide 85

Slide 85 text

Given-When-Then... Given When Then Ausgangssituation, „initial context“ etwas geschieht erwartetes Resultat Ausgangssituation, „initial context“ etwas geschieht erwartetes Resultat Szenario (Beispiele) ausführbare Szenarien

Slide 86

Slide 86 text

Given When Then Given-When-Then... ähnlich wie TDD, nur höhere Ebene

Slide 87

Slide 87 text

Given-When-Then... • Vorbedingung • Setup (Daten, Files, Hardware oä) Feature: Checkout Scenario: Checkout a banana Given the price of a "banana" is 40c .... Feature: Web-Search Scenario: Simple search Given a web browser is on the google page ....

Slide 88

Slide 88 text

Given-When-Then... • Interaktion „User“ (oder API) mit System • Auslösen eines Use-Case Feature: Checkout Scenario: Checkout a banana Given the price of a "banana" is 40c When I checkout 1 "banana“ Feature: Web-Search Scenario: Simple search Given a web browser is on the google page When search phrase "panda" is entered

Slide 89

Slide 89 text

Given-When-Then... • Ergebnis • Erwartetes / notwendiges Resultat Feature: Checkout Scenario: Checkout a banana Given the price of a "banana" is 40c When I checkout 1 "banana“ Then the total price should be 40c Feature: Web-Search Scenario: Simple search Given a web browser is on the google page When search phrase "panda" is entered Then results for „panda“ are shown

Slide 90

Slide 90 text

Zur Vereinfachung der Praxis (1)... Feature: Checkout Background: Given the price of a "banana" is 40c Scenario: Checkout a banana When I checkout 1 "banana" Then the total price should be 40c Scenario: Checkout three bananas When I checkout 3 "banana" Then the total price should be 1€20c

Slide 91

Slide 91 text

Zur Vereinfachung der Praxis (2)... Scenario Outline: eating Given there are cucumbers When I eat cucumbers Then I should have cucumbers Examples: | start | eat | left | | 12 | 5 | 7 | | 20 | 5 | 15 | https://cucumber.io/docs/gherkin/reference/

Slide 92

Slide 92 text

„Disclaimer“ zu Tools: Rein subjektiv. Kein gründlicher Marktüberblick. Stellen keine Empfehlung dar.

Slide 93

Slide 93 text

Tooling (1): die Basis

Slide 94

Slide 94 text

Tools für BDD verfeinert durch unterstützt durch Business- Ziel Features Szenario (Beispiele) ausführbare Szenarien Low-Level Speziﬁkationen verfeinert durch verfeinert durch In Gherkin Feature-Files Quellcode des Systems verwendet spockframework

Slide 95

Slide 95 text

Feature ausführen (1)... Feature: Checkout Scenario: Checkout a banana Given the price of a "banana" is 40c When I checkout 1 "banana" Then the total price should be 40c $ gradle cucumber > Task :cucumber Feb 29, 2020 1:51:59 PM io.cucumber.core.cli.Main run Undefined scenarios: file:...CfJB-checkout-naive.feature:6# Checkout a banana 1 Scenarios (1 undefined) 3 Steps (3 undefined) 0m0,127s You can implement missing steps with the snippets below: @Given("the price of a {string} is 40c") public void the_price_of_a_is_40c(String string) { // Write code here that turns the phrase above into concrete actions throw new io.cucumber.java.PendingException(); } @When("I checkout {int} {string}") public void i_checkout(Integer int1, String string) { // Write code here that turns the phrase above into concrete actions throw new io.cucumber.java.PendingException(); } ....

Slide 96

Slide 96 text

Feature ausführen (1)... ... Given the price of a "banana" is 40c @Given("the price of a {string} is 40c") public void the_price_of_a_is_40c(String string) { // Write code here that turns the phrase above into concrete actions throw new io.cucumber.java.PendingException(); } ....

Slide 97

Slide 97 text

kleiner Exkurs: Reguläre Ausdrücke Expression Bedeutung (.*) Match any string (\\d+) Match any number ^ Any beginning of a string $ Any end of a string @Given("^the price of a \"(.*?)\" is (\\d+)c$") public void thePriceOfAIsC(String name, int price) throws Throwable { .... }

Slide 98

Slide 98 text

Feature ausführen (2)... public class CheckoutSteps { Checkout checkout; int bananaPrice = 0; @Given("^the price of a \"(.*?)\" is (\\d+)c$") public void thePriceOfAIsC(String name, int price) throws Throwable { bananaPrice = price; } @When("^I checkout (\\d+) \"(.*?)\"$") public void iCheckout(int itemCount, String itemName) throws Throwable { checkout = new Checkout(); checkout.add(itemCount, bananaPrice); } @Then("^the total price should be (\\d+)c$") public void theTotalPriceShouldBeC(int total) throws Throwable { assertEquals(total, checkout.total()); } }

Slide 99

Slide 99 text

These: BDD-Szenarien ausführen funktioniert. Beweis (durch Beispiele) : cucumber, RSpec, SpecFlow, JBehave, Behat...

Slide 100

Slide 100 text

Übung: Try-it-yourself Entwickeln Sie „n“ (mit n>1) Szenarien für folgenden Use-Case: „Als Besucher kann ich alle verfügbaren Flüge für mein Reisedatum und mein Reiseziel sehen, um die beste Option auszuwählen.“ Nach: „T+A Hathaway“ (siehe Anhang)

Slide 101

Slide 101 text

These: Ihr Business versteht diese Szenarien.

Slide 102

Slide 102 text

These (2): Sie merken, ob ihre Anforderungen konkret genug sind.

Slide 103

Slide 103 text

Tooling (2): Serenity BDD http://www.thucydides.info

Slide 104

Slide 104 text

Ausführbare Specs Aktueller Status im Überblick

Slide 105

Slide 105 text

Tooling (3): Cucumber-Studio https://studio.cucumber.io/projects

Slide 106

Slide 106 text

Tooling (3): Cucumber-Studio https://studio.cucumber.io/projects

Slide 107

Slide 107 text

Wo sollten wir BDD einsetzen? "In all places where business has opinions about the behaviour.“ https://cucumber.io/blog/bdd/where_should_you_use_bdd/

Slide 108

Slide 108 text

Tipps zu BDD • Given-When-Then Beschreibung von Anforderungen im Team versuchen • Eines der BDD-Tools ausprobieren • Fachbereich involvieren („3-Amigo-Session“)

Slide 109

Slide 109 text

Von User-Stories zu BDD-Szenarien nach: T+A Hathaway (siehe Anhang)

Slide 110

Slide 110 text

Struktur einer User-Story üWER benötigt etwas? üWAS benötigen sie? üWARUM brauchen sie das? üWHO needs something? üWHAT do they need? üWHY do they need it?

Slide 111

Slide 111 text

von User-Story zu Szenario (2) 3. ... 2. WAS 1. WARUM „Als Besucher kann ich alle verfügbaren Flüge für mein Reisedatum und mein Reiseziel sehen, um die beste Option auszuwählen.“

Slide 112

Slide 112 text

von User-Story zu Szenario (3) 3. ... 2. WAS 1. WARUM „Als Besucher kann ich alle verfügbaren Flüge für mein Reisedatum und mein Reiseziel sehen, um die beste Option auszuwählen.“ Für einen Besucher könnte die beste Option bedeuten: 1. niedrigste Kosten, so bald wie möglich verfügbar 2. niedrigste Kosten in den nächsten 4 Wochen 3. Flug mit den wenigsten Zwischenstopps 4. Abflug nahe einer vorgegebenen Zeit 5. Frühester Flug zu gegebenem Datum 6. Letzter möglicher Flug zu gegebenem Datum 7. Flug mit Bonusmeilen des vorgegebenen Bonus-Programmes bezahlbar

Slide 113

Slide 113 text

von User-Story zu Szenario (4) 3. ... 2. WAS 1. WARUM „Als Besucher kann ich alle verfügbaren Flüge für mein Reisedatum und mein Reiseziel sehen, um die beste Option auszuwählen.“ Für einen Besucher könnte die beste Option bedeuten: 1. niedrigste Kosten, so bald wie möglich verfügbar 2. niedrigste Kosten in den nächsten 4 Wochen 3. Flug mit den wenigsten Zwischenstopps 4. Abflug nahe einer vorgegebenen Zeit 5. Frühester Flug zu gegebenem Datum 6. Letzter möglicher Flug zu gegebenem Datum 7. Flug mit Bonusmeilen des vorgegebenen Bonus-Programmes bezahlbar Szenario: Fred sucht Flug mit wenigen Stopps Given Fred ist auf der Buchungs-Website When Fred möchte Flüge mit möglichst wenigen Zwischenstopps sehen Then Flüge werden sortiert aufsteigend nach nach Anzahl Stopps angezeigt

Slide 114

Slide 114 text

von User-Story zu Szenario (5) 3. ... 2. WAS 1. WARUM „Als Besucher kann ich alle verfügbaren Flüge für mein Reisedatum und mein Reiseziel sehen, um die beste Option auszuwählen.“

Slide 115

Slide 115 text

von User-Story zu Szenario (6) 3. ... 2. WAS 1. WARUM „Als Besucher kann ich alle verfügbaren Flüge für mein Reisedatum und mein Reiseziel sehen, um die beste Option auszuwählen.“ Für einen Besucher könnte „Flüge sehen“ bedeuten: 1. Bekomme Liste von Flügen auf Website angezeigt, sortiert nach Abflugzeit 2. Bekomme Liste von Flügen auf Website angezeigt, sortiert nach Preis aufsteigend 3. Erhalte E-Mail mit Liste der Flüge 4. Erhalte die Liste der Flüge auf meinem Smartphone 5. Erhalte SMS mit Liste der Flüge 6. ...

Slide 116

Slide 116 text

von User-Story zu Szenario (7) Szenario: Fred möchte E-Mail mit Liste passender Flüge Given Fred ist auf der Buchungs-Website When Fred wählt die E-Mail Option aus Then Fred erhält eine E-Mail mit der Liste der passenden Flüge 3. ... 2. WAS 1. WARUM „Als Besucher kann ich alle verfügbaren Flüge für mein Reisedatum und mein Reiseziel sehen, um die beste Option auszuwählen.“ Für einen Besucher könnte „Flüge sehen“ bedeuten: 1. Bekomme Liste von Flügen auf Website angezeigt, sortiert nach Abflugzeit 2. Bekomme Liste von Flügen auf Website angezeigt, sortiert nach Preis aufsteigend 3. Erhalte E-Mail mit Liste der Flüge 4. Erhalte die Liste der Flüge auf meinem Smartphone 5. Erhalte SMS mit Liste der Flüge 6. ...

Slide 117

Slide 117 text

von User-Story zu Szenario (8) 3. Kriterien 2. WAS 1. WARUM „Als Besucher kann ich alle verfügbaren Flüge für mein Reisedatum und mein Reiseziel sehen, um die beste Option auszuwählen.“

Slide 118

Slide 118 text

von User-Story zu Szenario (9) 3. Kriterien 2. WAS 1. WARUM „Als Besucher kann ich alle verfügbaren Flüge für mein Reisedatum und mein Reiseziel sehen, um die beste Option auszuwählen.“ „alle verfügbaren“ könnte bedeuten: Es gibt... 1. keine solchen Flüge 2. 2 oder mehr Flüge vom gleichen Flughafen 3. Flüge von mehreren Flughäfen 4. Flüge zu mehreren Flughäfen 5. Flüge mit verfügbaren Plätzen 6. Flüge mit Warteliste („standby seating“) 7. ... „mein Reisedatum“ könnte bedeuten: Es gibt... 1. keine Flüge an diesem Tag / zu dieser Zeit 2. 2 oder mehr Flüge an diesem Datum 3. günstigere Flüge am Vortag oder Folgetag 4. ...

Slide 119

Slide 119 text

Tipps zu Szenarien Leiten Sie Szenarien aus Bestandteilen Ihrer User-Stories ab: • „Warum“ und „Was“ • „Kriterien“ oder Einschränkungen • Geschäftsregeln

Slide 120

Slide 120 text

Quellen (1) • J.S. Smart: BDD in Action. Manning. • S. Rose, M. Wynn, A. Hellesøy: The Cucumber for Java Book. Pragmatic Programmers. • T+A Hathaway: Getting and Writing IT Requirements in Lean and Agile World. Leanpub. Enthält ein (kurzes aber verständliches) Kapitel zu BDD.

Slide 121

Slide 121 text

Quellen (2) • Serenity (Tool): https://serenity- bdd.github.io/theserenitybook/latest/index.html • Sundberg, Thomas: Where should you use BDD: Online: https://cucumber.io/blog/bdd/where_should_you_use_bdd/ • Chandrasekaran, Arun: Examples to show different ways of creating cucumber feature files. Online: https://medium.com/@bcarunmail/examples-to-show-different-ways-of- creating-cucumber-feature-files-dbe8c04366bc

Slide 122

Slide 122 text

Ihr 5-Punkte Plan 1. Business-Ziele + Stakeholderliste 2. externe Schnittstellen 3. High-Level Prozesse + JIT-Details 4. Qualitätsanforderungen 5. (ausführbare) Beispiele

Slide 123

Slide 123 text

Quellen (3) • Michael Keeling: Design It! Pragmatic Programmers. • T+A Hathaway: Getting and Writing IT Requirements in Lean and Agile World. Leanpub. • Peter Hruschka: Business Analysis und Requirements Engineering. Hanser, 2. Auflage • Smart: BDD in Action. Manning.

Slide 124

Slide 124 text

Danke. Gernot Starke gernot.starke@innoq.com Twitter: @gernotstarke Peter Hruschka peter@systemsguild,.com hruschka@b-agile.de