Im Stich gelassen - Requirements for Software Architects

Haben Ihre Requirements-Engineers, Product-Owner oder Produktmanager Sie im Stich gelassen, was klare Anforderungen angeht? Leiden Sie unter vagen, unklaren oder fehlenden Anforderungen, ohne konsistente Prioritäten? Willkommen im Club der “Im Stich Gelassenen”.

Für Software- und Systemarchitektur stellen „gute" Anforderungen und Randbedingungen die Basis vieler Entscheidungen dar. Alle Beteiligten geben vor, das Prinzip “garbage-in, garbage-out” zu kennen, aber von der Anforderungsseite scheinen sich in der Praxis doch eher wenige dran zu halten.

Da braucht es konstruktive Abhilfe: Selbst sind die pragmatischen ArchitektInnen.

Nein, wir wollen auf keinen Fall die Rolle von PO, Business-Analysten und Requirements-Engineers übernehmen – sondern lediglich die architekturrelevanten Anforderungen so weit klären, dass wir auf dieser Basis robuste Architekturentscheidungen treffen können.

In der Session behandeln wir die Grundsätze von “Anforderungsklärung” für Softwarearchitektur. Wir starten bei grundlegendem Scoping und der Kontextabgrenzung, kümmern uns um Ermittlung (architekturrelevanter) funktionaler Anforderungen und tauchen dann in die kritischen Qualitätsziele und -anforderungen ab. Darüber hinaus beleuchten wir den Nutzen von „Behavior Driven Development“ für die Anforderungsklärung.

Sie bekommen methodische Tipps, gepaart mit Beispiel aus dem echten Leben.

Transcript

