Requirements Engineering Kurz und knapp. GI Informatiktage, 20. März 2015 Prof. Dr. Christof Ebert, Vector Consulting Services

Transkript

1 Requirements Engineering Kurz und knapp GI Informatiktage, 20. März 2015 Prof. Dr. Christof Ebert, Vector Consulting Services

2 Referent: Dr. Christof EBERT Dr. Christof Ebert ist Geschäftsführer der Vector Consulting Services GmbH. Er unterstützt Unternehmen weltweit bei der Verbesserung ihrer Produktentwicklung und Produktstrategie sowie im Veränderungsmanagement. Zuvor war er zehn Jahre in internationalen Führungsfunktionen für Alcatel tätig, zuletzt mit weltweiter Verantwortung für Software-Plattformen. Er sitzt in verschiedenen Aufsichtsgremien, ist Professor an der Universität Stuttgart und ist Autor des deutschsprachigen Standardwerks Systematisches Requirements Engineering. 2/49

3 Vector Consulting Services unterstützt Kunden weltweit bei der Optimierung ihrer Produkt- Entwicklung und IT sowie mit Interim-Management mit Kunden wie Accenture, Audi, BMW, Bosch, Daimler, Hyundai, IBM, Lufthansa, Munich RE, Porsche, Siemens, Thales, Vodafone, und ZF bietet mit der Vector Gruppe ein Portfolio aus Werkzeugen, Softwarekomponenten und Dienstleistungen ist als Gruppe weltweit vertreten mit über 1300 Mitarbeitern und einem Umsatz von über 250 Mio. Luftfahrt & Verteidigung Energie & Umwelt Bahn & Transport Automobilindustrie IT Medizin & Gesundheit 3/49

4 Motivation und Grundlagen Systematisches Requirements Engineering Werkzeugunterstützung Zusammenfassung und Ausblick Das Problem vieler Unternehmen ist, dass zu viele Features verkauft werden, und zu wenig Wert. Christof Ebert 4/49

5 Requirements = Innovation + Wert 5/49

6 Innovationsmanagement Aktuelle Beispiele Smarte Lösungen Produkte passen sich an sich ändernde Umgebung und Nutzung an Smarte Vernetzung Software, Mechanik und Elektronik schaffen neue Technologien, Geschäftsmodelle und Arbeitsweisen Smarte Umgebungen Kooperierende Systeme kommunizieren miteinander und tauschen Informationen aus Smarte Produktionssysteme Flexible Produktionssysteme ermöglichen ressourceneffiziente Produktion und individuelle Produkte 6/49

7 Innovationsmanagement Chancen und Risiken Chancen und Risiken Galaxy S Galaxy S2-20 Millionen - 40 Millionen Galaxy S3-50 Millionen Galaxy S4 Galaxy S5-100 Millionen - 11 Mio im ersten Monat Am 25. Mai 2012 dockt SpaceX Dragon als erstes kommerzielles Raumschiff an die ISS an Bei Apple sind wir bestrebt, Weltklasse-Produkte, mit der bestmöglichen Kundenerfahrung zu liefern. Mit dem Start unserer neuen Maps konnten wir diese Verpflichtung nicht halten. Die Frustration unserer Kunden tut uns sehr leid, und wir werden alles tun, um Maps besser zu machen. Tim Cook, CEO 7/49

8 Innovationsmanagement Wachsende Komplexität Objekt-Code in Tausend Statements Vermittlungssysteme Automobilelektronik Linux Kernel Heimautomatisierung Multifunktionsdrucker Raumfahrt, autonom, onboard Raumfahrt, bemannt, onboard Raumfahrt, Bodenkontrolle Quelle: Ebert 2013, Ebert/Jones /49

