Requirements Engineering

▪ Ziel des RE ▪ Anforderungen an Systeme so zu spezifizieren & zu verwalten, dass die implementierten & bereitgestellten Systeme die Bedürfnisse der Stakeholder erfüllen Requirements Engineering: Was? Angemessenes RE bietet Mehrwert für gesamte Entwicklung ▪ Verringerung des Risikos, ein falsches System zu entwickeln ▪ Besseres Verständnis des Problems ▪ Grundlage für die Schätzung von Entwicklungsaufwand & Kosten ▪ Voraussetzung für das Testen des Systems ▪ Typische Symptome für mangelhaftes RE: fehlende, unklare oder falsche Anforderungen ▪ Gründe für mangelhaftes RE ▪ Direkter Beginn mit der Entwicklung ▪ Kommunikationsprobleme zwischen beteiligten Parteien ▪ Annahme, dass Anforderungen selbstverständlich sind ▪ Unzureichende Ausbildung & Fähigkeiten im RE Requirements Engineering: Warum? RE bzgl. Anforderungen für jeder Art von System ▪ Fokus: Systeme, in denen Software wesentliche Rolle spielt ▪ Unterscheidung nach Herkunft ▪ Systemanforderungen: was ein System tun soll ▪ Stakeholderanforderungen: was Stakeholder wollen ▪ Benutzeranforderungen: was Benutzer wollen ▪ Domänenanforderungen: erforderliche Domäneneigenschaften ▪ Geschäftsanforderungen: Geschäftsziele einer Organisation ▪ Hauptaufgaben im RE: Ermittlung, Dokumentation, Validierung und Verwaltung von Anforderungen ▪ Werkzeugunterstützung kann dabei helfen ▪ Anforderungsanalyse & Lösung von Anforderungskonflikten ▪ Notwendig: maßgeschneiderter RE-Prozess Requirements Engineering: Wo & Wie? ▪ Requirements Engineer: typischerweise keine eigene Berufsbezeichnung, sondern Rolle von Personen, die ▪ als Teil ihrer Aufgaben Anforderungen ermitteln, dokumentieren, validieren und/oder verwalten ▪ über fundierte Kenntnisse im RE verfügen ▪ die Lücke zwischen Problem & möglicher Lösungen überbrücken ▪ In der Praxis: Business-Analysten, Anwendungsspezialisten, Product Owner, Systemingenieure, Entwickler ▪ Notwendige Fähigkeiten ▪ Anforderungen in verschiedenen Formen dokumentieren können ▪ Anforderungen mit verschiedenen Praktiken erarbeiten können ▪ Geeignete RE-Prozesse definieren und mit ihnen arbeiten können ▪ Bestehende Anforderungen verwalten können ▪ Werkzeugunterstützung einsetzen können

Stakeholder ▪ Personen oder Organisationen, die die Anforderungen beeinflussen oder die von diesem System betroffen sind

e Bedürfnisse heißen Anforderungen ▪ Funktionale Anforderungen ▪ Qualitätsanforderungen (siehe Kapitel 1) ▪ Constraints (Randbedingungen

1) Wertorientierung ▪ Anforderungen sind Mittel zum Zweck, kein Selbstzweck ▪ Wert einer Anforderung: Nutzen abzüglich Kosten für Ermitteln, Dokumentieren, Validieren & Verwalten ▪ Nutzen einer Anforderung: Grad, den sie dazu beiträgt ▪ ein System zu bauen, das die Bedürfnisse der Stakeholder erfüllt ▪ das Risiko von Fehlschlägen & kostspieligen Nacharbeiten bei der Entwicklung des Systems zu verringern ▪ (2) Stakeholder ▪ Ziel: Wünsche & Bedürfnisse der Stakeholder erfüllen ▪ Jeder Stakeholder hat Rolle im Systemkontext, z.B. Benutzer, Kunde, Auftraggeber, Betreiber, Behörde etc. (ggf. mehrere Rollen) ▪ Stakeholder können unterschiedliche Bedürfnisse haben: widersprüchliche Anforderungen möglich; RE muss Konflikte finden & auflösen ▪ Einbeziehung der richtigen Personen (→ Stakeholder-Analyse) Prof. Dr. Philipp Rohde 22WiSe-SWT-AC | 169 Prinzipien II ▪ (3) Gemeinsames Verständnis ▪ Von Stakeholder, RE und Entwickler; nötig für erfolgreiche Entwicklung ▪ Explizit: dokumentierte & vereinbarte Anforderungen ▪ Implizit: gemeinsames Wissen über Bedürfnisse, Visionen, Kontext usw. ▪ Positiv: Domänenwissen; frühere Zusammenarbeit; gemeinsame Kultur & Werte; gegenseitiges Vertrauen ▪ Negativ: geografische Distanz; Outsourcing; große Teams; Fluktuation ▪ Instrumente: z.B. Glossar, Prototypen, kurze Feedback-Schleifen ▪ (4) Kontext ▪ Systeme immer in Kontext (Systemumgebung); Verständnis wesentlich ▪ RE: genaue Klärung der Systemgrenze, Definition der Schnittstellen, Umfang des Systems und Kontextgrenze (»Rest der Welt«) ▪ Auch implizite Annahmen über den Kontext, die für das Funktionieren des Systems & die Erfüllung der Anforderungen gelten müssen Prof. Dr. Philipp Rohde 22WiSe-SWT-AC | 170 Prinzipien III ▪ (5) Problem → Anforderung → Lösung ▪ »Problem«: Stakeholder ist mit etwas unzufrieden (Ist-Situation) ▪ »Anforderungen«: was brauchen Stakeholder, um das Problem zu lösen ▪ »Lösung«: sozio-technisches System, das Anforderungen gerecht wird ▪ Alle drei eng verbunden; können nicht isoliert angegangen werden ▪ (6) Validierung ▪ Überprüfung, ob System tatsächlich Bedürfnisse der Stakeholder erfüllt ▪ Nicht-validierte Anforderungen sind nutzlos ▪ Validierung muss früh beginnen, um Risiko der Unzufriedenheit zu minimieren: Einigkeit über Anforderungen? Bedürfnisse der Stakeholder ausreichend abgedeckt? Kontextannahmen vernünftig? ▪ (7) Evolution ▪ Systeme & Anforderungen unterliegen ständigen Veränderungen, z.B. Wettbewerber, neue Produkte & Technologien, Gesetzesänderungen, veränderte Benutzerbedürfnisse etc. ▪ Auch: Änderung durch Validierung, Entdeckung von Fehlern etc. ▪ Konträr: Anforderungen stabil halten & Änderungen ermöglichen Prof. Dr. Philipp Rohde 22WiSe-SWT-AC | 171 Prinzipien IV ▪ (8) Innovation ▪ Gutes RE: Stakeholder nicht nur zufrieden stellen, sondern glücklich machen & begeistern ▪ RE gestaltet innovative Systeme: Streben nach neuen Funktionen & Benutzerfreundlichkeit; nach verändernden (disruptiven) Ideen ▪ (9) Systematische & disziplinierte Arbeit ▪ Prozesse & Praktiken zur systematischen Ermittlung, Dokumentation, Validierung & Verwaltung von Anforderungen ▪ Unabhängig vom Vorgehensmodell ▪ Den »RE-Standardprozess« gibt es nicht: Anpassung an Problem & Kontext immer sinnvoll; Erfolg muss laufend geprüft werden Prof. Dr. Philipp Rohde 22Wi

