Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Im Stich gelassen - Requirements for Software Architects

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.

Dr. Gernot Starke

March 09, 2020
Tweet

More Decks by Dr. Gernot Starke

Other Decks in Programming

Transcript

  1. 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.“
  2. <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
  3. Dr. Peter Hruschka Atlantic Systems Guild • Agile Requirements Engineer

    & Architect • Coach, Trainer, Autor • Founder arc42, req42 • Founding Member IREB e.V, iSAQB e.V.
  4. 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
  5. Anforderungen klären gehört zur Architekturarbeit Architektur analysieren + bewerten Anforderungen

    und Randbedingungen klären Querschnittliche Konzepte entwerfen Umsetzung begleiten Architektur kommunizieren Strukturen entwerfen
  6. 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).
  7. 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?
  8. Scope (Abgrenzung des Umfangs) Stakeholder Vision /Ziele Der erfolgreiche (Projekt-)

    Start Auch agile Projekte brauchen etwas „upfront“
  9. 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?
  10. 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:
  11. 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
  12. 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...
  13. Tipp (mehrere!) Stakeholder involvieren: • Fachbereiche • User • Betrieb

    / Hardware • (Top-)Management • Verantwortliche von Nachbarsystemen
  14. 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
  15. CHEESEBURGER HERSTELLEN Eier, Milch, Fleisch Bauernhof Tomaten, Salat Bio-Bauer Mehl

    Bäcker Gewürze Gewürz- regal WOLLEN SIE IHRE SCHÄTZUNG KORRIGIEREN?
  16. 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
  17. 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
  18. Tipps Externe Schnittstellen kennen: • fachliche Bedeutung • „Gegenstelle“ •

    Volatilität • Q-Anforderungen: Volumen, Durchsatz, Reaktionszeit, Verfügbarkeit
  19. 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?
  20. 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)
  21. ERRATEN? DENKEN in durchgängigen Prozessen von AUSSEN AUSGELÖST (Externer Trigger

    oder Zeittrigger) Quer durch das System erzeugt Mehrwert für EINEN STAKEHOLDER
  22. Zusammenarbeit - konkreter DISCOVER DELIVER Story Map Top Level Epics

    Selected Stories Release https://www.discovertodeliver.com/index.php
  23. Tipps • Business-Ziele explizit aufschreiben (lassen) • High-Level („Ende-zu-Ende“) Prozesse

    kennen • Mehrwert für Nutzer*innen kennen • Iterativ verfeinern
  24. 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?
  25. 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.>
  26. 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.
  27. Beispiel „Laufzeit" Die Ladezeit der Titelseite darf für Benutzer, die

    auf die Website per Smartphone über LTE zugreifen, höchstens 2 Sekunden betragen.
  28. 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.
  29. 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.
  30. Qualitäts-Szenarien beschreiben (konkret, messbar), wie System auf bestimmte Ereignisse reagieren

    soll. System Nutzung Ereignis, Stimulus Reaktion Metrik Änderung
  31. 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] …. …. …. …. …. …. …. ….
  32. Tipps zu Qualitätsanforderungen So spezifisch wie möglich: 1. Konkret mess-

    oder testbar 2. An Funktionen oder Features orientieren
  33. 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.
  34. 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
  35. 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 …..
  36. 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
  37. 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
  38. 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...
  39. 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
  40. 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 ....
  41. 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
  42. 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
  43. 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
  44. 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/
  45. 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
  46. 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(); } ....
  47. 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(); } ....
  48. 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 { .... }
  49. 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()); } }
  50. Ü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)
  51. 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/
  52. Tipps zu BDD • Given-When-Then Beschreibung von Anforderungen im Team

    versuchen • Eines der BDD-Tools ausprobieren • Fachbereich involvieren („3-Amigo-Session“)
  53. 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?
  54. 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.“
  55. 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
  56. 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
  57. 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.“
  58. 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. ...
  59. 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. ...
  60. 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.“
  61. 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. ...
  62. Tipps zu Szenarien Leiten Sie Szenarien aus Bestandteilen Ihrer User-Stories

    ab: • „Warum“ und „Was“ • „Kriterien“ oder Einschränkungen • Geschäftsregeln
  63. 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.
  64. 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
  65. Ihr 5-Punkte Plan 1. Business-Ziele + Stakeholderliste 2. externe Schnittstellen

    3. High-Level Prozesse + JIT-Details 4. Qualitätsanforderungen 5. (ausführbare) Beispiele
  66. 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.