9 Externe Herausforderungen, Vector Kundenumfrage % 50% 40% Wichtig für eigenen Aufgabenbereich Konnektivität (z.b. PLM/ALM, Infrastruktur) Komplexitäts Management Innovative Produkte 30% 20% 10% 0% Verteilte Entwicklung Big Data Robuste Produkte Governance Andere Effizienz Kostenreduktion Wichtig für eigene Branche 0% 10% 20% 30% 40% 50% 60% Vector Kundenumfrage 2015 ; ; Summe > 100%, da 3 Antworten pro Frage erlaubt waren Evolution seit 2014: Komplexitäts-Management und Konnektivität haben dominierende Rolle, während 2014 der Fokus noch auf Kosten lag. 9/49

10 Hausgemachte Herausforderungen Hohe Wertschöpfung und hohes Geschäftsrisiko Erfolgsquote von Projekten Fehlende Transparenz Termin- und Kostenüberschreitungen Unzureichende Produktivität Nacharbeiten und Fehler Projekt- und Haftungsrisiken Demotivation und Burn-Out 18% Erfolgreich 43% 39% Hauptgründe für Projektprobleme Unzureichende Prozesse Unklare Verantwortungen Requirements Unzureichende Engineering Anforderungen Zu spät oder über Budget Abgebrochen und keine Zeit, für Verbesserungen Quellen Oben: Standish Group 2012, ca Projekte Unten: Standish Group, ObjectGroup, McKinsey, /49

11 Unzureichende Anforderungen haben Tradition Plötzlich ergab sich eine aufgeregte Diskussion zwischen dem König und seinem Lieferanten Der König verzichtete auf die üblichen Bestrafungen und hörte auf seine Berater. Er verstand, dass er Teil des Problems ist. Er stimmte zu, dass eine nachhaltige Lösung Veränderungen auf beiden Seiten braucht. Requirements Engineering wurde eingeführt. 11/49

12 Die drei wesentlichen Risiken auch für Sie 1 Fehlende Anforderungen Relevante Stakeholder nicht involviert Unklarer Bedarf und Nutzen, kritische Anforderungen übersehen 2 Falsche Anforderungen Vermischung von Bedarf (Was?, Warum?) und Lösung (Wie?) Handwerkliche (Lücken, Inkonsistenzen) und methodische Fehler (Prioritäten) 3 Sich ändernde Anforderungen Unbekannte oder unzureichende Basis Fehlendes Änderungsmanagement Basiert auf: B.Lawrence, K.Wiegers and C.Ebert: The Top Risks of Requirements Engineering. IEEE Software, Vol. 18, No. 6, pp , Nov /49

13 Beispiel: Falsche Anforderungen reduzieren den Wert Welche Funktionen werden als nützlich betrachtet und verwendet? Manchmal 16% Selten 19% Oft 13% Immer 7% Nie 45% Quellen: Standish Group, Ebert 2014 (mit Beispielen aus Automotive, Bahn, IT) 16/49

14 Beispiel: Unzureichende Anforderungen und die Konsequenzen Unklare Anforderungen Ungenügende Analyse und Spezifikation Anforderungsänderungen Unrealistische Pläne und Vereinbarungen Termindruck Terminverzug Fehler; fehlende Prüfung Unzureichende Qualität Demotivation; Frustration Nicht eingehaltene Kundenerwartungen 17/49

15 Eine Anforderung So viele Fragen REQ_0815 Die Stockwerkskonsole erlaubt den Ruf des Aufzugs in den Stockwerken. Die Konsole besteht aus zwei Ruftasten, mit denen die Auf- beziehungsweise Abwärtsrichtung signalisiert wird. Der Benutzer ruft den Aufzug durch das Drücken der Ruftaste. Die VIP-Funktion wird durch einen Schlüsselschalter aktiviert. Damit können Stockwerke bevorzugt angefahren werden. Bringt die Anforderung Kundennutzen und Umsatz? Sind die Inhalte relevant, oder nur eine Feature-Aufreihung? Kann die Anforderung gewinnbringend umgesetzt werden? Wie ist der Status der Anforderung? Wer ist für die Anforderung verantwortlich? Wie wird die Anforderung validiert? Wie wird die Anforderung umgesetzt? 18/49