Arbeitsprodukt: dokumentiertes, im Arbeitsprozess erzeugtes Zwischen- bzw. Endergebnis ▪ Von Skizze bis zu formaler, vertraglicher Spezifikation ▪ Merkmale: Zweck, Darstellung, Umfang & Lebensdauer ▪ Für spezielle Zwecke bis universell einsetzbar ▪ Drei Abstraktionsebenen: Business, System & Komponenten ▪ Darstellung: auf natürlicher Sprache basierend; vorlagenbasiert; modellbasiert; weitere Formen, z.B. Zeichnung oder Prototyp ▪ Lebensdauer: kurzlebig, weiterentwickelnd, langlebig ▪ Typische Arbeitsprodukte ▪ Einzelne Anforderung, z.B. User Story ▪ Menge von Anforderungen, z.B. Use Case, grafische Modelle (z.B. UML), Beschreibungen externer Schnittstellen, Epics ▪ Dokumente zu System-, Geschäfts-, Stakeholder-, Benutzer

Lastenheft – Vom Auftraggeber festgelegte Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Auftragnehmers innerhalb eines Auftrages. DIN 69901-5:2009 Customer Requirements Specification – A coarse description of the required capabilities of a system from the customer’s perspective. Usually supplied by the customer.

Pflichtenheft – Vom Auftragnehmer erarbeiteten Realisierungsvorgaben aufgrund der Umsetzung des vom Auftraggeber vorgegebenen Lastenhefts. DIN 69901-5:2009 Software Requirements Specification (SRS) – A requirements specification pertaining to a software system

Basisfaktoren (Dissatisfier) •Selbstverständlich •Negativ bei Fehlen •Nicht ausgesprochen (implizit) •Unterbewusstes Wissen

Leistungsfaktoren (Satisfier) •Spezifiziert •Kalkuliert: positiv / negativ •Ausgesprochen (explizit) •Bewusstes Wissen

Begeisterungsfaktoren (Delighter) •Nicht erwartet •Positiv bei Entdeckung •Unbewusstes Wissen

A high-level or complex user story to be refined into more detailed user stories

Einfache Erzählung zur Veranschaulichung der Benutzerziele

die eine Softwarefunktion erfüllen soll.

(2) Eine erzählerische Beschreibung einer Softwareanforderung, Funktion,

Funktion oder eines Qualitätsmerkmals, dargestellt als Erzählung der gewünschten

Benutzerinteraktionen mit einem Softwaresystem

Wichtigstes Arbeitsprodukt: eine Funktionalität, die für einen Benutzer von Wert ist / Problem löst / Prozess unterstützt ▪ Neben Beschreibung weitere Pflichtangaben ▪ Spezifische Akzeptanzkriterien ▪ Komplexität bzw. Aufwand (typisch: Story Points) ▪ Business Value (monetäre oder abstrakte Einheit) ▪ Detaillierungsgrad reicht für Planung & Aufwandschätzung des nächsten Sprints (gemäß Priorität im Product Backlog) ▪ Sie können jeweils in einem Sprint umgesetzt werden