1. Im Stich gelassen? Dr. Gernot Starke Dr. Peter Hruschka
2. 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.“
3. <schamlos> Peter Hruschka, Gernot Starke Requirements Skills erfolgreicher Softwareteams Hanser-Verlag, (voraussichtlich 2. Quartal 2020) </schamlos> X Requirements-Skills erfolgreicher Softwareteams peter HRUSCHKA gernot STARKE LIKE NEED WANT ALT A S Z
4. Dr. Gernot Starke INNOQ Fellow • Architecture-Improver • Coach, Trainer • Founder arc42, aim42 • iSAQB e.V.
5. Dr. Peter Hruschka Atlantic Systems Guild • Agile Requirements Engineer & Architect • Coach, Trainer, Autor • Founder arc42, req42 • Founding Member IREB e.V, iSAQB e.V.
6. garbage in, garbage out
7. f(x) Exkurs: Mathematik (genauer: Analysis)
8. y = f(t) transformieren Eingabedaten Funktionen ...
9. Input Requirements Output Software
10. sw = t(req) sw : Software req : Anforderungen t : Team Funktionen ...
11. Input Output
12. Input Output ? Photo by John Cameron on Unsplash
13. Requirements-Chaos Statt „echter“ Product-Owner: • Konkurrierende Fachabteilungen • Ständig wechselnde Prioritäten • Unklare Vorgaben • Diffuse Begriffe
14. Wer bekommt Prügel? Entwicklungsteam L Photo by Aimee Vogelsang on Unsplash
15. 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
16. Nicht-Ziele Requirements-Engineering oder Business-Analyse: • ersetzen • abschaffen • vom Entwicklungsteam übernehmen lassen
17. dann geht‘s! Foto: Peter Hruschka
18. Anforderungen klären gehört zur Architekturarbeit Architektur analysieren + bewerten Anforderungen und Randbedingungen klären Querschnittliche Konzepte entwerfen Umsetzung begleiten Architektur kommunizieren Strukturen entwerfen
19. 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).
20. Architektur- relevante Anforderungen
21. 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?
22. Scope (Abgrenzung des Umfangs) Stakeholder Vision /Ziele Der erfolgreiche (Projekt-) Start Auch agile Projekte brauchen etwas „upfront“
23. 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?
24. 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:
25. 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
26. 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...
27. Photo by Yiran Ding on Unsplash kennen wir deren Anforderungen?
28. Stakeholder vergessene Stakeholder bedeuten vergessene Anforderungen Photo by Yiran Ding on Unsplash
29. Tipp (mehrere!) Stakeholder involvieren: • Fachbereiche • User • Betrieb / Hardware • (Top-)Management • Verantwortliche von Nachbarsystemen
31. 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
32. CHEESEBURGER HERSTELLEN Sesame Bun Beef Patty Cheese Veggies SCHÄTZEN SIE DEN PROJEKTAUFWAND
33. CHEESEBURGER HERSTELLEN Eier, Milch, Fleisch Bauernhof Tomaten, Salat Bio-Bauer Mehl Bäcker Gewürze Gewürz- regal WOLLEN SIE IHRE SCHÄTZUNG KORRIGIEREN?
34. 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
35. 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
36. Tipps Externe Schnittstellen kennen: • fachliche Bedeutung • „Gegenstelle“ • Volatilität • Q-Anforderungen: Volumen, Durchsatz, Reaktionszeit, Verfügbarkeit
37. 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?
38. Granularität von funktionalen Anforderungen Für Entwicklungsteams wichtig: Überblick! (Details brauchen wir erst „Just in Time“)
39. YOUR BUSINESS YOUR Product Teile und beherrsche - aber wie?
40. 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)
41. ERRATEN? DENKEN in durchgängigen Prozessen von AUSSEN AUSGELÖST (Externer Trigger oder Zeittrigger) Quer durch das System erzeugt Mehrwert für EINEN STAKEHOLDER
42. Prozesse - die natürlichste Zerlegung eines großen Systems
43. Zusammenarbeit im Team DISCOVER DELIVER https://www.discovertodeliver.com/index.php Nach: Ellen Gottesdiener
44. Zusammenarbeit - konkreter DISCOVER DELIVER Story Map Top Level Epics Selected Stories Release https://www.discovertodeliver.com/index.php
45. Tipps • Business-Ziele explizit aufschreiben (lassen) • High-Level („Ende-zu-Ende“) Prozesse kennen • Mehrwert für Nutzer*innen kennen • Iterativ verfeinern
46. Qualitäts- anforderungen
47. Qualität: Erfüllung von Eigenschaften.
48. Qualität: Erfüllung von Eigenschaften.
49. Erfüllung von Eigenschaften. n meistens groß.
50. Erfüllung von Eigenschaften. Beispiel: Hotel. Anzahl-Zimmer, Konferenzräume, Essen, Preis- pro-Übernachtung, Tagungspreis, Fitness-Raum, WLAN, Verfügbarkeit.
51. Erfüllung von Eigenschaften. n meistens groß. Und abhängig von Stakeholdern.
52. 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?
53. Erfüllung von Eigenschaften. n meistens groß. Und abhängig von Stakeholdern. Für Software?
54. 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 <u.a.>
55. Orientierungshilfe für {heiten|keiten}
56. Nachteil des ISO-Modells... unspezifisch: Begriffen lassen Raum für Interpretation. Beispiel: „Availability“.
57. Anti-Beispiel „Availability“ neulich, im Urlaub:
58. Anti-Beispiel „Availability“ neulich, im Urlaub:
59. Anti-Beispiel „Availability“ neulich, im Urlaub:
60. 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.
61. Beispiel „Laufzeit" Die Ladezeit der Titelseite darf für Benutzer, die auf die Website per Smartphone über LTE zugreifen, höchstens 2 Sekunden betragen.
62. 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.
63. 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.
64. Qualitäts-Szenarien beschreiben (konkret, messbar), wie System auf bestimmte Ereignisse reagieren soll. System Nutzung Ereignis, Stimulus Reaktion Metrik Änderung
65. aber...
66. Manche Qualitätsanforderungen widersprechen oder beeinflussen sich gegenseitig.
67. Beispiel: Höchste Sicherheit und großartige Useability.
68. Daher: Entwicklungsteams (Sie!) müssen Qualitätsanforderungen detailliert auf Nebenwirkungen analysieren.
69. 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 Modifiability Operability Usability <…> <…> <…> Quality Attribute Web [Keeling-17] …. …. …. …. …. …. …. ….
70. Tipps zu Qualitätsanforderungen So spezifisch wie möglich: 1. Konkret mess- oder testbar 2. An Funktionen oder Features orientieren
71. 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.
72. Quellen (2) • arc42 Beispiele für Qualitätsanforderungen: https://github.com/arc42/quality-requirements
73. Behaviour Driven Development
75. Behaviour Example Driven Development
76. Business Ziele Scope, Kontext Schlüssel- Beispiele Spezifikation mit Beispielen gemeinsam spezifizieren Beispiele statt Abstraktionen
77. Hierarchie von Anforderungen... ausführbar Vision ausführbare Spezifikationen (Code) konkret abstrakt …..
78. Hierarchie von Anforderungen... ausführbar
79. Domain-Storytelling... Funktionen / Prozesse aus Sicht der Akteure Schlüssel- Beispiele Spezifikation mit Beispielen Schüler (Franz) offline 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
80. ausführbare Specs als Verfeinerung verfeinert durch unterstützt durch Business- Ziel Features Szenario (Beispiele) ausführbare Szenarien Low-Level Spezifikationen verfeinert durch verfeinert durch Quellcode des Systems verwendet Vision ausführbare Spezifikationen (Code) konkret abstrakt …..
81. Given-When-Then... Business- Ziel Features Szenario (Beispiele) ausführbare Szenarien Low-Level Spezifikationen Given a web browser is on the Google page When the search phrase "panda" is entered Then results for "panda" are shown
82. Meta Beispiel Beispiel für ein Beispiel – aus „The Cucumber for Java Book“
83. 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
84. 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...
85. 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
86. Given When Then Given-When-Then... ähnlich wie TDD, nur höhere Ebene
87. 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 ....
88. 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
89. 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
90. 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
91. Zur Vereinfachung der Praxis (2)... Scenario Outline: eating Given there are <start> cucumbers When I eat <eat> cucumbers Then I should have <left> cucumbers Examples: | start | eat | left | | 12 | 5 | 7 | | 20 | 5 | 15 | https://cucumber.io/docs/gherkin/reference/
92. „Disclaimer“ zu Tools: Rein subjektiv. Kein gründlicher Marktüberblick. Stellen keine Empfehlung dar.
93. Tooling (1): die Basis
94. Tools für BDD verfeinert durch unterstützt durch Business- Ziel Features Szenario (Beispiele) ausführbare Szenarien Low-Level Spezifikationen verfeinert durch verfeinert durch In Gherkin Feature-Files Quellcode des Systems verwendet spockframework
95. 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(); } ....
96. 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(); } ....
97. 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 { .... }
98. 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()); } }
99. These: BDD-Szenarien ausführen funktioniert. Beweis (durch Beispiele) : cucumber, RSpec, SpecFlow, JBehave, Behat...
100. Ü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)
101. These: Ihr Business versteht diese Szenarien.
102. These (2): Sie merken, ob ihre Anforderungen konkret genug sind.
103. Tooling (2): Serenity BDD http://www.thucydides.info
104. Ausführbare Specs Aktueller Status im Überblick
105. Tooling (3): Cucumber-Studio https://studio.cucumber.io/projects
106. Tooling (3): Cucumber-Studio https://studio.cucumber.io/projects
107. 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/
108. Tipps zu BDD • Given-When-Then Beschreibung von Anforderungen im Team versuchen • Eines der BDD-Tools ausprobieren • Fachbereich involvieren („3-Amigo-Session“)
109. Von User-Stories zu BDD-Szenarien nach: T+A Hathaway (siehe Anhang)
110. 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?
111. 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.“
112. 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
113. 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
114. 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.“
115. 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. ...
116. 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. ...
117. 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.“
118. 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. ...
119. Tipps zu Szenarien Leiten Sie Szenarien aus Bestandteilen Ihrer User-Stories ab: • „Warum“ und „Was“ • „Kriterien“ oder Einschränkungen • Geschäftsregeln
120. 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.
121. 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
122. Ihr 5-Punkte Plan 1. Business-Ziele + Stakeholderliste 2. externe Schnittstellen 3. High-Level Prozesse + JIT-Details 4. Qualitätsanforderungen 5. (ausführbare) Beispiele
123. 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.
124. Danke. Gernot Starke gernot.starke@innoq.com Twitter: @gernotstarke Peter Hruschka peter@systemsguild,.com hruschka@b-agile.de