16 Was ist eine Anforderung? Anforderung Eigenschaft oder Bedingung, die zur Problemlösung oder Zielerreichung erforderlich ist. Verschiedene Typen von Anforderungen; rekursiv anwendbar Marktanforderungen / Kunden- / Benutzer- / Geschäftsanforderungen / Ziele / Bedürfnisse Warum? Problemraum Produktanforderungen / Eigenschaften / SLA / Service- / Systemanforderungen Was? Lösungsraum Komponentenanforderungen / Software- /IT-Anforderungen Wie? 19/49

17 Was ist Requirements Engineering? Requirements Engineering Diszipliniertes und systematische Vorgehen zur Ermittlung, Dokumentation, Analyse, Abstimmung, Prüfung und Verwaltung von Anforderungen unter kundenorientierten, technischen und wirtschaftlichen Vorgaben. Requirements Engineering Ermittlung Analyse Abstimmung Dokumentation Prüfung Verwaltung 20/49

18 Requirements Engineering im Kontext Requirements Engineering Projektmanagement Die Aufgabe verstehen Die Aufgabe planen und organisieren Die Aufgabe ausführen Entwicklung, Betrieb 21/49

19 Wertorientiert: Anforderungen entwickeln statt sammeln Verstehe Bedürfnisse und Kaufkriterien Vertrieb, Marketing Sichere und verbessere den Wert Produktmanagement, Entwicklung Wert für Markt Entwickle und liefere Wert Marketing, Vertrieb Schaffe und kommuniziere Wert Entwicklung, Produktmanagement 22/49

20 Erfolgsorientiert: Wert für Markt und Unternehmen optimieren Wert Realistischer Zielbereich: Ziele erreicht Leistungsfaktoren verfehlt: Zu spät, zu teuer Over-Engineering: Zu spät, zu teuer Aufwand 23/49

21 Flexibel: Methodik an Randbedingungen anpassen Anforderungen werden frühzeitig abgestimmt und Änderungen sind aufwändig Komplexität Anforderungen ändern sich häufig im Projekt Anforderungen werden im Projekt entwickelt. Großes Projekt Lange Lebensdauer Hoher Wartungsanteil Viele Varianten / Releases Mehrere Standorte / Lieferanten Wasserfallmodell, V-Modell Inkrementelle Entwicklung Prototyping, evolutionär Kleines Projekt Kurze Lebensdauer Ein Standort Agile Prozesse Unsicherheiten Anforderungen stabil Wenig Kundeneinfluss Anforderungen volatil, unbekannt Starke Kundenbeteiligung 24/49

22 Nutzen von Requirements Engineering Kundenzufriedenheit Projektmanagement Lieferantensteuerung Kostenreduzierung Qualität, weniger Nacharbeit Effizienz Wiederverwendung Absicherung Projektkosten Zielwert 20-40% Effizienz- Potenzial durch RE Zusatzkosten und Zeitverzug durch unzureichendes RE gutes RE Projektzeit Requirements Engineering der wesentliche Erfolgsfaktor. Quelle der Zahlen: Ebert 2014, Standish Group 2009, Institut für angewandte Informatik Karlsruhe 2005, IAG Business Analysis Benchmark 2008 (103 Unternehmen, durchschnittlich 3 Mio US$ Projektumfang) 25/49

23 Motivation und Grundlagen Systematisches Requirements Engineering Werkzeugunterstützung Zusammenfassung und Ausblick If I had eight hours to chop a tree, I would use six hours to sharpen the axe. Abraham Lincoln 26/49

24 Übersicht: Ermittlung Ermittlung Analyse Abstimmung Problem: Sammlung langer Feature-Listen ohne Bezug zum tatsächlichen Bedarf Dokumentation Verwaltung Prüfung Ziel: Systematisches Entwickeln von Anforderungen Viele Anspruchsträger Unterschiedliche Perspektiven Verschiedenen Arten von Anforderungen Wertorientierung: Basis-, Leistungs-, Begeisterungs-Faktoren Ergebnis: Vision Kontext Bedürfnisse und Erwartungen 27/49

