Requirements Engineering (MC.ba VZ WS24) 2024 PDF

6_Req: Requirements Engineering (MC.ba VZ WS24) Studiengang Mobile Computing FH Hagenberg, 2024 alle RechteGmbH, © ReqPOOL bei ReqPOOL Linz GmbH Wozu Requirements Engineering?  Re...

6_Req: Requirements Engineering (MC.ba VZ WS24) Studiengang Mobile Computing FH Hagenberg, 2024 alle RechteGmbH, © ReqPOOL bei ReqPOOL Linz GmbH Wozu Requirements Engineering?  Requirements Engineering – Warum? Der tatsächliche Bedarf des Kunden Lastenheft Pflichtenheft Umsetzung Test Rechnung Kunde beschreibt Lieferant beschreibt Entwickler Qualitätssicherung Der Kunde muss WAS WIE programmiert testet die finale die Projektkosten er benötigt er das System umsetzt die Software Software bezahlen © ReqPOOL GmbH Vorstellrunde Laura Bayer Nicole Dopler Sales, s2G.at Managerin, ReqPOOL [email protected] [email protected] +436642042123 +436649261351 © ReqPOOL GmbH 5 ReqPOOL – Managementberatung für Software Als führende, unabhängige Managementberatung für Software begleitet ReqPOOL Organisationen auf dem Weg zum selbstfahrenden Unternehmen. Dabei unterstützt ReqPOOL bei der Definition der individuellen Unternehmensinitiativen und in der Spezifikation, Beschaffung und Einführung von innovativen Software-Lösungen. Unsere Kunden profitieren von unseren einzigartigen Softwaremethodiken und von unseren Softwarelösungen als Gewerk mit Erfolgsgarantie. Durch unsere jahrelange Erfahrung und unseren Fokus auf Spezifikation, Aufwandsschätzung und transparenter Scope-Governance von Software erzielen unsere Kunden messbare Wettbewerbsvorteile. 20 Jahre Erfahrung Niederlassungen: >120 Berater Seit 2001 mehrere hunderte Die ReqPOOL Gruppe Linz (HQ), Wien, 200 Subject Matter Experts Softwareprojekte besteht aus mehreren Salzburg, Graz, über 200 Kunden in Deutschland und Österreich Beratungsunternehmen. Berlin, Köln & zum Erfolg geführt. Amsterdam © ReqPOOL GmbH 6 s2G.at GmbH Als dynamisches Software-Entwicklungsunternehmen aus Linz, ist s2G.at spezialisiert auf maßgeschneiderte Softwarelösungen. Dazu gehören die Ablösung von Legacy-Systemen und umfassende Softwarewartung zur Sicherung der Stabilität und Leistungsfähigkeit der Systeme. Mit über einem Jahrzehnt Erfahrung in verschiedenen Branchen bietet s2G.at nicht nur technische Expertise, sondern auch kontinuierliche Beratung und Betreuung durch einen festen Ansprechpartner. Der Fokus liegt auf Kundennähe, Flexibilität und der Entwicklung zukunftssicherer IT-Lösungen, die Unternehmen helfen, ihre IT-Infrastrukturen zu modernisieren und langfristige Wettbewerbsvorteile zu sichern. Volksgartenstraße 15, Team > 23 >10 Jahre Erfahrung Java, JavaScript 4020 Linz 3 Scrum Teams © ReqPOOL GmbH 7  „ Erfahrungen mit Anforderungsmanagement? „ Bisherige Berufserfahrungen? © ReqPOOL GmbH 8 Bedeutung von RE im Bezug auf Entwicklungstätigkeiten Code: 3889 9743 © ReqPOOL GmbH 9  AGENDA – Gesamter Kurs Kurs 1 Vorstellung & Erfahrungsaustausch 23.10.2024 Einleitung & Grundlagen Kurs 2 Grundlegende Prinzipien des Requirements Engineering 23.10.2024 Praktiken zur Erarbeitung von Anforderungen Kurs 3 06.11.2024 Prozess & Arbeitsstruktur Dokumentationspraktiken – Natürlichsprach. BEISPIEL Anforderungen Mobile Applikation Kurs Arbeitsergebnisse und Dokumentationspraktiken – 08.11.2024 zum Transport für Modellbasierte Anforderungen Schulkinder und Kurs 5 Praktiken für das Abstimmen von Anforderungen Menschen mit 13.11.2024 Beeinträchtigungen Praktiken für das Requirements Engineering Kurs 6 Werkzeugunterstützung 29.11.2024 Präsentationen Kurs 7 Prüfung - TBD xx.12.2024 © ReqPOOL GmbH Inhalt & Prüfungsrelevanz Projektarbeit im Team (60 Punkte) Schriftliche Klausur (30 Punkte) – min. 18 Punkte für positive Note Präsentation der Projektarbeit (20 Punkte) (Optional) Zertifizierung (Gut für den Lebenslauf ) © ReqPOOL GmbH 11 Basisliteratur Foliensatz Basiswissen Requirements Engineering (Version 3.0) ISBN: 3864908140 Offizielles Begleitmaterial von IREB Lehrplan Handbuch Prüfungsordnung / Übungsprüfung / Auswertung Glossar © ReqPOOL GmbH 12 LERNEINHEIT 1: Einleitung und Grundlagen © ReqPOOL GmbH 13 Requirements Engineering – Was? Ermittlung, Dokumentation, Validierung Bedürfnis eines Stakeholders und Verwaltung von Anforderungen der Anspruch an ein System (Software, Stakeholder Hardware, Dienstleistung) Die Rolle wird von unterschiedlichen Definierte Funktionalitäten des Produktes Personen eingenommen Vorgaben zur Qualität des Produktes Requirements Anforderung Engineer Stakeholder Wichtigste Quelle von Anforderungen Hat Einfluss auf die Anforderung oder wird vom System beeinflusst Z.B. Kunden, Mitarbeiter, Betreiber, Entwickler, Architekten, Auftraggeber und Tester © ReqPOOL GmbH 14  Requirements Engineering – Was? Anforderungskatalog Backlog Prozessmodell Rand- Funktionale bedingungen Anforderungen Datenmodell NFA-Katalog Zuschlagskriterien Systemkontext Big-Picture Qualitäts- anforderungen SLA Scope-Dokument Prozessbeschreibung Arten von Anforderungen © ReqPOOL GmbH Es werden unterschiedliche Qualitäten eines Systems der Anforderung „Qualitätsanforderung“ zugeordnet, die im erheblichen Maße den Projekterfolg bzw. die spätere Akzeptanz des Systems beeinflussen. Exkurs: Kategorisierung der Qualitätsanforderungen Qualitäts- anforderungen Performance Sicherheit Zuverlässigkeit Benutzbarkeit Änderbarkeit Übertragbarkeit Max. 10ms Serverreaktion 99,95% Verfügbarkeit SAP Integration Max. 1ms Fehlertoleranzzeit Anbindung an bestehende Datenbanken © ReqPOOL GmbH 16  Requirements Engineering – Warum? Der tatsächliche Bedarf des Kunden Lastenheft Pflichtenheft Umsetzung Test Rechnung Kunde beschreibt Lieferant beschreibt Entwickler Qualitätssicherung Der Kunde muss WAS WIE programmiert testet die finale die Projektkosten er benötigt er das System umsetzt die Software Software bezahlen © ReqPOOL GmbH  Requirements Engineering – Warum? + Mehrwert durch Requirements Engineering Besseres Verständnis des Problems Risikominimierung ein falsches System zu entwickeln Grundlage für die Schätzung von Entwicklungsaufwand und Kosten Schaffung der Vorrausetzung fürs Testen © ReqPOOL GmbH Requirements Engineering – Warum? X Typische Symptome für mangelhaftes RE fehlende Anforderungen widersprüchliche Anforderungen mehrdeutige Anforderungen …und deren Ursachen Sofortiger Start ohne gemeinsames Verständnis Kommunikationsprobleme und unterschiedliche Wissensstände Unvollständige Dokumentation aufgrund von Annahmen Unzureichende Ausbildung und Fähigkeiten des Requirements Engineer © ReqPOOL GmbH 19  Requirements Engineering – Wo? Klassifizierung von Anforderungen Systemanforderungen Beschreiben was das System können soll Domänenanforderungen Beschreiben Anforderungen (Randbedingungen) die vom Stakeholderanforderungen Umfeld vorgegeben werden Beschreiben aus der Sicht der Stakeholder was dieser mit dem System erreichen will Geschäftsanforderungen Beschreiben Anforderungen, Benutzeranforderungen die eng mit dem gewünschten Beschreiben aus der Nutzer- Business Value verknüpft sind Perspektive was diese mit dem System erreichen wollen © ReqPOOL GmbH  Requirements Engineering – Wie? 4 Haupttätigkeiten eines Requirements Engineer 01 Ermitteln 02 Dokumentieren 03 Validieren 04 Verwalten © ReqPOOL GmbH  Requirements Engineering – Wie? 4 Haupttätigkeiten eines Requirements Engineer https://www.sophist.de/index.php?id=439&utm_so urce=pdf&utm_medium=text&utm_campaign=cpre -buch&utm_content=pk1v1 © ReqPOOL GmbH  Die Rolle und Aufgaben eines Requirements Engineer Persönlichkeitsprofil eines Requirements Engineer Selbst- bewusstsein Überzeugungs Kommunika- -fähigkeit tionsfähigkeit Eigenschaften von Anforderungs- experten Moderations- Analytisches fähigkeit Denken Konfliktlö- Empathie sungsfähigkeit © ReqPOOL GmbH  Bitte in Gruppen von 3-4 Personen aufteilen © ReqPOOL GmbH  Mobile Applikation zum Transport für Schulkinder und Menschen mit Beeinträchtigungen „Happy Wheels“ Der Verein „Happy Wheels“ hat uns mit der Erstellung eines Lastenhefts beauftragt. Wir sind zertifizierte Requirements Engineers und freuen uns bereits diese Aufgabe in den kommenden Wochen erledigen zu dürfen. In einem persönlichen Gespräch hat uns der Vereinsvorsitzende bereits die aktuelle Ausgangssituation geschildert. Siehe dazu im eLearning. © ReqPOOL GmbH  „Happy Wheels“ Projektarbeit im Team Im Zuge der Vorlesung erstellt ihr als Gruppe je ein Lastenheft, welches der Verein verwendet, um ein passendes System am Markt zu finden. Das Lastenheft dient als Ausgangsbasis für eine Ausschreibung. Darin wird beschrieben werden wesentlich Inhalte beschrieben, um dieses Drittlesbar zu machen. Endergebnis der Projektarbeit im Team ist das vollständige Lastenheft unter Berücksichtigung der gelehrten Inhalte. Abgabe des Lastenhefts durch eine Person aus der Gruppe am Freitag den 8. Dezember 2024, 12 Uhr. Gruppen von 3-4 Personen --> Versand der Gruppenaufteilung durch eine Person an [email protected] und [email protected] © ReqPOOL GmbH Exkurs: Lastenheft und Pflichtenheft LASTENHEFT Gesamte Anforderungen an ein System/Leistungen Inhalt eines Lastenhefters soll unabhängig von einer konkreten Realisierung formuliert werden Ein sauberes Lastenheft ermöglicht es, dass ein Dienstleiter angesprochen werden kann und um die Abgabe eines Angebots gebeten werden kann PFLICHTENHEFT Ausformulierte Lösungen und detaillierte Anforderungen auf Basis des Lastenhefts des Auftraggebers Beschreibt wie und womit ein Produkt entwickelt werden soll (technische + organisatorische Anforderungen) Grundlage zur Auswahl der Angebote für den Auftraggeber © ReqPOOL GmbH 30 Hinweise für Gestaltung des Lastenhefts Vorlage für ein Lastenheft wurde am eLearning abgelegt. Die Vorlage beinhaltet relevante Mindestinformationen, die im Lastenheft erläutert werden sollen. Weiters sollen die Lehrinhalte der Vorlesung im Lastenheft angewendet und eingesetzt werden, wenn sinnvoll. Drittlesbarkeit muss gegeben sein. © ReqPOOL GmbH 31 Hinweise für die Präsentation des Lastenhefts Präsentationsdauer: ca. 10 Minuten In der Präsentation sollen jene Inhalte aus dem Lastenheft präsentiert werden, die aus eurer Sicht, am relevantesten und wichtigsten sind, um euren Kolleg:innen und uns, euer Lastenheft zu erläutern. Wir wollen verstehen, für welche Zielgruppen, unter welchen Annahmen, die App spezifiziert wurde und u.a. welche wesentlichen Merkmale (zb. Funktionalitäten/Anforderungen) diese aufweist. Wie unterscheidet sich eure App von anderen? Welches Alleinstellungsmerkmal kann ausgewiesen werden? © ReqPOOL GmbH 7 LERNEINHEIT 2: Grundlegende Prinzipien des Requirements Engineerings © ReqPOOL GmbH 33  Grundlegende Prinzipien des Requirements Engineerings Überblick Problem – Anforderung – Lösung Kontext Validierung Gemeinsames Verständnis Evolution Stakeholder Innovation Wertorientierung Systematische & disziplinierte Arbeit © ReqPOOL GmbH  1. Wertorientierung Anforderungen sind Mittel zum Zweck, kein Selbstzweck 1 Anforderungen sollten nicht zum Selbstzweck beschrieben werden – So viel wie nötig, aber nicht zu wenig! 2 Der Wert einer Anforderung für die Systementwicklung ist ihr Nutzen abzüglich der Kosten für das Ermitteln, Dokumentieren, Validieren und Verwalten der Anforderung. 3 Der Nutzen einer Anforderung ist der Grad, den sie dazu beiträgt: Ein System zu bauen, das die Wünsche und Bedürfnisse der Stakeholder erfüllt Das Risiko von Fehlschlägen und kostspieligen Nacharbeiten bei der Entwicklung des Systems zu verringern für die Systementwicklung ist ihr Nutzen abzüglich der Kosten für das Ermitteln, Dokumentieren, Validieren und Verwalten der Anforderung. © ReqPOOL GmbH  2. Stakeholder Im Requirements Engineering geht es darum, die Wünsche und Bedürfnisse der Stakeholder zu befriedigen Berücksichtigung von Nutzern eines bestehenden Systems als Einbeziehung der richtigen Personen Stakeholder um Feedback über (Stakeholder) in den entsprechenden fehlende Funktionalitäten Rollen einzuholen Personas – zur fiktiven Beschreibung bei großen Es ist nicht ausreichend nur Gruppen oder von unbekannten Kunden und Endnutzer zu Stakeholdern mit ähnlichen berücksichtigen Merkmalen Stakeholder können eine oder Unterschiedliche Wünsche & mehrere Rollen haben (z.B. Bedürfnisse führen zu Konflikten, Benutzer, Kunde, Auftraggeber, die durch das RE identifiziert und Betreiber, Regulierungsbehörde) gelöst werden müssen © ReqPOOL GmbH  Aufgabe Definition möglicher Stakeholder- und Stakeholdergruppen. Zeit: 15 Min Präsentation: Random © ReqPOOL GmbH  3. Gemeinsames Verständnis Erfolgreiche Systementwicklung ist ohne eine gemeinsame Basis nicht möglich Explizites gemeinsames Implizites gemeinsames Verständnis: Verständnis: Förderung des gemeinsamen Förderung Potenzielledes gemeinsamen Hindernisse für Verständnisses durch: Verständnisses ein gemeinsamesdurch: Glossare, Prototypen, enge Zusammenarbeit Verständnis sind und Kosten/Nutzen-Abschätzung, intensiver Austausch, Outsourcing, geografische bestehende Systeme Vertrauen Entfernung und große Teams © ReqPOOL GmbH  3. Gemeinsames Verständnis Relevantes, richtiges und implizites Wissen externalisieren und dokumentieren, mit Fokus die Dark Info zu identifizieren. Informatorische Basis Kontextgrenze Implizit Explizit Irrelevant Irrelevantes Relevant spezifiziert „Dark“ Gemeinsames Wissen, Richtig spezifiziertes & richtig Info das nicht spezifiziert Wissen, das richtig verstanden wurde aber gleich verstanden wurde & verstanden wird relevant für das Projekt ist Verständnis Richtig Falsch Falsch angenommenes Spezifiziertes Wissen, Wissen das falsch verstanden wird Irrelevantes spezifiziert & Richtiges falsch Wissen verstanden aber Irrelevant Falsch & irrelevant Quelle: Glinz & Frinker -2013 - Shared Understanding: Key for Successful Requirements Engineering © ReqPOOL GmbH  4. Kontext Systeme können nicht isoliert verstanden werden Systemgrenze Systemabgrenzung System Kontextabgrenzung Systemkontext Kontextgrenze Irrelevante Umgebung © ReqPOOL GmbH 4. Kontext - Beispiel Systeme können nicht isoliert verstanden werden Geschäftsprozess Geschäftsprozess Softwaresystem System Hardwaresystem Softwaresystem Dokument (z.B. System Kontext gesetzliche Vorschrift) Skizze eines System und des System Kontexts © ReqPOOL GmbH 41  Aufgabe Skizzierung des möglichen Systemkontexts. Zu welchen anderen Systemen wird eine Schnittstelle benötigt? In welchem Kontext ist die mobile Applikation eingebunden? Welche Geschäftsprozesse sind betroffen? Zeit: 20 Min Präsentation: Random © ReqPOOL GmbH  4. Kontext Ein Big Picture hilft ein gemeinsames Verständnis über den gesamten Rollen Inhalt zu erarbeiten. Active Directory Nutzer Kunde Kunde Intern intern extern Kunde GmbH | BU 1 | BU 2 Umfeldsystem Webnutzer Vertrieb Kunden- Fertigungs- Qualitäts- service technische stelle Kunde Großkunde Web-Auftritt Ausarbeitu ng Laden der Daten aus SAP & Product Data System (PDS) Kunden Service Center (KSC) QVC mittels WebServices Produkt- Produkt- Produkt- Auftrags- Versand Qualität Kundenhierarchie & - basisdaten Suche Konfiguration management stammdaten Auftrag Grenzkurve Reporting Auftragsbestätigung Lieferschein Faktura/Rechnung Rollen & Werkszeugnis Reklamation Technologische Basis Rechte Active Directory Stammdaten Aufrufen der BU 1 & BU 2: Vertriebsplanung Versand- Dokumente Direkt Abruf QV-Parameter aktueller bereitemenge per Direkt- Eintrefftermin Produktions- Versandabrufe Link oder Grobblech: Parameter status (Online) PPS Aufträge ILLOPLAN Zukünftig sind die (Tandem) Produktionsstatus xECM PI Produktionsschritte Schnittstellen keine Kann diese entfallen wenn PNP Webservices mehr Schnittstelle verwendet werden kann? HLFG sondern JMS Entscheidung welche Schnittstelle SQM-DMS QVC VPE verwendet werden soll ist noch im Zuge SAP des Projekts zu treffen. Attestsystem Werkszeugnis-ID Attestsystem Werkszeugnis Attribute (Grobblech) © ReqPOOL GmbH  5. Problem – Anforderung – Lösung Ein unausweichlich ineinandergreifendes Tripel Ein Problem tritt auf wenn ein Stakeholder mit der aktuellen Situation unzufrieden ist. Eine Anforderung beschreibt die Wünsche/Bedürfnisse der Stakeholder, um ein Problem zu lösen oder zu vereinfachen. Eine Lösung erfolgt meist durch ein soziotechnisches System, das die Anforderungen erfüllt. Im Requirements Engineering sollten Probleme, Anforderungen und Lösungen beim Denken/Kommunizieren/Dokumentieren (soweit möglich) getrennt betrachtet werden. © ReqPOOL GmbH  6. Validierung Nicht validierte Anforderungen sind nutzlos Die Aufgabe eines Requirements Engineers im Zuge der Validierung ist es zu prüfen: Ob eine Einigung unter den Stakeholdern über die Anforderungen erreicht ist (d.h. keine ungelösten Konflikte und Prioritäten einvernehmlich gesetzt) Ob die Anforderungen den Bedürfnissen/Wünschen der Stakeholder entsprechen Fortlaufende Validierung der System- und Kontextgrenze © ReqPOOL GmbH  7. Evolution Sich ändernde Anforderungen sind kein Unfall, sondern der Normalfall Mögliche Gründe: Änderung der Geschäftsprozesse Einführung von neuen Produkten und Dienstleistungen durch Wettbewerber Sich verändernde Bedürfnisse der Stakeholder Prioritätsänderung oder Meinungsänderungen von Kunden Veränderungen der Technologie Feedback von aktuellen Systemnutzern Feedback von Stakeholdern z.B. während der Validierung Aufdeckung von Fehlern z.B. Inkonsistenzen in Anforderungen © ReqPOOL GmbH  8. Innovation Mehr vom Gleichen ist nicht genug Anforderungen sollen Inkrementell vs. disruptiv durch die Gestaltung von Innovationen die Stakeholder begeistern Innovationen im „Kleinen“ Innovationen im „Großen“ durch durch neue Funktionen, das Definieren von disruptiven Qualitäten wie bspw. neuen Ideen und den Einsatz neuartiger disruptiver neuer Technologie Benutzerfreundlichkeit (z.B. MP3-Player statt Discman) © ReqPOOL GmbH  9. Systematische & disziplinierte Arbeit Im Requirements Engineering unverzichtbar Die verwendeten Praktiken und Prozesse müssen an das jeweilige Problem, den gegeben Kontext und die vorhandene Arbeitsumgebung angepasst werden Nicht immer die gleichen Prozesse und Praktiken verwenden Erfolgreiche Prozesse und Praktiken aus den vergangenen Projekten nicht unreflektiert wiederverwenden © ReqPOOL GmbH Praxisbezug Welche Erfahrungen zu den Prinzipien hast du bereits gesammelt? Prinzip 1: Wertorientierung – Anforderungen sind Mittel zum Zweck, kein Selbstzweck Prinzip 2: Stakeholder – Im Requirements Engineering geht es darum, die Wünsche und Bedürfnisse der Stakeholder zu befriedigen Prinzip 3: Gemeinsames Verständnis – Erfolgreiche Systementwicklung ist ohne eine gemeinsame Basis nicht möglich Prinzip 4: Kontext – Systeme können nicht isoliert verstanden werden Prinzip 5: Problem · Anforderung · Lösung – Ein unausweichlich ineinandergreifendes Tripel Prinzip 6: Validierung – Nicht validierte Anforderungen sind nutzlos Prinzip 7: Evolution – Sich ändernde Anforderungen sind kein Unfall, sondern der Normalfall Prinzip 8: Innovation – Mehr vom Gleichen ist nicht genug Prinzip 9: Systematische und disziplinierte Arbeit – im Requirements Engineering unverzichtbar © ReqPOOL GmbH 49  Aufgabe Beschreibung der aktuellen IST- Situation sowie Problembeschreibung. Zeit: 20 Min Präsentation: Random © ReqPOOL GmbH LERNEINHEIT 3: PRAKTIKEN FÜR DIE ERARBEITUNG VON ANFORDERUNGEN © ReqPOOL GmbH 50  Quellen der Anforderungen Anforderungsquellen Stakeholder Dokumente Systeme im Betrieb Identifizieren ist sehr Normen und Standards Alt- oder wichtig da sonst negative oder Gesetzestexte Vorgängersysteme Auswirkungen Bestehende Konkurrenzsysteme Listen führen Anforderungsdokumente Individuelles / Dokumentation von Stakeholdermanagement Altsystemen © ReqPOOL GmbH Weitere Anforderungsquellen Neben den Stakeholdern existieren weitere Quellen für Anforderungen, die durch den Requirements Engineer aufgedeckt und berücksichtigt werden: > Bestehende Systeme und Altsysteme > (Prozess) Dokumente > Rechtliche und regulatorische Dokumente > Unternehmensspezifische Vorschriften > Nutzerstudien oder Marktanalysen © ReqPOOL GmbH 52  Wichtige Stakeholder eines Systems Entwickler des Systems Sponsoren und andere Behörden Geldgeber (Be-)Nutzer des Systems Kunden u. Auftraggeber © ReqPOOL GmbH  Exkurs - Stakeholdermanagement Monitoring „Kümmern“ Identifikation Beziehung Strategie Maßnahmen der Bewertung und Konflikte wählen umsetzen Stakeholder aufzeigen Analyse Engagement © ReqPOOL GmbH  Unterstützung im Umgang mit der Identifikation von Stakeholder Checklisten Organisationsstrukturen Geschäftsprozessdokumentationen Marktberichte Anfängliche Stakeholder © ReqPOOL GmbH  Umgang mit Stakeholdern im Projekt STAKEHOLDERLISTE Nicht identifizierte Stakeholder Name HERAUSFORDERUNGEN Funktion (Rolle) Weitere Personendaten Mangel an Motivation Zufrieden mit dem Kontaktdaten Altsystem Angst vor Veränderung Zeitlichen & räumliche Verfügbarkeit Negative Erfahrungen mit Vorprojekten Relevanz des Stakeholders Sein Wissensgebiet und –umfang Seine Ziele & Interessen bezogen auf das Projekt © ReqPOOL GmbH Die Definition der Personas ermöglicht allen Projektbeteiligten die einheitliche Sicht auf die Funktionsweise der Software und schaltet implizites Wissen über die User der Anwendung gleich. Definition Personas Eine Persona (lat. Maske) stellt einen Prototyp für eine Gruppe von Nutzern dar, mit konkret ausgeprägten Eigenschaften und einem konkreten Nutzungsverhalten. Personas dienen der Spezifikation von Stakeholdern einer Softwareanwendung. Dafür wird analysiert, welcher Nutzerkreis diese Anwendung später nutzen wird. Anhand von Beobachtungen an realen Menschen werden einige fiktive Personen geschaffen, die stellvertretend für den größten Teil der späteren tatsächlichen Anwender stehen sollen. Die Software wird dann spezifiziert und programmiert, indem das alle Projektbeteiligten die Bedürfnisse dieser fiktiven Personen aufgreifen und dementsprechend unterschiedliche Bedienungsszenarien durchspielen. Personas müssen einer fundierten Datenbasis entsprechen. Diese Datenbasis wird aus einem mehrstufigen Prozess aus quantitativen und vor allem qualitativen Umfragen, Beobachtungen (Work-Shadowing) und Nutzerinterviews erhoben. © ReqPOOL GmbH 57  Anforderungskategorisierung nach KANO BASISFAKTOREN Selbstverständlich Unterbewusstes Wissen Müssen erfüllt werden Beobachtungstechniken / Dokumente LEISTUNGSFAKTOREN Explizit gefordert Bewusstes Wissen Erfüllung ist erstrebenswert Befragungstechniken BEGEISTERUNGSFAKTOREN Angenehm und nützlich Unbewusstes Wissen Muss nicht erfüllt werden Kreativitätstechniken © ReqPOOL GmbH  Aufgabe #6 Definition von Basisfaktoren, Leistungsfaktoren und Begeisterungsfaktoren der mobilen Applikation für „Happy Wheels“ Zeit: 20 Min Präsentation: Random © ReqPOOL GmbH  Arten von Ermittlungstechniken - Erhebung Erhebung Befragung Kollaboration Beobachtung Artefaktbasiert Interview Workshop Feldbeobachtung Systemarchälogie Fragbogen Hilfstechniken Apprenticing Feedbackanalyse Wiederverwendung © ReqPOOL GmbH Workshop Setup Jeder Workshop hat ein Ziel und liefert ein Ergebnis (z.B. Vision Statement, Liste von Zielen, Stakeholder-Liste, Übersicht über die Systemumgebung, Anforderungen, Roadmap etc.) Moderator Ist verantwortlich für den Ablauf, wählt passende Methoden aus und definiert die Zielsetzung & Ergebnisse gemeinsam mit dem Auftraggeber. Teilnehmer Ist verantwortlich für den Inhalt des Workshops. Auftraggeber Ist verantwortlich für die Vorgabe der Zielsetzung & Ergebnisse und unterstützt bei der Auswahl der Teilnehmer. © ReqPOOL GmbH 61 Workshop richtig machen VORBEREITUNG Ziele definieren und Inhalte abgrenzen Zeitplanung erstellen Teilnehmerauswahl treffen Agenda vorbesprechen oder aussenden Vorbereitung Begleitende Unterlagen vorbereiten WORKSHOP Vorstellungsrunde und Vorstellung der Ziele Durchführung Inhalte präsentieren Praktische Beispiele erarbeiten Diskussionen zulassen und moderieren Nächste Schritte erarbeiten Nachbereitung Pausen einplanen NACHBEREITUNG Protokoll versenden Erarbeitete Inhalte an Teilnehmer versenden Prüfen von Einhaltung der vereinbarten Ziele © ReqPOOL GmbH 62  Arten von Ermittlungstechniken – Entwurf/Ideenfindung Entwurf und Ideenfindung Kreativität Entwurf Design Thinking Brainstorming Szenarien Perspektivenwechsel Storyboards Analogien Prototypen © ReqPOOL GmbH  Exkurs: Design Thinking Beispiel: IDEO – Shopping Cart https://www.youtube.com/watch?v=M66ZU2PCIcM © ReqPOOL GmbH Auswahl der richtigen Ermittlungstechniken Art des Systems Beteiligte Personen Softwareentwicklungs- Organisatorischer Aufbau Lebenszyklusmodell © ReqPOOL GmbH 65  Aufgabe Definition von einer oder mehreren Personas, die als spätere Nutzer:innen der mobilen Applikation in Frage kommen. Zeit: 10 Min Präsentation: Random © ReqPOOL GmbH LERNEINHEIT 4: PROZESS & ARBEITSSTRUKTUR © ReqPOOL GmbH 66 Einflussfaktoren auf Requirements-Engineering-Prozesse Eignung des Gesamtprozesses A F Randbedingungen Verfügbare Zeit Entwicklungskontext B H und Budget Fähigkeiten und Verfügbarkeit von Stakeholdern C I Volatilität Erfahrungen des Gemeinsames Verständnis D J Requirements Engineer Komplexität/Kritikalität des zu entwickelnden Systems E © ReqPOOL GmbH 67 Einflussfaktoren auf Requirements-Engineering-Prozesse Eignung des Gesamtprozesses A F B H D J © ReqPOOL GmbH 68 Einflussfaktoren auf Requirements-Engineering-Prozesse Eignung des Gesamtprozesses A Entwicklungskontext B © ReqPOOL GmbH 69 Entwicklungskontext Die folgenden Facetten werden unterschieden: Auftraggeber- Entwicklung des Systems für einen individuellen Kunden → Stakeholder & potentielle Nutzer befinden sich auf Kunden-Seite Auftragnehmer- Entwicklung des Systems für einen Markt → tatsächliche Nutzer sind nicht bekannt, Anforderungen an das System werden durchs Produkt- Beziehung /Portfoliomanagement vorgegeben Auftragnehmer spezifiziert und entwickelt das System für einen speziellen Kunden, der das System später nutzen wird Entwicklungstyp Organisation entwickelt ein System mit dem Ziel dieses als Produkt oder Dienstleitung in einem bestimmten Marktsegment anzubieten Anbieter erweitert ein existierendes System, um es als Produkt weiterzuverkaufen Konkrete Vertragsbedingungen sind Teil des Entwicklungskontexts Vertragsbedingungen Festpreisentwicklung vs. gewisse Spielräume hinsichtlich Budgets, Funktionalität und Fristen Bei noch keinem langjährig bestehenden Vertrauensverhältnis ist Vertrauen es sinnvoll einen strikten RE-Prozess mit klaren Zielsetzungen, Verantwortlichkeiten, Meilensteinen und Fristen zu definieren © ReqPOOL GmbH 70 Einflussfaktoren auf Requirements-Engineering-Prozesse Fähigkeiten und Verfügbarkeit von Stakeholdern C D E © ReqPOOL GmbH 71 Fähigkeiten und Verfügbarkeit von Stakeholdern Zeitliche und örtliche Verfügbarkeit der Stakeholder Anpassung der Ermittlung und Abstimmung von Anforderungen an die Verfügbarkeit der Stakeholder Iteratives Vorgehen z. B. - Regelmäßige Workshops mit Stakeholdern - Online-Kollaborationswerkzeuge © ReqPOOL GmbH 72 Einflussfaktoren auf Requirements-Engineering-Prozesse Volatilität der Anforderungen Entwicklungskontext Randbedingungen Verfügbare Zeit Gemeinsames Verständnis D und Budget © ReqPOOL GmbH 73  Gemeinsames Verständnis Für eine erfolgreiche Systementwicklung ist ein möglichst einheitliches Verständnis nötig 1 2 Einheitlichkeit Abgestimmtheit Einheitliches Verständnis Zusätzlicher hinsichtlich des zu Abstimmungsaufwand lösenden Problems, der unter den Beteiligten Anforderungen an das als Konsequenz von System und den unterschiedlichem Systemkontext Verständnis 3 Gemeinsames Einführung eines Prozesses zur Herstellung eines Verständnis gemeinsamen Verständnisses im Falle einer Abweichung © ReqPOOL GmbH 74 Einflussfaktoren auf Requirements-Engineering-Prozesse Eignung des Gesamtprozesses Volatilität der Anforderungen Entwicklungskontext Fähigkeiten und Verfügbarkeit Randbedingungen von Stakeholdern Verfügbare Zeit Gemeinsames Verständnis und Budget Komplexität/Kritikalität des zu entwickelnden Systems E © ReqPOOL GmbH 75 Komplexität und Kritikalität des zu entwickelnden Systems RE unterstützt die Komplexität durch Strukturierung beherrschbar zu machen Bei sicherheitskritischen Systemen dienen die Arbeitsprodukte als ein Teil zum Nachweis, dass das System geltende Normen und Standards erfüllt Einsatz von modellbasierter Dokumentation, um Komplexität beherrschbar zu machen und angemessen mit der Kritikalität umzugehen © ReqPOOL GmbH 76 Einflussfaktoren auf Requirements-Engineering-Prozesse F Randbedingungen Randbedingungen Verfügbare Zeit und Budget © ReqPOOL GmbH 77 Vorgegebene Randbedingungen Einflussfaktoren Weitere Konkrete Randbedingungen definieren Allgemeine Vorgaben hinsichtlich Gesetzliche Vorgaben Randbedingungen einzuhaltender Normen Randbedingungen © ReqPOOL GmbH 78 Einflussfaktoren auf Requirements-Engineering-Prozesse Randbedingungen Verfügbare Zeit H und Budget I Verfügbare Zeit und Budget © ReqPOOL GmbH 79 Verfügbare Zeit und Budget Ressourcen wirken sich direkt auf die einzusetzenden Requirements Engineering – Techniken aus: o Ermittlung der Anforderungen o Iterationszyklen o Umfang der Dokumentation Notwendig ist eine Abstimmung und Verteilung des Gesamtaufwandes mit anderen Disziplinen (z.B. Architektur, Entwicklung) unter Betrachtung von Zeitschienen und Meilensteinen © ReqPOOL GmbH 80 Projektstrukturplan (PSP) © ReqPOOL GmbH 81 Quelle: https://blog.awork.io/lesenswert/projektplan-erstellen/  Projektablaufplan (PAP) © ReqPOOL GmbH Quelle : https://benjamin-michels.de/projektablaufplan-eine-kernmethode-im-projektmanagement/ Einflussfaktoren auf Requirements-Engineering-Prozesse Randbedingungen Verfügbare Zeit und Budget I Volatilität J © ReqPOOL GmbH 83 Einflussfaktoren auf Requirements-Engineering-Prozesse Randbedingungen Verfügbare Zeit und Budget Erfahrungen des J Requirements Engineer © ReqPOOL GmbH 84 Erfahrungen des Requirements Engineers Auf Basis von Erfahrungen kann ein Requirements Engineer entscheiden welche Techniken unter ähnlichen Bedingungen bereits gut oder weniger gut funktioniert haben Nur Vorgehen und Techniken einsetzen, die dem Requirements Engineer vertraut sind © ReqPOOL GmbH 85 Facetten der RE-Prozesskonfiguration marktorientiert explorativ Zielfacette linear Zeitfacette iterativ präskriptiv kundenspezifisch © ReqPOOL GmbH 86 Facetten der RE-Prozesskonfiguration marktorientiert System wird als Produkt oder explorativ Service auf dem Markt angeboten Anforderungen sind im Vorfeld nicht bekannt, Anforderungen müssen aufgedeckt bzw. systematisch erarbeitet werden Plangetrieben, vorgelagertes RE, schwergewichtiger Prozess iterativ linear Agiler, iterativer RE- Prozess, leichtgewichtiger Prozess System wird für einen spezifischen Kunden präskriptiv entwickelt Anforderungen dienen als Teil eines Vertrages kundenspezifisch © ReqPOOL GmbH 87 Zeitfacette: linear vs. iterativ Plangetrieben, vorgelagertes RE, schwergewichtiger Prozess iterativ linear Agiler, iterativer RE- Prozess, leichtgewichtiger Prozess © ReqPOOL GmbH 88 Zeitfacette: linear vs. iterativ Kriterien für Planbasiert und weitgehend linearer Entwicklungsprozess linearen RE- Prozess: Die Stakeholder kennen ihre Anforderungen und können diese im Voraus spezifizieren Eine umfassende Anforderungsspezifikation ist als vertragliche Grundlage erforderlich Die Regulierungsbehörden verlangen eine umfassende, formell freigegebene Anforderungsspezifikation in einem frühen Stadium der Entwicklung Kriterien für Iterativer und agiler Entwicklungsprozess iterativen RE- Prozess: Viele Anforderungen sind nicht im Voraus bekannt, entstehen im Laufe der Entwicklungen Verfügbarkeit der Stakeholder ermöglicht kurze Rückkopplungsschleifen Dauer der Entwicklung lässt mehr als nur eine oder zwei Iterationen zu Möglichkeit zur leichten Änderung von Anforderungen ist wichtig © ReqPOOL GmbH 89 Zweckfacette: präskriptiv vs. explorativ explorativ Anforderungen sind im Vorfeld nicht bekannt, Anforderungen müssen aufgedeckt bzw. systematisch erarbeitet werden präskriptiv Anforderungen dienen als Teil eines Vertrages © ReqPOOL GmbH 90 Zweckfacette: präskriptiv vs. explorativ Kriterien für Kunde benötigt einen festen Vertrag für die Systementwicklung präskriptiven RE- Prozess: Funktionalität und Umfang haben Vorrang vor Kosten und Terminen Entwicklung soll ausgeschrieben bzw. ausgelagert werden Kriterien für Stakeholder haben nur eine vage Vorstellung ihrer Anforderungen explorativen RE- Prozess: Stakeholder sind stark involviert + liefern kontinuierliches Feedback Termine und Kosten haben Vorrang vor Funktionalität und Umfang Es ist nicht von vorhinein klar welche Anforderungen umgesetzt werden sollen © ReqPOOL GmbH 91 Zielfacette: marktorientiert vs. kundenspezifisch marktorientiert System wird als Produkt oder Service auf dem Markt angeboten System wird für einen spezifischen Kunden entwickelt kundenspezifisch © ReqPOOL GmbH 92 Zielfacette: marktorientiert vs. kundenspezifisch Kriterien für System soll hauptsächlich von der auftraggebenden Organisation genutzt werden kunden- spezifischen RE- Prozess: Wichtigsten Stakeholder sind mit der Organisation des Auftraggebers verbunden Für Stakeholder-Rollen können konkrete Personen identifiziert werden Kunde wünscht eine Anforderungsspezifikation, die als Vertrag dienen kann Kriterien für System wird in einem bestimmten Marktsegment als Produkt oder markt- Dienstleistung verkauft orientierten RE- Künftige Benutzer sind nicht eindeutig identifizierbar Prozess: Anforderungen müssen so gestaltet werden, dass sie den erwarteten Wünschen der relevanten Benutzergruppe entsprechen Product Manager (Product Owner), Marketingpersonen sind die primären Stakeholder © ReqPOOL GmbH 93 Anmerkungen marktorientiert explorativ Zielfacette linear Zeitfacette iterativ präskriptiv kundenspezifisch © ReqPOOL GmbH 94 Konfiguration eines RE-Prozesses Partizipativer RE-Prozess: marktorientiert iterativ, explorativ und kundespezifisch explorativ Vertraglich regulierter RE- Ziel Prozess: typischerweise linear, präskriptiv, kundenspezifisch Zeit linear iterativ Produktorientierter RE-Prozess: iterativ, explorativ, marktorientiert präskriptiv kundenspezifisch © ReqPOOL GmbH 95 Partizipativer RE-Prozess marktorientiert Ausrichtung auf enge explorativ Zusammenarbeit zwischen Auftraggeber und Auftragnehmer Stakeholder und Auftraggeber Ziel involviert Zeit linear iterativ Häufige Arbeitsprodukte: Product Backlog mit User Stories präskriptiv und Tasks Prototypen kundenspezifisch © ReqPOOL GmbH 96  Vertraglich Regulierter RE-Prozess marktorientiert Zu Beginn der Systementwicklung explorativ wird eine Anforderungsspezifikation von der Auftraggeber erstellt (=Lastenheft) Ziel Der Auftragnehmer analysiert die Anforderungsspezifikationen linear Zeit iterativ (=Pflichtenheft) Häufige Arbeitsprodukte: präskriptiv Lasten-/Pflichtenheft kundenspezifisch © ReqPOOL GmbH 97 Produktorientierter RE-Prozess marktorientiert Kein Auftragnehmer/Arbeitsgeber explorativ Verhältnis Produkt/Service wird an verschiedenste Kunden verkauft Ziel Zeit linear iterativ Häufige Arbeitsprodukte: Product Backlog mit User Stories präskriptiv und Tasks Prototypen kundenspezifisch © ReqPOOL GmbH 98  Aufgabe Entlang welcher Facette wird euere Applikation angesiedelt sein und warum? Zeit: 15 Min. Präsentation: Random © ReqPOOL GmbH LERNEINHEIT 5: ARBEITSERGEBNISSE UND DOKUMENTATIONSPRAKTIKEN - Allgemeiner Überblick © ReqPOOL GmbH 100 Arbeitsergebnisse im Requirements Engineering Ein Arbeitsergebnis/Dokumentationsarte ist ein dokumentiertes Zwischenergebnis oder finales Ergebnis, das im Zuge eines Arbeitsprozesses entsteht. Einzelne Anforderungen Anforderung – liegt in Form von Beschreibungen einzelner Anforderungen und typischerweise in natürlicher Sprache vor (Umfang → klein) User Story – beschreibt aus dem Blickwinkel eines Stakeholders eine gewünschte Funktion oder ein gewünschtes Verhalten (Umfang → klein) © ReqPOOL GmbH 101 Arbeitsergebnisse im Requirements Engineering Menge von Use Case – beschreibt aus dem Blickwinkel der Nutzer des Systems eine Anforderungen notwendige Systemfunktion (Umfang → klein bis mittel) Grafisches Model – wird verwendet zur Beschreibung von unterschiedlichen Aspekten des Systems bzw. des Kontexts (Umfang → mittel) Aufgabenbeschreibung – beschreibt Aufgaben, die das System erfüllen soll (= Zusammenfassung von Anforderungen) (Umfang → klein bis mittel) Externe Schnittstellenbeschreibung – beschreibt die im Systemkontext ausgetauschten Informationen zwischen einem System und einem Akteur ((Umfang → mittel) Epic – beschreibt die Bedürfnisse eines Stakeholders auf einer hohen Abstraktionsebene (Umfang → klein bis mittel) © ReqPOOL GmbH 102 Arbeitsergebnisse Definition von System-, Geschäfts-, Stakeholder- oder Benutzer-Anforderungsspezifikation – Anforderungs- wird bereitgestellt in Form eines freigegebenen oder durch eine Baseline dokumenten fixierten Anforderungsdokuments (Umfang → groß bis sehr groß) Product und Sprint Backlog - dient zur Verwaltung von Listen von Arbeitsaufgaben (Umfang → mittel bis groß) Story Map – ordnet eine Menge von User Stories an und setzt diese miteinander in Beziehung (Umfang → mittel) Vision – formuliert ein konzeptuelles Leitbild für das zukünftige System (Umfang → klein) Lastenheft - vollständige technische und fachliche Spezifikation zur Systementwicklung (Umfang → groß bis sehr groß) Scope Dokument – Überblick über technische und fachliche Spezifikation mit Zusammenhängen für Pilotierung bzw. agile/iterative Umsetzung (Umfang → groß bis sehr groß) © ReqPOOL GmbH 103 Arbeitsergebnisse im Requirements Engineering Weitere Glossar – stellt eine eindeutige und abgestimmte gemeinsame Arbeits- Terminologie bereit ergebnisse (Umfang → mittel) Textuelle Beschreibung oder grafische Skizzen – dokumentiert kurzfristig gewonnene Informationen oder visualisiert Information zum besseren Verständnis (Umfang → klein) Prototypen – verbessern das Verständnis bezüglich der Eigenschaften des betrachteten Systems und werden zur Validierung von Anforderungen herangezogen (Umfang → klein bis groß) © ReqPOOL GmbH 104  Allgemeine Dokumentationsrichtlinien Dokumentation durch Vorlagen Dokumentation in natürlicher Dokumentation durch (auch: template- oder Sprache schablonenbasiert) konzeptuelle Modelle VORTEILE VORTEILE VORTEILE Kein Lernaufwand Schnelle Erfassung und Kompakter und für geübte Sehr vielseitig einsetzbar einfache verständlicher Wiederverwendung Höherer Grad der NACHTEILE Verbesserung der Qualität Eindeutigkeit Gefahr der Mehrdeutigkeit Gefahr der NACHTEILE NACHTEILE Perspektivenvermischung Gefahr, dass der Fokus weg Setzt spezifische vom Inhalt zum reinen Modellierungskenntnisse Ausfüllen der Vorlage voraus wechselt Mischform Hebt das Beste aus beiden Welten heraus Ergänzung, wo möglich und nötig © ReqPOOL GmbH LERNEINHEIT 6: ARBEITSERGEBNISSE UND DOKUMENTATIONSPRAKTIKEN -natürlichsprachige Arbeitsergebnisse © ReqPOOL GmbH 106  Sprache „Populanten von Domizilen mit transparenter Außenstruktur sollten sich von der Transformation resistenter Materie in Wurfprojektile distanzieren.“ © ReqPOOL GmbH  Sprache „Populanten von Domizilen mit transparenter Außenstruktur sollten sich von der Transformation resistenter Materie in Wurfprojektile distanzieren.“ (Wer im Glashaus sitzt, sollte nicht mit Steinen werfen) „Warum das Huhn die Straße überquerte“ von Holger Fröhner © ReqPOOL GmbH  Sprachliche Effekte Sender Empfänger Sprachliche Effekte beeinflussen sehr stark die Kommunikation und können die Informationen verfälschen Subjektive Wahrnehmung Wissenstransformation → Transformationseffekte © ReqPOOL GmbH  Sprachliche Effekte NOMINALISIERUNG Prozess als Hauptwort dargestellt z.B.: Bei einem Systemabsturz soll ein Neustart des Systems erfolgen. UNSPEZIFISCHE SUBSTANTIVE Empfänger Substantive nicht definiert Sender z.B.: Die Daten sollen dem Benutzer auf dem Terminal angezeigt werden. UNIVERSALQUANTOREN Nicht definierte Häufigkeit z.B.: Das System soll in jedem Untermenü alle Datensätze anzeigen. UNVOLLSTÄNDIGE SPEZIFIZIERTE BEDINGUNGEN Bedingungsstrukturen klar darstellen z.B.: Das Restaurantsystem soll einem registrierten Gast bei einem Alter von über 17 Jahren alle im Lokal angebotenen Getränke anzeigen. UNVOLLSTÄNDIG SPEZIFIZIERTE PROZESSWÖRTER Passiv-Formulierung vermeiden, Prozess vollständig beschreiben (was von wo wohin?) z.B.: Zur Anmeldung des Benutzers werden die Login-Daten eingegeben © ReqPOOL GmbH  Sprache - Negativbeispiele Das User Interface muss cool aussehen… Definition von cool? Der Konfigurationsbereich sollte teilweise für den Super User sichtbar sein. In der Mitte vom Bildschirm abschneiden? Sender Empfänger An dieser Stelle können Grafiken angezeigt werden. Können, müssen aber nicht. Nach erfolgreichem Login erhält der Benutzer vielleicht noch seine letzten Aktivtäten angezeigt. Aber nur vielleicht und auch nur, wenn Zeit ist…. © ReqPOOL GmbH  Natürliche Sprache – Vor- und Nachteile Ausdrucksstärke und Flexibilität Subjektive Wahrnehmung Für jeden verständlich / keine Transformationseffekt Ausbildung erforderlich Interpretationsspielraum Es lässt sich quasi alles dokumentieren © ReqPOOL GmbH  Vorlagenbasierte Arbeitsergebnisse als bewährte Antwort Vorlage für Anforderungen 1. Satzschablone Vorlage für Formulare 2. Formularvorlage 3. Dokumentenvorlage Vorlage für Dokumente © ReqPOOL GmbH  Vorlagenbasierte Arbeitsergebnisse Klare Struktur Struktur von Inhalt Erfassung von wichtigen Strukturelle Lücke Informationen Einheitliches Aussehen Höhere Qualität © ReqPOOL GmbH Die fünf Schritte zur Formulierung von Anforderungen mittels einer Satzschablone sind: Konstruktion von Anforderungen mittels Satzschablone Die fünf Schritte zur Formulierung von Anforderungen mittels einer Satzschablone sind: E.g., Chris Rupp © ReqPOOL GmbH 115 Die fünf Schritte zur Formulierung von Anforderungen mittels einer Satzschablone sind: Konstruktion von Anforderungen mittels Satzschablone 1. Festlegen der rechtlichen Verbindlichkeit 1 E.g., Chris Rupp © ReqPOOL GmbH 116 Die fünf Schritte zur Formulierung von Anforderungen mittels einer Satzschablone sind: Konstruktion von Anforderungen mittels Satzschablone 1. Festlegen der rechtlichen Verbindlichkeit 2. Den Kern der Anforderung, den Prozess benennen 2 E.g., Chris Rupp © ReqPOOL GmbH 117 Die fünf Schritte zur Formulierung von Anforderungen mittels einer Satzschablone sind: Konstruktion von Anforderungen mittels Satzschablone 1. Festlegen der rechtlichen Verbindlichkeit 2. Den Kern der Anforderung, den Prozess benennen 3. Charakterisieren der Aktivität des Systems 3 E.g., Chris Rupp © ReqPOOL GmbH 118 Die fünf Schritte zur Formulierung von Anforderungen mittels einer Satzschablone sind: Konstruktion von Anforderungen mittels Satzschablone 1. Festlegen der rechtlichen Verbindlichkeit 2. Den Kern der Anforderung, den Prozess benennen 3. Charakterisieren der Aktivität des Systems 4. Objekte einfügen 4 E.g., Chris Rupp © ReqPOOL GmbH 119 Die fünf Schritte zur Formulierung von Anforderungen mittels einer Satzschablone sind: Konstruktion von Anforderungen mittels Satzschablone 1. Festlegen der rechtlichen Verbindlichkeit 2. Den Kern der Anforderung, den Prozess benennen 3. Charakterisieren der Aktivität des Systems 4. Objekte einfügen 5. Formulieren von logischen und zeitlichen Bedingungen 5 E.g., Chris Rupp © ReqPOOL GmbH 120 Die fünf Schritte zur Formulierung von Anforderungen mittels einer Satzschablone sind: Konstruktion von Anforderungen mittels Satzschablone Satz 1 Das Bibliothekssystem muss die Möglichkeit bieten, neue Leihobjekte von externen Datenmedien des Bibliothekssystems zu importieren Satz 2 Nachdem das Bibliothekssystem Daten neu eingegebener Bibliothekskunden oder neuer Leihgegenstände von benachbarten Bibliothekssystem empfangen hat, muss das Bibliothekssystem die Daten speichern. Satz 3 Falls während des Importierens ein semantischer oder syntaktischer Datenfehler auftritt, muss das Bibliothekssystem dem Administrator für einzelne zu importierende neue Leihobjekte den jeweiligen Fehler (Fehlernummer und Fehlerbeschreibung) auf dem Bildschirm und auf dem Drucker ausgeben. © ReqPOOL GmbH 121 Die fünf Schritte zur Formulierung von Anforderungen mittels einer Satzschablone sind: Satzschablone für User Stories Personas Als Kernfunktionalität möchte ich Motivation / Zweck sodass © ReqPOOL GmbH 122 Die fünf Schritte zur Formulierung von Anforderungen mittels einer Satzschablone sind: Satzschablone für User Stories Als Teilnehmerin der Vorlesung möchte ich die Aufgaben, Inhalte und Vorgehensweisen des Requirements Engineerings lernen sodass ich in erster Linie die Klausur bestehe und das theoretisch erlernte Wissen gewinnbringend in die Praxis mitnehmen kann. © ReqPOOL GmbH 123  Aufgabe Anwendung einer Satzschablone für bereits definierte Anforderungen sowie Definition weiterer für die Umsetzung relevanter funktionalen und nicht funktionaler Anforderungen. Zeit: 30 Min © ReqPOOL GmbH  Qualitätskriterien für einzelne Anforderungen ADÄQUAT (ABGESTIMMT) VERSTÄNDLICH NOTWENDIG Beschreibt Bedürfnis und Für alle betreffenden Hinsichtlich aktueller ist akzeptiert von Stakeholder / kann sich in Gegebenheiten gültig Stakeholder Phasen unterscheiden EINDEUTIG VOLLSTÄNDIG PRÜFBAR Kein Für geforderte Durch Tests nachweisbar Interpretationsspielraum Funktionalität ausreichend beschrieben © ReqPOOL GmbH  Qualitätskriterien für eine Menge von Anforderungen KONSISTENT NICHT REDUNDANT VOLLSTÄNDIG Widerspruchsfrei in sich Einzelne Anforderungen Alle relevanten und mit anderen AF werden nicht mehrfach Anforderungen sind gepflegt vorhanden MODIFIZIERBAR VERFOLGBAR KONFORM Spezifikationen können Ursprung, Umsetzung und Einhalten von Richtlinien erweitert werden Beziehungen zur Dokumentation nachvollziehbar © ReqPOOL GmbH LERNEINHEIT 7: ARBEITSERGEBNISSE UND DOKUMENTATIONSPRAKTIKEN -modellbasierte Arbeitsergebnisse © ReqPOOL GmbH 149 Warum eigentlich modellieren? © ReqPOOL GmbH 150  Eine Gegenüberstellung © ReqPOOL GmbH  Zweck von Modellierung von Anforderungen 1. Spezifikation 2. Dekomposition 3. Paraphrasierung 4. Validierung © ReqPOOL GmbH Eigenschaften von Modellen Abbild der Realität Deskriptiv Aussage über die existierende Realität Präskriptiv Vorbild von etwas, was noch nicht existiert Verkürzung der Realität Selektion & Verdichtung Pragmatische Eigenschaft Verwendungskontext und Verwendungszweck © ReqPOOL GmbH 153 Konzeptuelle Modellierungssprachen Anforderungsmodelle Syntax vs. Semantik = Schnellere Erfassung von bildhaft dargestellten Informationen Eine Perspektive auf Anforderungen kann modelliert werden Zweckmäßige Abstraktion der Realität durch Definition von Modellierungssprache & Verwendungszweck © ReqPOOL GmbH 155  Vor- und Nachteile der Anforderungsmodellierung Beziehungen zwischen Konsistente Datenhaltung Anforderungen werden klarer schwierig Verringerung der Komplexität Übergreifende Integration schwierig Verringerung von Interpretationen Hauptsächliche Fokussierung auf funktionale Anforderungen Nicht alles darstellbar © ReqPOOL GmbH Kontextmodellierung - Zielmodelle Zielmodelle oder- und- Dekomposition Dekomposition Ziel Ziel Teilziel Teilziel Teilziel Teilziel Teilziel Teilziel © ReqPOOL GmbH 157 BEISPIEL FÜR UND-ODER-BÄUME Um das Zielmodell „Komfortable Navigation zum Zielort“ zu erreichen müssen Die 3 Teilziele (Und-Dekomposition) „Dynamische Anpassung der Route“ „Komfortable Erfassung des Zielorts“ „Komfortable Routenführung“ und einem Teilziel (Oder-Dekomposition): „Manuelle Eingabe von Verkehrsbehinderungen“ „Automatische Aktualisierung von Verkehrsdaten“ Quelle: Pohl & Rupp-2015 – Basiswissen Requirements Engineering © ReqPOOL GmbH 158 Kontextmodellierung – Use Cases Use Case Use Case Use Case Diagramm Spezifikationen Akteure (Personen bzw. andere Systeme) im Systemkontext Systemgrenze Use Cases Verschiedene Beziehungstypen zwischen den Elementen © ReqPOOL GmbH 159 UML – USE CASE DIAGRAMM Quelle: Pohl & Rupp-2015 – Basiswissen Requirements Engineering © ReqPOOL GmbH 160 Beispiel: Use-Case-Diagramm mit UML Include: „Zum Zielort navigieren“ enthält die Schritte „Standort ermitteln“ und „Zielort eingeben“ Extend: „Verkehrsinformation downloaden“ ist ein Teil von „Zielort navigeren“ Quelle: Pohl & Rupp-2015 – Basiswissen Requirements Engineering © ReqPOOL GmbH 161  Aufgabe Erstellt ein einfaches Use Case Diagramm mit der Verwendung von mind. einer und einer -Beziehung. Zeit: 20 Min Präsentation: Random © ReqPOOL GmbH  USE CASES SPEZIFIKATION Bezeichner: Name: Autoren: Priorität: ID eindeutig Verfasser Wichtigkeit Namensgebung Nomen & Verb Kritikalität: Quelle: Verantwortlicher: zB: Schadensausmaß Stakeholder, verantwortlicher bei Fehlerverhalten Dokument, System Stakeholder Kurzbeschreibung Auslösendes Ereignis: Akteure: Vorbedingung: Nachbedingung: löst den Use Case aus Auflistung aller Liste für Liste von Zuständen, Akteure, die mit dem Vorbedingungen, die in denen sich das Use Case in Beziehung erfüllt sein müssen System unmittelbar stehen nach Ausführung befindet Ergebnis: Alternativszenarien: Beschreibung der oftmals mit anderen Ausgaben, die währen Hauptszenario Nachbedingungen Ausnahmeszenarien der Ausführung erhalten erzeugt werden Qualität: Querbezüge zu Qualitätsanforderungen © ReqPOOL GmbH  UCD – Use Case Description 1. Kurzbeschreibung Ein Beispiel 2. Zweck 3. Ergebnis 4. Kontext und Abgrenzung 5. Quellen 6. Grafischer Überblick über den Ablauf 7. Hauptszenarien 7.1. 7.1.1. Auslöser und Vorbedingungen 7.1.2. Schritte 8. Alternativszenarien 8.1. 8.1.1. Auslöser und Vorbedingungen 8.1.2. Schritte 9. Fehlerszenarien 9.1. 9.1.1. Auslöser und Vorbedingungen 9.1.2. Schritte 10. Zusatzinformationen 11. Hinweise für das Domänenmodell 12. Sonstige Hinweise für die Lösung 13. Qualitätsanforderungen 14. Hinweise für Testfälle und Testdaten 15. Glossar 16. Wünsche und Ideen für die Zukunft 17. Detailbeschreibung Ist © ReqPOOL GmbH  Modellbasierte Arbeitsergebnisse MODELLIERUNG VON STRUKTUR UND DATEN MODELLIERUNG VON FUNKTION UND ABLAUF MODELLIERUNG VON ZUSTAND UND VERHALTEN © ReqPOOL GmbH  Modellierung von Struktur und Daten Struktur und UML-Klassendiagramme Datenmodellierung = betrachtet Anforderungen an die statischen Struktureigenschaften d.h. wichtige Objekte des System, ihre Daten und ihre Beziehungen untereinander © ReqPOOL GmbH  UML Klassendiagramme Wieso? Modellierung von Modellierung von Klassen und Basisklassen und Vielseitig Beziehung von Schnittstellen über Klassen Stereotypen © ReqPOOL GmbH  UML Klassendiagramme Basisnotationselemente [Name] m [Name] Attribute Aggregation n...m Einzelne Teile können existieren 1..* Komposition Teile können nicht ohne Ganzes existieren Klasse Assoziation Multiplizitäten Rollen © ReqPOOL GmbH  UML Klassendiagramme Basisnotationselemente [Name] Attribute (Methoden) Klasse © ReqPOOL GmbH  UML Klassendiagramme Basisnotationselemente [Name] Assoziation © ReqPOOL GmbH  UML Klassendiagramme Beispiele für Multiziplitäten [Name] m [Name] Attribute n...m 1..* Klasse Assoziation Multiplizitäten Rollen - 0..1 (keins oder eins) - 0..* (keins bis beliebig viele) - 1..* (eins bis beliebig viele) - 1..3 (zwischen eins und drei) - 3 (genau drei) © ReqPOOL GmbH  UML Klassendiagramme Beispiel - Kann es im System Kunden geben die nie eine Bestellung durchgeführt haben? - Besitzt jedes Objekt der Klasse Bestellung_Detail einen Artikel? © ReqPOOL GmbH  Modellbasierte Arbeitsergebnisse MODELLIERUNG VON STRUKTUR UND DATEN MODELLIERUNG VON FUNKTION UND ABLAUF MODELLIERUNG VON ZUSTAND UND VERHALTEN © ReqPOOL GmbH  Modellierung von Funktion und Ablauf Funktion und Ablauf Aktivitätsmodelle = betrachtet die erforderlichen Funktionen des Systems, die Abhängigkeit zwischen diesen Funktionen und der Zusammenhang zwischen Ein- und Ausgaben von Funktionen Prozessmodelle © ReqPOOL GmbH  Modellierung von Funktion und Ablauf Aktivitäts- und Prozessmodelle AKTIVITÄTSMODELLE PROZESSMODELLE = repräsentieren die erforderlichen = repräsentieren die technischen Funktionen des betrachteten Prozesse oder Geschäftsprozesse Systems Aktivitätsdiagramme oder Aktivitätsdiagramme Diagramme der BPMN Use-Case-Diagramme, Datenflussdiagramme © ReqPOOL GmbH Modellierung von Funktion und Ablauf UML - Aktivitätsdiagramm AKTIVITÄTSDIAGRAMM PROBLEM Abläufe, z.B. Geschäftsprozesse müssen modelliert werden. Im Vordergrund steht dabei eine Aufgabe, die in Einzelschritte zerlegt werden soll → Details eines Use Cases werden festgelegt Geeignet zur Modellierung von Abläufen Betrachtung des Kontrollfluss zwischen Aktionen des Systems Sequenziellen Abfolge von Aktionen © ReqPOOL GmbH 176  Modellierung von Funktion und Ablauf Notationselemente von Aktivitätsdiagramme AKTIONSKNOTEN © ReqPOOL GmbH  Modellierung von Funktion und Ablauf Beispiel eines Aktivitätsdiagramms © ReqPOOL GmbH Erklärvideo - Ablaufdiagramm  Modellbasierte Arbeitsergebnisse MODELLIERUNG VON STRUKTUR UND DATEN MODELLI