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

Im Stich gelassen: SWKammer-Köln

Im Stich gelassen: SWKammer-Köln

Warum wir und als Software-Team um bessere Anforderungen kümmern sollten - und wie!

Vortrag mit Daniel Lauxtermann.

Dr. Gernot Starke

June 14, 2021
Tweet

More Decks by Dr. Gernot Starke

Other Decks in Programming

Transcript

  1. Im Stich gelassen?
    Dr. Gernot Starke
    Fellow
    Daniel Lauxtermann
    Senior Consultant

    View full-size slide

  2. Dr. Gernot Starke
    Fellow
    • Gründer arc42, aim42
    • Mitgründer iSAQB e.V.
    Daniel Lauxtermann
    Senior Consultant
    • Requirements Engineer
    • Product Owner, Business Analyst

    View full-size slide

  3. garbage in,
    garbage out

    View full-size slide

  4. Input Output

    View full-size slide

  5. Input Output
    ?
    Photo by John Cameron on Unsplash

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

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

    View full-size slide

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

  11. Anforderungen + Randbedingungen
    • 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
    er hat
    Anforderungen?

    View full-size slide

  12. Beispiel: Meinungen…
    • Konkurrierende
    Fachabteilungen
    • Unklare Vorgaben
    Product
    • Id
    • Name
    • revenueAcc
    Characteristic
    • name
    • valueType
    • value
    Name Anz. Preis
    Ich will flexibel
    individuelle
    Dinge verkaufen
    und manuelle
    Aufwände
    reduzieren Performance
    Management
    machen wir auf Basis
    von Produkten.
    Erlöse müssen
    korrekt kontiert
    werden.
    Anforderung

    View full-size slide

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

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  17. Wenn ich die Leute
    gefragt hätte, was sie
    wollen, hätten sie
    gesagt: »schnellere
    Pferde«
    (Angebliches Zitat von Henry Ford)
    © Volkan Furuncu / Picture Alliance

    View full-size slide

  18. Kontextabgrenzung / Scope
    Was liegt „im“ System, was „außen“?
    Zeigt externe Schnittstellen
    Macht klar, was im Fokus steht
    Systemgrenze
    trennt innen und außen

    View full-size slide

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

    View full-size slide

  20. Funktionale Anforderungen
    Überblick schaffen, Gesamtprozess verstehen
    Geschäftsprozess
    ,
    Systemprozess,
    Use Case,
    oder User Story
    (unser)
    System
    other...
    other...
    API

    View full-size slide

  21. Funktionale Anforderungen
    Überblick schaffen, Gesamtprozess verstehen
    iterativ / inkrementell

    View full-size slide

  22. Funktionale Anforderungen
    Idee: Top-Down...

    View full-size slide

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

    View full-size slide

  24. Hierarchie von Anforderungen...
    ausführbar

    View full-size slide

  25. Geht auch mit JIRA/Confluence
    Tabelle
    (Business)
    Use Case Diagramm
    Ticketart /
    Komponente /
    Stichwort /
    Link
    Epic
    User Story
    JIRA
    Lorem
    Ipsum
    DoD

    View full-size slide

  26. Link zur Architekturdoku
    A
    B
    C
    Links
    Plugin
    System
    A1
    A2
    C1
    (System)
    Use Case Diagramm
    (Business)
    Use Case Diagramm
    Links
    Excerpt
    Das gleiche Muster lässt sich für andere Kapitel wiederholen

    View full-size slide

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

  28. Was bei DDD
    fehlt...!

    View full-size slide

  29. Domain-Driven
    Analysis
    and Design
    treffender wäre DDAD:

    View full-size slide

  30. Domain-Driven (Analysis and) Design
    Zentrale DDD-
    Praktiken
    gehören zur
    Anforderungsklärung...
    Legend
    Ubiquitous
    Language
    Core Domain
    Generic
    Subdomains
    Bounded
    Context
    Context
    Map
    avoid
    overinvesting
    problem
    space
    solution
    space
    names enter
    cultivate rich
    model with
    Model-Driven
    Design
    cultivate rich
    model with
    assess / overview
    relationsships
    with
    Domain
    Events
    express model
    with
    work in
    autonomous,
    clean

    View full-size slide

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

    View full-size slide

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

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

  34. BDD: Behaviour-Driven Development

    View full-size slide

  35. Ausführbare Specs
    Aktueller Status
    im Überblick

    View full-size slide

  36. Tipps
    • Eines der BDD-Tools ausprobieren
    • Given-When-Then Beschreibung von
    Anforderungen im Team versuchen
    • Fachbereich involvieren
    („3-Amigo-Session“, Biz+Test+Dev)

    View full-size slide

  37. Die Sache mit der Qualität (DIN 9000:2015-11)
    „Grad, in dem ein Satz
    inhärenter Merkmale
    eines Objekts
    Anforderungen
    erfüllt“.
    Häh?

    View full-size slide

  38. Die Sache mit der Qualität...
    Konkrete Informationen wie z.B.:
    • Wie lange Zeit bis XY-Operation fertig?
    • Wieviele Daten/User?
    • Wie lange für welche Art Änderung?

    View full-size slide

  39. Qualität - konkreter
    Prio Q-Merkmal Konkretisierung
    1 Flexibilität Neues csv- oder Fix-Field Importformat in <4h konfigurierbar
    2
    Last /
    Performance
    100.000 per Batch/ftp gelieferte Fotos inkl. Metadaten
    innerhalb von 4h prozessiert
    3 Datensicherheit
    • Mandant kann niemals Zugriff auf Daten anderer
    Mandanten erhalten
    • Datenlieferung grundsätzlich einem Mandaten zugeordnet
    4 Änderbarkeit
    Grafisches Subsystem innerhalb von 20PT an neuen Grafik-
    Chip anpassbar
    Voraussetzung: neuer Chip verfügt über notwendigen Low-Level Funktionen

    View full-size slide

  40. Qualitätsanforderungen ermitteln
    Reliability
    Testability
    Security
    Performance
    Availability
    Modifiability
    Operability
    Usability
    <…>
    <…> <…>
    Quality Attribute
    Web
    [Keeling-17]
    ….
    ….
    ….
    ….
    ….
    ….
    ….
    ….

    View full-size slide

  41. Tipps
    1. Qualitätsanforderungen explizit machen
    2. Falls keine vorhanden: educated guess

    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
    1. Mit Fachbereich/Business auf discover-
    deliver Schleife einigen
    2. PO in „Requirements Engineering“ ausbilden

    View full-size slide

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

    View full-size slide

  46. Quellen
    Peter Hruschka, Gernot Starke
    Im Stich gelassen?
    Requirements Skills erfolgreicher
    Softwareteams
    https://leanpub.com/requirements-skills/c/swkkoeln-meetup-06-21

    View full-size slide

  47. Gutschein…
    https://leanpub.com/requirements-skills/c/swkkoeln-meetup-06-21

    View full-size slide

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

    View full-size slide