25 Übersicht: Dokumentation Ermittlung Analyse Abstimmung Problem: Prosa-Texte und s, in denen sich niemand zurecht findet Dokumentation Verwaltung Prüfung Ziel: Klare Beschreibung aller Anforderungen Strukturierte und prüfbare Anforderungen Unterscheidung zwischen dem Bedarf (sog. Lastenheft), und der Realisierung (sog. Pflichtenheft) Missverständnisse vermeiden: Nur was klar beschrieben ist, wird auch richtig entwickelt Ergebnis: Dokumentierte gemeinsame Basis für alle Anspruchsträger Klare Beschreibung von Marktanforderungen, Produktanforderungen und Komponentenanforderungen Strukturierte Anforderungen mit allen relevanten Attributen 28/49

26 Übersicht: Modellierung und Analyse Ermittlung Analyse Abstimmung Problem: Projektstart ohne belastbare Basis Dokumentation Verwaltung Prüfung Ziel: Synthese einer Lösung Bewertung von Einflüssen, Abhängigkeiten, Unsicherheiten Vergleich alternativer Lösungsansätze, z.b. Beschaffung vs. Entwicklung vs. Wiederverwendung Produktperspektive, z.b. Qualitätsanforderungen, Komplexität, Varianz, Technische Schulden Schätzung der Aufwände und Kosten für Projekt und Betrieb Ergebnis: Bewertete Lösungsmodelle Antwort auf Ausschreibungen Aufwandschätzung 29/49

27 Übersicht: Prüfung Ermittlung Analyse Abstimmung Problem: Missverständnisse und Lücken führen zu aufwändigen Nacharbeiten Dokumentation Verwaltung Prüfung Ziel: Kontinuierliche Prüfung der Anforderungen Validierung ( doing the right things ) sichert frühzeitig ab, dass das spätere Produkt den angenommenen Wert bringt Verifikation ( doing things right ) sichert eine konsistente Qualität der Anforderungen und der folgenden Arbeitsergebnisse Ergebnis: Kontinuierliche Bewertung des Produkts aus Kundensicht Ausreichende Konfigurationsbasis für alle weiteren Arbeiten Arbeitsergebnisse mit richtiger Qualität Die Prüfung der Anforderungen hat den größten Nutzen aller Prüfschritte im Projekt 30/49

28 Übersicht: Abstimmung und Vereinbarung Ermittlung Analyse Abstimmung Problem: Jeder hat seine eigene Wahrnehmung davon, was zu tun ist Dokumentation Verwaltung Prüfung Ziel: Anforderungen werden gemeinsam abgestimmt Allocation Before Commitment : Nur nach der Zuweisung von Anforderungen zu einem konkreten Projekt oder Inkrement gibt es Verträge nach außen und Budget im Projekt Ergebnis: Gemeinsames Verständnis von Wert, Nutzen und Kosten Abgestimmte und priorisierte Anforderungen an das Projekt Professionelles Management von Risiken und Unsicherheiten Planungs- und Konfigurations-Basis als Single Source Start des formalen Änderungsmanagements Formaler Meilenstein für den Projektstart 31/49

29 Übersicht: Verwaltung Ermittlung Analyse Abstimmung Problem: Unkontrollierte Änderungen führen zu Terminverzug und explodierenden Kosten Dokumentation Verwaltung Prüfung Ziel: Systematisches Projektmanagement auf Basis der Anforderungen Projektfortschritt anhand erfüllter Anforderungen (Earned Value) Nachverfolgbarkeit der Anforderungen durch Verknüpfung mit wenigstens einem Arbeitspaket und Testfall Änderungen und neue Anforderungen durchlaufen ebenfalls die Ermittlung, Dokumentation, Analyse, Prüfung, Abstimmung Ergebnis Transparente Fortschrittsverfolgung Kontinuierliches Risikomanagement Diszipliniertes Änderungsmanagement Effiziente Nachverfolgbarkeit 32/49

30 Umsetzung: Systematisches Requirements Engineering Projektzusammenhänge Bedarf Vision Produkt Geschäftsprozesse Organisation Marktanforderungen Produktanforderungen Backlog Umsetzung Features, User Stories 33/49

