Requirements Engineering für die agile Softwareentwicklung

Book description

  • Erstes deutsches Buch, das sich der Kombination agiles und klassisches RE widmet Thema wird zurzeit heftig diskutiert auf Konferenzen, Blogs mit eindrücklichen Beispielen aus der Praxis für pragmatische Lösungen* Autor in der Welt der (klass.) Qualitätssicherung/Testen sehr bekannt

Table of contents

  1. Cover
  2. Title
  3. Impressum
  4. Vorwort
  5. Danksagung
  6. 1 Einleitung
    1. 1.1 Das Agile Manifest
    2. 1.2 Requirements Engineering im Kontext des Agilen Manifests
    3. 1.3 Scrum im Überblick
    4. 1.4 Ein Blick auf das große Ganze
    5. 1.5 Die fünf Grundprinzipien des Requirements Engineering in der agilen Softwareentwicklung
      1. Grundprinzip 1: Späte Detailspezifikation
      2. Grundprinzip 2: Umsetzungsdetails bleiben draußen!
      3. Grundprinzip 3: Risiko und zeitlicher Abstand zur Umsetzung steuern Detailgrad
      4. Grundprinzip 4: Effizienz im Requirements Management
      5. Grundprinzip 5: Änderungen akzeptieren und konsistent umsetzen
    6. 1.6 Umfang des Requirements Engineering – agil vs. klassische Softwareentwicklung
  7. 2 Requirements-Engineering-Rollen
    1. 2.1 Product Owner
      1. 2.1.1 Der Product Owner als Stellvertreter des Kunden im Team
      2. 2.1.2 Schwierige Ausprägungen von Product Ownern
        1. Der Visionär
        2. Der Teilzeit-Product-Owner
        3. Der Product Owner Proxy
    2. 2.2 Agiles Entwicklungsteam
      1. 2.2.1 Das Entwicklungsteam als Umsetzer und Berater des Product Owner
      2. 2.2.2 Schwierige Ausprägungen im Entwicklungsteam
        1. Der Supergenaue
        2. Der Hacker
    3. 2.3 Agile Master
      1. 2.3.1 Der Agile Master als Coach und Problemlöser
      2. 2.3.2 Schwierige Ausprägungen von Agile Master
        1. Der geheime Projektleiter
        2. Die agile Mimose
    4. 2.4 Tester
      1. 2.4.1 Der Tester als Prüfer und Qualitätsberater
      2. 2.4.2 Schwierige Ausprägungen von Testern
        1. Der Perfektionist
    5. 2.5 Architekt
      1. 2.5.1 Der Architekt als Berater für das Gesamtsystem
      2. 2.5.2 Schwierige Ausprägungen von Architekten
        1. Der Generalisierer
    6. 2.6 Produktmanager
      1. 2.6.1 Der Produktmanager als Dirigent mehrerer Teams
      2. 2.6.2 Schwierige Ausprägungen von Produktmanagern
        1. Der »Über den Zaun Werfer«
        2. Der »Technisch gebildete Produktmanager«
  8. 3 Qualität von Requirements
    1. 3.1 Qualitätskriterien für Requirements
      1. 3.1.1 Qualitätskriterien nach IEEE 830-1998 und IREB
      2. 3.1.2 INVEST-Qualitätskriterien
    2. 3.2 Definition of Done (DoD)
    3. 3.3 Definition of Ready (DoR)
    4. 3.4 Review von Requirements
      1. Review beim Einfügen ins Backlog
      2. Review im oder vor der Sprint-Planung
      3. Review im oder vor dem Sprint-Review-Meeting
      4. Sonstige Reviews im Projektverlauf
  9. 4 Requirements-Ermittlung und Dokumentation
    1. 4.1 Übergeordnete Artefakte
      1. 4.1.1 Vision und Goals (Ziele)
      2. 4.1.2 Epics
        1. Business Epics
        2. Architectural Epics
        3. Eigenschaften von Epics
      3. 4.1.3 Systemkontext
      4. 4.1.4 Stakeholder
      5. 4.1.5 Personas
    2. 4.2 Geschäftsprozesse und Systemverhalten
      1. 4.2.1 Prozesse
      2. 4.2.2 Use Cases
        1. Use-Case-Diagramm
        2. Use-Case-Beschreibung
      3. 4.2.3 Use-Case-Szenario
        1. Szenario-Standardablauf: Urlaub eintragen:
        2. Szenariovariante – »Arztbesuch«
        3. Szenario-Sonderfall – »Sonstige Fehlzeit«
    3. 4.3 Funktionale und nicht funktionale Sicht
      1. 4.3.1 Features
      2. 4.3.2 User Stories
        1. Nicht funktionale User Stories?
        2. Technische User Stories?
      3. 4.3.3 User Constraints
        1. 4.3.3.1 Nicht funktionale Anforderungen
          1. Funktionalität
          2. Effizienz
          3. Kompatibilität
          4. Benutzbarkeit (Usability)
          5. Zuverlässigkeit
          6. Informationssicherheit (Security)
          7. Portierbarkeit
          8. Skalierbarkeit
          9. Sicherheit der Anwender (Safety)
          10. Dokumentation
        2. 4.3.3.2 Rahmenbedingungen
    4. 4.4 Benutzerschnittstelle
      1. Wireframes
      2. Sketchy UI/Sketches
      3. Finales UI
      4. Szenariobasierte UI-Spezifikation:
      5. Hinweise zur GUI-Spezifikation:
    5. 4.5 Systemschnittstelle
    6. 4.6 Entwicklersicht
      1. 4.6.1 Spikes
      2. 4.6.2 Architektur und technisches Design
      3. 4.6.3 Developer Story
      4. 4.6.4 Softwareszenarien
      5. 4.6.5 Developer Constraints
        1. 4.6.5.1 Nicht funktionale Anforderungen (NFA)
          1. Wartbarkeit
          2. Skalierbarkeit
          3. Sicherheit (des Systems, Security)
          4. Sicherheit (der Anwender, Safety)
          5. Dokumentation
        2. 4.6.5.2 Rahmenbedingungen
      6. 4.6.6 Tasks
    7. 4.7 Inhaltliche Strukturierungshilfsmittel
      1. 4.7.1 Themen
      2. 4.7.2 Epics und Features
    8. 4.8 Agile Requirements-Engineering-Methoden
      1. 4.8.1 Specification by Example
      2. 4.8.2 Test Driven Development
      3. 4.8.3 Behaviour Driven Development
        1. Exkurs Entscheidungstabelle:
  10. 5 Requirements-Analyse
    1. 5.1 Machbarkeitsanalyse
      1. 5.1.1 Technische und funktionale Analyse mit Spikes
      2. 5.1.2 Organisatorische und personelle Machbarkeit
    2. 5.2 Analyse von Nutzen und Geschäftswert
      1. 5.2.1 Messung des Nutzens
      2. 5.2.2 Das Kano-Modell
      3. 5.2.3 Ordnung nach relativem Nutzen
      4. 5.2.4 Abstrakter Geschäftswert (Business Value)
    3. 5.3 Risikobewertung
      1. 5.3.1 Risiken identifizieren und bewerten
      2. 5.3.2 Maßnahmen planen
      3. 5.3.3 Risiken überwachen und steuern
    4. 5.4 Analyse der Qualität der Anforderungen
    5. 5.5 Aufwands- und Kostenschätzung
      1. 5.5.1 Aufwandsschätzung in klassischen Projekten
      2. 5.5.2 Prinzipien agiler Schätzungen
      3. 5.5.3 Schätzen im Projektverlauf
        1. Frühe Grobschätzung zur Priorisierung
        2. Genauere Schätzung für die Iterationsplanung
      4. 5.5.4 Schätzmethoden
        1. Grobschätzung mit T-Shirt-Sizing
        2. Schätzung mit Story Points und Planning Poker
        3. Schätzung in Personentagen, Function Points etc.
      5. 5.5.5 Ermitteln von Aufwand und Kosten aus Story Points
        1. Referenzaufwand ermitteln und Hochrechnen
        2. Ermittlung der Umsetzungszeit je Story Point aus der Velocity
    6. 5.6 Priorisierung
      1. 5.6.1 Prioritätsskala
        1. Einteilung in Prioritätsklassen
        2. Fortlaufende Nummerierung
      2. 5.6.2 Basis für die Priorisierung
        1. Eindimensionale Priorisierung
        2. Priorisierung nach mehreren Dimensionen
  11. 6 Requirements Management
    1. 6.1 Inhalt vs. Verwaltung des Inhalts
    2. 6.2 Planung
      1. 6.2.1 Portfolio- und Programmplanung
        1. Planungsvoraussetzungen
        2. Planungsfokus
        3. Aufwand und Umfang
        4. Ergebnis des Portfolio- und Programmplanungsprozesses
      2. 6.2.2 Systemplanung
        1. Mindestvoraussetzung für die Systemplanung
        2. Planungsfokus und Aufgaben in diesem Planungsschritt:
        3. Aufwand und Umfang
        4. Ergebnis des Planungsprozesses auf Systemebene
      3. 6.2.3 Releaseplanung
        1. Mindestvoraussetzung für die Releaseplanung
        2. Planungsfokus und Aufgaben in diesem Planungsschritt
        3. Aufwand und Umfang
        4. Ergebnis des Planungsprozesses auf dieser Ebene
      4. 6.2.4 Sprint-Planung
        1. Mindestvoraussetzung für die Sprint-Planung
        2. Planungsfokus und Aufgaben in diesem Planungsschritt:
        3. Aufwand und Umfang
        4. Ergebnis des Planungsprozesses auf dieser Ebene
      5. 6.2.5 Daily Meeting
    3. 6.3 Backlog
    4. 6.4 Story Maps
      1. 6.4.1 Listenbasierte Requirements-Verwaltung
      2. 6.4.2 Story-Card-basierte Requirements-Verwaltung
        1. Inhaltliche Gliederung
        2. Ergänzung um Planungssicht
        3. Requirements-Handling in Story Maps
    5. 6.5 Taskboard
  12. 7 Rechtliche Themen
    1. 7.1 Allgemeine rechtliche Aspekte
    2. 7.2 Vertragsbasis und Vertragserfüllungspflicht
    3. 7.3 Gewährleistung
    4. 7.4 Agile Vorgehensweisen und Festpreis
      1. Vertragsvereinbarungen bei Festpreisen
    5. 7.5 Das Vier-Stufen-Modell für agile Festpreisprojekte
      1. 7.5.1 Stufe 1: Definition der Projektziele und ersten Kundenanforderungen
      2. 7.5.2 Stufe 2: Agiles Erstellen der Vertragsbasis
      3. 7.5.3 Stufe 3: Festpreisangebot durch den Lieferanten
      4. 7.5.4 Stufe 4: Agile Projektabwicklung
    6. 7.6 Öffentliche Ausschreibungen
      1. Welcher Lieferant wird nun die Ausschreibung gewinnen?
    7. 7.7 Haftung des Teams
    8. 7.8 Standards und Normen
      1. Sicherheitskritische Entwicklung
    9. 7.9 Absicherung des Auftraggebers
      1. Mehr spezifizieren und Risikoanalyse durchführen
      2. Mehr und risikobasiert Testen
    10. 7.10 Absicherung des Lieferanten
      1. Alle relevanten Prozessthemen berücksichtigen
      2. Bei »Prozesslücken« an anerkannten Standards orientieren
      3. Relevante Kommunikation dokumentieren
      4. Erfahrene Personen zur Prozesssteuerung einsetzen
  13. Anhang
    1. A Abkürzungen
    2. B Glossar
    3. C Literatur
    4. Index

Product information

  • Title: Requirements Engineering für die agile Softwareentwicklung
  • Author(s): Johannes Bergsmann
  • Release date: June 2014
  • Publisher(s): dpunkt
  • ISBN: 97833864901492