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. Im Stich
    gelassen?
    Dr. Gernot Starke Dr. Peter Hruschka

    View full-size slide

  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.“

    View full-size slide


  3. 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

    View full-size slide

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

    View full-size slide

  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.

    View full-size slide

  6. garbage in,
    garbage out

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  9. Input
    Requirements
    Output
    Software

    View full-size slide

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

    View full-size slide

  11. Input Output

    View full-size slide

  12. Input Output
    ?
    Photo by John Cameron on Unsplash

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  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

    View full-size slide

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

    View full-size slide

  17. dann geht‘s!
    Foto: Peter Hruschka

    View full-size slide

  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

    View full-size slide

  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).

    View full-size slide

  20. Architektur-
    relevante
    Anforderungen

    View full-size slide

  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?

    View full-size slide

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

    View full-size slide

  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?

    View full-size slide

  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:

    View full-size slide

  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

    View full-size slide

  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...

    View full-size slide

  27. Photo by Yiran Ding on Unsplash
    kennen wir deren
    Anforderungen?

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  30. 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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  33. 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

    View full-size slide

  34. 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

    View full-size slide

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

    View full-size slide

  36. 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?

    View full-size slide

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

    View full-size slide

  38. YOUR BUSINESS
    YOUR
    Product
    Teile und beherrsche - aber wie?

    View full-size slide

  39. 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)

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  45. Qualitäts-
    anforderungen

    View full-size slide

  46. Qualität:
    Erfüllung von Eigenschaften.

    View full-size slide

  47. Qualität:
    Erfüllung von Eigenschaften.

    View full-size slide

  48. Erfüllung von Eigenschaften.
    n meistens groß.

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  51. 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?

    View full-size slide

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

    View full-size slide

  53. 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

    View full-size slide

  54. Orientierungshilfe für {heiten|keiten}

    View full-size slide

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

    View full-size slide

  56. Anti-Beispiel
    „Availability“
    neulich, im Urlaub:

    View full-size slide

  57. Anti-Beispiel
    „Availability“
    neulich, im Urlaub:

    View full-size slide

  58. Anti-Beispiel
    „Availability“
    neulich, im Urlaub:

    View full-size slide

  59. 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.

    View full-size slide

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

    View full-size slide

  61. 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.

    View full-size slide

  62. 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.

    View full-size slide

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

    View full-size slide

  64. Manche Qualitätsanforderungen
    widersprechen
    oder beeinflussen
    sich gegenseitig.

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  67. 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]
    ….
    ….
    ….
    ….
    ….
    ….
    ….
    ….

    View full-size slide

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

    View full-size slide

  69. 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.

    View full-size slide

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

    View full-size slide

  71. Behaviour
    Driven
    Development

    View full-size slide

  72. Behaviour
    Example
    Driven
    Development

    View full-size slide

  73. Business
    Ziele Scope,
    Kontext
    Schlüssel-
    Beispiele
    Spezifikation
    mit
    Beispielen
    gemeinsam
    spezifizieren
    Beispiele statt Abstraktionen

    View full-size slide

  74. Hierarchie von Anforderungen...
    ausführbar
    Vision
    ausführbare Spezifikationen
    (Code)
    konkret
    abstrakt
    …..

    View full-size slide

  75. Hierarchie von Anforderungen...
    ausführbar

    View full-size slide

  76. 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

    View full-size slide

  77. 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
    …..

    View full-size slide

  78. 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

    View full-size slide

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

    View full-size slide

  80. 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

    View full-size slide

  81. 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...

    View full-size slide

  82. 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

    View full-size slide

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

    View full-size slide

  84. 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
    ....

    View full-size slide

  85. 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

    View full-size slide

  86. 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

    View full-size slide

  87. 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

    View full-size slide

  88. 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/

    View full-size slide

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

    View full-size slide

  90. Tooling (1): die Basis

    View full-size slide

  91. 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

    View full-size slide

  92. 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();
    }
    ....

    View full-size slide

  93. 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();
    }
    ....

    View full-size slide

  94. 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 {
    ....
    }

    View full-size slide

  95. 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());
    }
    }

    View full-size slide

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

    View full-size slide

  97. Ü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)

    View full-size slide

  98. These:
    Ihr Business
    versteht
    diese Szenarien.

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  101. Ausführbare Specs
    Aktueller Status
    im Überblick

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  104. 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/

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  107. 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?

    View full-size slide

  108. 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.“

    View full-size slide

  109. 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

    View full-size slide

  110. 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

    View full-size slide

  111. 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.“

    View full-size slide

  112. 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. ...

    View full-size slide

  113. 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. ...

    View full-size slide

  114. 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.“

    View full-size slide

  115. 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. ...

    View full-size slide

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

    View full-size slide

  117. 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.

    View full-size slide

  118. 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

    View full-size slide

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

    View full-size slide

  120. 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.

    View full-size slide

  121. Danke.
    Gernot Starke
    [email protected]
    Twitter: @gernotstarke
    Peter Hruschka
    peter@systemsguild,.com
    [email protected]

    View full-size slide