31 Motivation und Grundlagen Systematisches Requirements Engineering Werkzeugunterstützung Zusammenfassung und Ausblick A Fool with a Tool Remains a Fool Anonymous 34/49

32 Weshalb Werkzeuge für das Requirements Engineering? Anforderungen von Hand Inkonsistenzen, Fehler, Nacharbeiten Ineffizienz Werkzeuge unterstützen das Requirements Engineering Klare Statuskontrolle im Projekt Konsistentes Änderungsmanagement Effiziente Verknüpfung zu anderen Projektergebnissen Einfaches Filtern anhand von Attributen Single Source für alle relevanten Anspruchsträger Werkzeugunterstützung schafft Systematik und Konsistenz, und damit Effizienz und Qualität im Projekt 35/49

33 Wesentliche Anforderungen an Requirements Werkzeuge # Ziel Methodik 1 Tabellarische Dokumentation alle Arten von Anforderungen und Randbedingungen Wie wird spezifiziert? Welche Informationen? Welche Dokumente? 2 Bilder, Texte, CAD, Code transparent einbetten Wie lassen sich heterogene Inhalte pflegen? 3 Kosten für Einführung und Betrieb Welche Techniken sind nötig? 4 Organisation von Anforderungen (Metadaten, Attribute, Inkrementplanung) 5 Kontrolle und Pflege von Abhängigkeitsbeziehungen (Design, Testfälle, Dokumentation) Wie filtere ich Anforderungen? Wie erreiche ich Konsistenz? 6 Workflow-Unterstützung Wie aktualisiere ich den Status? 7 Prüfmöglichkeiten, z.b. Konsistenz- und Vollständigkeitskontrolle 8 Hypertext-Links zur einfachen Navigation zwischen Arbeitsergebnissen (z.b. Anforderung zu Testfall) 9 Kontrolle von Baselines und Versionen (z.b. Versionen mit Zeitstempel, Produktlinien, Varianten) Welche Qualität ist nötig? Welche Ergebnisse? Wie wird navigiert? Wie werden Änderungen verwaltet? 10 Schutz der eigenen Urheberrechte und Innovationen Wie schütze ich meine IP? 11 Offline Nutzung Wie kann ich ohne Internet /Cloud arbeiten? 12 Kollaboration mit externen Benutzern Lassen sich Anforderungen verteilt pflegen? 13 Zugriff mit anderen Werkzeugen (Datenbanken, Notifikation, Reporterzeugung, Rechteverwaltung) Wie gut kooperiert das Werkzeug mit anderen Werkzeugen? 14 Kosten (Lizenzen, Hardware, Netzwerk, Einführung) Wie teuer ist die Einführung und Nutzung? 36/49

34 Verschiedene Arten von Werkzeugen Tool- Gattung Typische Nutzung Verwaltung (Text, Informationen, Status, Verweise etc.) Bewertung Leicht verfügbar und günstig. Nicht gebrauchstauglich für Bilder. Wikis Vielfältige Informationen, mehrere Nutzer. Leicht einsetzbar und günstig. Unhandlich und unübersichtlich über die Zeit. Spreadsheets Workflow- Tools Statusverfolgung, Informationen, mehrere Nutzer Einfach. Fokus auf Workflow und einfache Inhalte. Zwingt zu systematischem Arbeiten. Modellierungswerkzeuge Modellierung (Analyse, Design) und Code-Generierung; Unterstützung bestimmter Methoden und Notationen Sinnvoll für durchgängige Nutzung einer bestimmten Methode. Overhead bei vielen Text- Anforderungen und CRs. Benötigt eine klare Methodik. Spezielle Werkzeuge Spezifikation, Verwaltung von Anforderungen und weiteren Dokumenten (z.b. Specs, CRs, Testfälle). Mehrwert bei Kopplung verschiedener Werkzeuge. Aufwändig in Einführung und Nutzung. Sinnvoll für Workflow, Verknüpfungen, Nachverfolgung, kombinierte Bilder und Texte, PLM Einbindung. Datenmodell, Prozesse und Rollen vorab gut spezifizieren. Agile Cloud- Lösungen Verteilte agile Verwaltung von Anforderungen Verteilter Zugriff auf Anforderungen in agilen Umgebungen 37/49

