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

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

garbage in, garbage out

Input Output

Input Output ? Photo by John Cameron on Unsplash

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

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

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

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

Anforderungen klären gehört zur Architekturarbeit Architektur analysieren + bewerten Anforderungen und Randbedingungen klären Querschnittliche Konzepte entwerfen Umsetzung begleiten Architektur kommunizieren Strukturen entwerfen

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?

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

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

Photo by Yiran Ding on Unsplash kennen wir deren Anforderungen?

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

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

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

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

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

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

Funktionale Anforderungen Überblick schaffen, Gesamtprozess verstehen iterativ / inkrementell

Funktionale Anforderungen Idee: Top-Down...

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

Hierarchie von Anforderungen... ausführbar

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

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

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

Was bei DDD fehlt...!

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

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

No content

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

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

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

BDD: Behaviour-Driven Development

Ausführbare Specs Aktueller Status im Überblick

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

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?

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?

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

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

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

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

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

Tipps 1. Mit Fachbereich/Business auf discover- deliver Schleife einigen 2. PO in „Requirements Engineering“ ausbilden

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

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

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

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.