Schweitzer Fachinformationen
Wenn es um professionelles Wissen geht, ist Schweitzer Fachinformationen wegweisend. Kunden aus Recht und Beratung sowie Unternehmen, öffentliche Verwaltungen und Bibliotheken erhalten komplette Lösungen zum Beschaffen, Verwalten und Nutzen von digitalen und gedruckten Medien.
1Einleitung und Motivation
1.1Fokus dieses Buches
1.1.1Zielgruppen
1.1.2Abbildung des Lehrplans IREB CPRE RE@Agile Primer
1.1.3Abbildung des Lehrplans IREB CPRE Advanced Level RE@Agile - Practitioner/Specialist
1.1.4Allgemeine Begriffseinordnung
1.2Verbindung zwischen RE und agilem Vorgehen
1.2.1Denkweisen und Werte im RE und agilen Vorgehen
1.2.2Zusammenhang zwischen RE und Agile
1.2.3Was ist RE@Agile
1.2.4RE im Kontext des Agilen Manifests
1.2.5Nutzen von RE im agilen Vorgehen
1.2.6Vorurteile und Probleme beim RE im agilen Umfeld
1.2.7Fallstricke bei RE@Agile
1.2.8Resümee
2Grundlagen
2.1Methodenüberblick
2.1.1Allgemeine agile Vorgehensweisen
2.1.2Scrum »in a Nutshell«
2.1.3Methoden zur Unterstützung des Requirements Engineering
2.2Requirements Engineering im agilen Umfeld
2.3Grundprinzipien des RE in der agilen Softwareentwicklung
2.4Umfang des Requirements Engineering
3Requirements-Ermittlung und -Dokumentation
3.1Ein kurzer Überblick
3.1.1Anforderungsarten
3.1.2Requirements-Dokumente vs. Product Backlog
3.1.3Granularität funktionaler Requirements
3.1.4Grafische Modelle und textuelle Beschreibungen
3.1.5Definition von Begriffen, Glossare und Informationsmodelle
3.1.6Akzeptanz- und Abnahmekriterien
3.1.7Definition of Ready & Definition of Done
3.1.8Prototyp vs. Inkremente
3.1.9Ermittlung
3.1.10Dokumentation
3.1.11Artefakte
3.1.12Ein Blick auf das große Ganze
3.2Übergeordnete Artefakte
3.2.1Zusammenhänge und Abhängigkeiten
3.2.2Vision und Ziele
3.2.3Systemgrenze und Kontext
3.2.4Stakeholder
3.2.5Epics
3.2.6Personas
3.3Geschäftsprozesse und Systemverhalten
3.3.1Prozesse
3.3.2Use Cases
3.3.3Use-Case-Szenario bzw. -Template
3.4Funktionale und nicht funktionale Sicht
3.4.1Features
3.4.2User Stories
3.4.2.1Schneiden, Aufteilen bzw. Gruppieren von User Stories
3.4.2.2Wann sollte man aufhören zu zerlegen?
3.4.2.3Nicht funktionale User Stories
3.4.2.4Technische User Stories
3.4.3Qualitätsanforderungen und Randbedingungen
3.4.3.1Qualitätsanforderungen
3.4.3.2Randbedingungen (Constraints)
3.4.3.3Abnahme und Backlog-Management
3.5Benutzerschnittstelle
3.5.1Wireframes
3.5.2Sketchy User Interface/Sketches
3.5.3Finales User Interface
3.5.4Szenariobasierte UI-Spezifikation
3.5.5Hinweise zur GUI-Spezifikation
3.6Systemschnittstelle
3.7Prototypen und Inkremente
3.8Entwicklersicht
3.8.1Spikes
3.8.2Architektur und technisches Design
3.8.3Developer Story
3.8.4Systemszenarien
3.8.5Developer Constraints
3.8.6Tasks
3.9Inhaltliche Strukturierungshilfsmittel
3.9.1Themes
3.9.2Epics und Features
4Requirements-Validierung und -Abstimmung
4.1Verfeinerung von Anforderungen
4.1.1Backlog Refinement
4.1.2Refinement-Meeting
4.2Machbarkeitsanalyse
4.2.1Technische und funktionale Analyse mit Spikes
4.2.2Organisatorische und personelle Machbarkeit
4.3Ermitteln von Geschäftswert und Nutzen
4.3.1Messung des Nutzens
4.3.2Das Kano-Modell
4.3.3Ordnung nach relativem Nutzen
4.3.4Abstrakter Geschäftswert (Business Value)
4.3.5MVP - Minimum Viable Product
4.3.6MMP - Minimum Marketable Product
4.4Risikobewertung
4.4.1Risiken identifizieren und bewerten
4.4.2Maßnahmen planen
4.4.3Risiken überwachen und steuern
4.5Aufwands- und Kostenschätzung
4.5.1Aufwandsschätzung in nicht agilen Softwareprojekten
4.5.2Prinzipien agiler Schätzungen
4.5.3Schätzen im Projektverlauf
4.5.4Schätztechniken
4.5.5Ermitteln von Aufwand und Kosten aus Story Points
4.6Bewertung der Qualität der Anforderungen
4.7Priorisierung
4.7.1Prioritätsskala
4.7.2Basis für die Priorisierung
5Qualität im Requirements Engineering
5.1Qualitätskriterien für Requirements
5.1.1Qualitätskriterien nach IEEE 830-1998 und IREB
5.1.1.1Qualitätskriterien für einzelne Anforderungen
5.1.1.2Qualitätskriterien für mehrere Anforderungen
5.1.2DEEP-Qualitätskriterien
5.1.3INVEST-Qualitätskriterien
5.2Definition of Ready (DoR)
5.2.1Definition of Ready für einen einzelnen Backlog-Eintrag
5.2.2Definition of Ready für eine übergreifende Prüfung
5.3Definition of Done (DoD)
5.4Review von Requirements
5.5Produktvalidierung
6Requirements Management
6.1Allgemeines
6.2Inhalt vs. Management des Inhalts
6.3Requirements-Management-Aktivitäten
6.4Planende Aktivitäten des Requirements Management
6.4.1Portfolio- und Programmplanung
6.4.2Produkt-Roadmap, Delivery Roadmap
6.4.3Produktplanung
6.4.4Releaseplanung
6.4.5Sprint-Planung
6.4.6Daily Scrum
6.5Artefakte für das Requirements...
Dateiformat: ePUBKopierschutz: Wasserzeichen-DRM (Digital Rights Management)
Systemvoraussetzungen:
Das Dateiformat ePUB ist sehr gut für Romane und Sachbücher geeignet - also für „fließenden” Text ohne komplexes Layout. Bei E-Readern oder Smartphones passt sich der Zeilen- und Seitenumbruch automatisch den kleinen Displays an. Mit Wasserzeichen-DRM wird hier ein „weicher” Kopierschutz verwendet. Daher ist technisch zwar alles möglich – sogar eine unzulässige Weitergabe. Aber an sichtbaren und unsichtbaren Stellen wird der Käufer des E-Books als Wasserzeichen hinterlegt, sodass im Falle eines Missbrauchs die Spur zurückverfolgt werden kann.
Weitere Informationen finden Sie in unserer E-Book Hilfe.
