Requirements Engineering für Dummies

Dr. Marcus Winteroll ist Mitglied der oose Innovative Informatik eG, einem Anbieter von Schulungen und Workshops zu Software & Systems Engineering in Hamburg. Als Trainer und Berater beschäftigt er sich mit der Analyse sowie Verbesserung von Geschäfts- und Entwicklungsprozessen. Dazu setzt er auf agile Methoden; aber auch die klassischen Vorgehensweisen sind ihm aus seiner langjährigen Erfahrung als Requirements Engineer, Projektleiter, Prozessmanager, Qualitätssicherer und Entwickler vertraut. Seine gesammelten Erfahrungen teilt er auf Konferenzen und als Autor von Fachartikeln.

• Über den Autor 13Einleitung 25Über dieses Buch 25Konventionen in diesem Buch 26Was Sie nicht lesen müssen 26Törichte Annahmen über die Leser 26Wie dieses Buch aufgebaut ist 26Teil I: Requirements Engineering verstehen 27Teil II: Vorgehen im Requirements Engineering 27Teil III: Anforderungsanalyse 27Teil IV: Requirements Management 27Teil V: Der Top-Ten-Teil 27Symbole, die in diesem Buch verwendet werden 27Wie es weitergeht 28Teil I: Requirements Engineering verstehen 29Kapitel 1 Das ist Requirements Engineering 31Warum uns Requirements Engineering weiterhelfen kann 31Aufgaben im Requirements Engineering 34Wer das Requirements Engineering macht 36Der Requirements Engineer 37Wer sonst noch das Requirements Engineering macht 37Viele Arten von Anforderungen 38Funktionale Anforderungen 38Nichtfunktionale Anforderungen 39Randbedingungen 40Abstraktionsstufen von Anforderungen 41Möglichkeiten der Zertifizierung 42Zertifikate des IREB 43Zertifikate des IIBA 44PMI Professional in Business Analysis (PMI-PBA) 45Kapitel 2 Einbettung des Requirements Engineering 47Das Zusammenspiel mit den übrigen Beteiligten 47Die Kunden des Requirements Engineering 48Wer sonst noch so wichtig ist: die Stakeholder 48Die Basis vieler Anforderungen: die Geschäftsprozesse 49Das Anforderungsdokument: eines für alle? 50Requirements Engineering im klassischen Vorgehen: alles klar 52Was zu erwarten ist 52Was nicht zu erwarten ist 52Requirements Engineering in agilen Projekten: just in time 53Beliebte Missverständnisse beim agilen Requirements Engineering 53Was agiles Vorgehen vom klassischen unterscheidet 54Klassisch, agil, Festpreis, Aufwandspreis –nicht jede Kombination ist sinnvoll 56Klassisch und Festpreis 56Agil und Aufwandspreis 56Agil und Festpreis 57Klassisch und Aufwandspreis 57Alles im Überblick 57Kapitel 3 Fallstricke 59Was wir von den Kunden erwarten dürfen – und sie von uns 59Wer nimmt die Anforderungen auf? 60Der Projektleiter als Requirements Engineer 60Der Product Owner als Requirements Engineer 61Entwickler als Requirements Engineers 61Kunde und Nutzer als Requirements Engineers 62Die richtige Detaillierung von Anforderung 63Umgang mit Änderungen 64Dokumentation von Anforderungen 66Teil II: Vorgehen im Requirements Engineering 69Kapitel 4 Vorgehen in klassischen Projekten 71Einordnung in den Projektablauf 71Der Ablauf 73Kapitel 5 Vorgehen in agilen Projekten 77Direkte Kommunikation statt Dokumentation 78Der Wert gibt den Takt an 79Das Ziel immer vor Augen 80Die Vorbereitungsphase 80Requirements Engineering in Scrum 82Scrum kurz erklärt 82Wo das Requirements Engineering in Scrum stattfindet 84Das Product Backlog weiterentwickeln: Refinement 86Fertig heißt fertig: die Definition of Done 88Welche Rolle für die Anforderungen zuständig ist 89Wenn mehrere Teams an einem System arbeiten 90Fortwährende Analyse statt Änderungsmanagement 91Die Unterschiede zwischen klassischem und agilem Requirements Engineering 92Kapitel 6 Anpassung des Requirements-Engineering-Prozesses 93Einflussfaktoren 93Facetten des Requirements-Engineering-Prozesses 94Zeitfacette 95Zweckfacette 96Zielfacette 96Konfiguration des Prozesses 97Teil III: Anforderungsanalyse 99Kapitel 7 An die Anforderungen herankommen 101Stakeholderanalyse 102Stakeholder identifizieren 103Stakeholder verstehen 105Maßnahmen zur Einbindung der Stakeholder 110Zusätzliche Anforderungsquellen 111Anforderungen ermitteln 112Von geheimen und selbstverständlichen Anforderungen: das Kano-Modell 113Wer fragt, gewinnt: die Befragungstechniken 115Anforderungen gemeinsam erheben: Kooperationstechniken 121Schauen Sie genau hin: Beobachtungstechniken 123Systemarchäologie und der Blick zurück: artefaktbasierte Techniken 126Recycling im Requirements Engineering: die Wiederverwendung von Anforderungen 127Seien Sie kreativ: Entwurfs- und Ideenfindungstechniken 128Hypothesen bilden und ausprobieren 133Techniken, die Sie zusätzlich unterstützen 134Welche Technik Ihnen weiterhilft 135Konflikte und der Umgang damit 138Analyse von Konflikten 138Auflösung von Konflikten 139Kapitel 8 Was uns zu Beginn klar sein sollte 145Wohin soll die Reise gehen? Das Ziel klar vor Augen 145Auf die Verpackung kommt es an: der Produktkarton 147Alles auf einem Blick: das Product Vision Board 150Auf die Schnelle: das Fahrstuhlgespräch 152Den Überblick gewinnen 153Den Kontext des Systems verstehen 154Wie das System verwendet werden soll: Anwendungsfälle 156Der Überblick über die ganze Geschichte: Story Map 159Releases schneiden 164Werden Sie zum Minimalisten: das Minimale Marktfähige Release 164Von der Story Map zum Releaseplan 167Kapitel 9 Funktionale Anforderungen verstehen und beschreiben 175Die Systemverwendung mit Anwendungsfällen beschreiben 176Wer das System zu welchem Zweck verwendet: das Anwendungsfalldiagramm 178Anwendungsfälle Schritt für Schritt: Abläufe beschreiben 180Anwendungsfälle mit Anwendungsfällen erweitern 192Die Geschichten der Nutzer: User Stories 196Die Akzeptanzkriterien einer User Story 198Wie kleine User Stories große ersetzen 201Anwendungsfälle oder User Stories? 205Anwendungsfälle klassisch 205Von der Story Map über Anwendungsfälle zu den User Stories 205Kapitel 10 Weitere Aspekte funktionaler Anforderungen 209Fachliche Begriffe begreifen 210Alle wichtigen Begriffe auf einem Blick: das Glossar 210Der Zusammenhang zwischen den fachlichen Gegenständen im Fachklassenmodell 212Das sind ja Zustände 220Die Zustände fachlicher Gegenstände 220Das System bekommt Zustände 225Wie das Geschäft zu regeln ist 232Prototypen 243Die natürliche Sprache 247Man kann nicht alles verstehen 248Tipps zum Umgang mit der Sprache 248Ein Bausatz für Sätze: Satzschablonen 250Die Sprache und nichts als die Sprache 254Kapitel 11 Nichtfunktionale Anforderungen und Randbedingungen 257Die Bedeutung der nichtfunktionalen Anforderungen 258Nichtfunktionale Anforderungen verstehen 260Nichtfunktionale Anforderungen ermitteln 265Nichtfunktionale Anforderungen in der agilen Entwicklung 270Was schon vorher feststeht: die Randbedingungen 273Kapitel 12 Wer weiß, ob das auch so stimmt – Anforderungen prüfen 277Was gibt es denn da zu prüfen? 278Vorgehen im klassischen Requirements Engineering 279Qualitätskriterien zur Verifikation und Validierung 279Vorgehen im agilen Requirements Engineering 281Techniken für die Prüfung 282Reviewtechniken 282Explorative Validierungstechniken 284Prinzipien der Überprüfung 286Kapitel 13 Anforderungen festhalten 289Zweck der Dokumentation 289Der richtige Zeitpunkt 292Hilfreiche Regeln 294Arten der Dokumentation 295Dokumente 296Modelle 302Anforderungssammlungen im Requirements-Management-Tool 304Product Backlog 305Story Map 306Formularvorlagen für Anforderungen 306Teil IV: Requirements Management 309Kapitel 14 Anforderungen organisieren 311Requirements Management im agilen Vorgehen 312Der Lebenszyklus einer Anforderung 314Versionierung 316Attribute einer Anforderung 317Kann man so oder so sehen: Sichtweisen 318Konfigurationen 320Kapitel 15 Ist das wirklich wichtig? – Priorisierung von Anforderungen 323Was wichtig ist 324Ad-hoc-Priorisierungstechniken 325Priorisierung mittels Stufen 325Ranking 326Top-Ten-Technik 326Kauf dir ein Feature 326Analytische Priorisierungstechniken 327Wiegers’sche Priorisierungsmatrix 327Kano-Modell 330Vorgehen 330Kapitel 16 Die Anforderungen verfolgen 333Zweck der Verfolgbarkeit 333Verfolgbarkeit darstellen 335Methodisches Verfolgen 338Kapitel 17 Umgang mit Änderungen 341Ganz normal und doch unbeliebt 341Der Änderungsprozess und seine Bestandteile 342Kapitel 18 Werkzeuge im Requirements Engineering: Unterstützung und Last 347Arten von Werkzeugen 348Office-Tools 348Requirements-Management-Tools 349Modellierungstools 350Was schon da ist: Bugtracker und Wiki 351Lowtech-Tools 351Kombinationen von Tools 352Einführung von Werkzeugen 352Teil V: Der Top-Ten-Teil 355Kapitel 19 Zehn Prinzipien des Requirements Engineering 357Zusammenarbeit: Requirements Engineering allein funktioniert nicht 357Wertorientierung: Anforderungen sind kein Selbstzweck 358Stakeholder: Es geht darum, ihren Bedarf zu erfüllen 358Gemeinsames Verständnis: Die Basis für erfolgreiche Systementwicklung 358Kontext: Notwendig, um Systeme zu verstehen 359Problem, Anforderung, Lösung: Eine untrennbare Verbindung 359Validierung: Ungeprüfte Anforderungen sind nutzlos 360Evolution: Änderungen sind normal 360Innovation: Mehr vom Gleichen reicht nicht 361Systematische und disziplinierte Arbeit: Ohne geht es nicht 361Kapitel 20 Zehn beliebte Fehler im Requirements Engineering 363Die Suche nach dem Schuldigen 363Lösungen beschreiben anstatt Probleme zu verstehen 364Anforderungen einfach vom Altsystem übernehmen 364Die Nutzer beschreiben die Anforderungen 364Wir arbeiten agil und dokumentieren nichts 365Entweder keine oder unverständliche Systemdokumentationen 365User Stories sind allein dazu da, die bestehenden Anforderungen in das Backlog aufzunehmen 365Agil und Modellierung geht nicht zusammen 366Fachleute und Entwickler sprechen nicht miteinander 366Das Requirements Engineering läuft nicht, also brauchen wir ein Tool 366Kapitel 21 Zehn Online-Quellen 369IREB-Lehrpläne, Handbücher und Glossar 369Requirements Engineering Magazine 369Scrum-Guide 369Online Browsing Platform der ISO 370V-Modell 370UML-Spezifikation 370UML-Übersicht 371DMN-Spezifikation 371Übersicht über Requirements-Tools 371Übersicht über UML-Tools 371Stichwortverzeichnis 375