Lock in $30 Savings on PRO—Offer Ends Soon! ⏳

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. Dr. Gernot Starke Fellow • Gründer arc42, aim42 • Mitgründer

    iSAQB e.V. Daniel Lauxtermann Senior Consultant • Requirements Engineer • Product Owner, Business Analyst
  2. 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
  3. Anforderungen klären gehört zur Architekturarbeit Architektur analysieren + bewerten Anforderungen

    und Randbedingungen klären Querschnittliche Konzepte entwerfen Umsetzung begleiten Architektur kommunizieren Strukturen entwerfen
  4. 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?
  5. 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
  6. 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...
  7. Tipp (mehrere!) Stakeholder involvieren: • Fachbereiche • User • Betrieb

    / Hardware • (Top-)Management • Verantwortliche von Nachbarsystemen
  8. 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
  9. Kontextabgrenzung / Scope Was liegt „im“ System, was „außen“? Zeigt

    externe Schnittstellen Macht klar, was im Fokus steht Systemgrenze trennt innen und außen
  10. Tipps Externe Schnittstellen kennen: • fachliche Bedeutung • „Gegenstelle“ •

    Volatilität • Q-Anforderungen: Volumen, Durchsatz, Reaktionszeit, Verfügbarkeit
  11. Geht auch mit JIRA/Confluence Tabelle (Business) Use Case Diagramm Ticketart

    / Komponente / Stichwort / Link Epic User Story JIRA Lorem Ipsum DoD
  12. 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
  13. Tipps • Business-Ziele explizit aufschreiben (lassen) • High-Level („Ende-zu-Ende“) Prozesse

    kennen • Mehrwert für Nutzer*innen kennen • Iterativ verfeinern
  14. 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
  15. 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 …..
  16. 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
  17. 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
  18. Tipps • Eines der BDD-Tools ausprobieren • Given-When-Then Beschreibung von

    Anforderungen im Team versuchen • Fachbereich involvieren („3-Amigo-Session“, Biz+Test+Dev)
  19. 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?
  20. 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?
  21. 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
  22. Qualitätsanforderungen ermitteln Reliability Testability Security Performance Availability Modifiability Operability Usability

    <…> <…> <…> Quality Attribute Web [Keeling-17] …. …. …. …. …. …. …. ….
  23. Zusammenarbeit - konkreter DISCOVER DELIVER Story Map Top Level Epics

    Selected Stories Release https://www.discovertodeliver.com/index.php
  24. 5-Punkte Plan 1. Business-Ziele 2. externe Schnittstellen 3. High-Level Prozesse

    4. (ausführbare) Beispiele 5. Qualitätsanforderungen
  25. Quellen Peter Hruschka, Gernot Starke Im Stich gelassen? Requirements Skills

    erfolgreicher Softwareteams https://leanpub.com/requirements-skills/c/swkkoeln-meetup-06-21
  26. 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.