35 Vergleich von Requirements-Engineering-Werkzeugen Hoch Polarion in-step Benutzererfahrung (Funktionalität, Benutzbarkeit, Preis-Leistungs- Verhältnis etc.) Contour Integrity PREEvision Enterprise Arch. DOORS Microsoft Office Rally Quality- Center Niedrig Niedrig Hoch Größe: Marktanteil Technologie, Preis Quelle: Vector Kundenerfahrungen, Ovum und Gartner. Detaillierte Werkzeugübersicht in C.Ebert: Systematisches Requirements Engineering, dpunkt, 5. Auflage, /49

36 Spreadsheet-Template für Requirements Einfache Basis für die wesentlichen Informationen Unterscheidung verschiedener Typen von Anforderungen Verknüpfung von Anforderungen Dokumentation von Status, Aufwandschätzung, Priorisierung Einfache Abbildung auf ein Inkrement und einen Testfall 39/49

37 Rollenoptimierte Ausschnitte bei DOORS 40/49

38 Konfigurierbare Benutzeroberfläche bei Integrity 41/49

39 Anforderungen in der Polarion ALM-Umgebung 42/49

40 Verknüpfung von Anforderungen und Design in PREEvision 43/49

41 Motivation und Grundlagen Systematisches Requirements Engineering Werkzeugunterstützung Zusammenfassung und Ausblick What you think about something can never be as good as what you know about something. Jean Paul Getty 44/49

42 10 Tipps für das praktische Requirements Engineering 1. Arbeiten Sie diszipliniert 2. Vereinbaren Sie klare Verantwortungen in einem Kernteam 3. Nutzen Sie standardisierte Vorlagen 4. Forcieren Sie ein systematisches Projektmanagement 5. Prüfen Sie alle Anforderungen und Änderungen 6. Entwickeln Sie nur auf Basis vereinbarter Anforderungen 7. Verfolgen Sie den Status der Anforderungen 8. Liefern Sie inkrementell mit priorisierten Anforderungen 9. Planen Sie frühzeitig den Übergang in den Betrieb 10. Verbessern Sie kontinuierlich Ihr Requirements Engineering 45/49

43 Wirtschaftlicher Nutzen Kundenzufriedenheit Tatsächliche Bedürfnisse werden systematisch umgesetzt Effizienz und Termintreue Weniger Missverständnisse und Nacharbeiten; Testbarkeit; weniger Informations-Überlast und Frustrationen Projektmanagement Transparenter Status, Liefertreue Lieferantensteuerung Rechtzeitig geklärte Anforderungen Wiederverwendung Kontrollierte Varianz Absicherung Risikomanagement, Haftungsrisiko Quelle: Ebert, Systematisches Requirements Engineering, /49

44 Trends im Requirements Engineering Märkte und Kundenverhalten Einflüsse auf das Requirements Engineering Greifbarer Nutzen Effizienz und Performanz Innovative Lösungen Globale Märkte und Wertschöpfung Vernetzung von Informationen Strategisch Wertorientierung Servicegetriebene Lösungen Virtuelles Unternehmen Operativ Lean Requirements Engineering Durchgängige Qualität Wissensmanagement 47/49

45 Requirements Engineering Praxis Systematisches Requirements Engineering Christof Ebert dpunkt.verlag, 450 Seiten 5. überarbeitete Auflage 2014 Chinesisch, 2013 Der Klassiker für den systematischen Umgang mit Anforderungen. Geschrieben von einem Praktiker für die Praxis einfach, verständlich und anwendbar! Dass der Autor sein Metier versteht, durfte ich in einem gemeinsamen Projekt hautnah erleben. Hans Leibbrand, COO, Thales 48/49

46 Sprechen Sie uns an Wir unterstützen Sie gerne! Tel Fax