Johannes Bergsmann hat technische Informatik studiert und arbeitete ca. 11 Jahre als Softwareentwickler, Projektleiter, Technischer Leiter, Architekt, Produktmanager und Berater in einem internationalen Systemhaus und als selbstständiger Unternehmer. Im März 2003 gründete er »Software Quality Lab« und begleitet seither als Berater und Trainer viele Unternehmen im Bereich Requirements Engineering und Prozessgestaltung.
Johannes Bergsmann ist zertifizierter Scrum Master, Sachverständiger für Informatik bei Gerichten, als Lehrbeauftragter an Fachhochschulen im Bereich Softwarequalitätsmanagement tätig, ist Autor vieler Fachartikel und hält Fachvorträge bei verschiedenen Veranstaltungen und Konferenzen.
Unter Mitwirkung von Markus Unterauer:
Markus Unterauer hat Wirtschaftsinformatik studiert. In seiner Berufspraxis war er in vielen Bereichen der Softwareentwicklung wie Architektur, Entwurf, Entwicklung, Testen, Testautomatisierung bis zu Deployment tätig. Er lernte dabei sowohl klassische als auch agile Projekte und Methoden intensiv kennen.
Seit 2012 arbeitet Markus Unterauer bei Software Quality Lab als Berater und Trainer. Er ist zertifizierter Scrum Master und hat sich auf die Bereiche Softwareprozesse und Anforderungsmanagement spezialisiert. Markus Unterauer ist auch als Vortragender in diesen Themenbereichen immer wieder auf Konferenzen tätig.
Zu diesem Buch – sowie zu vielen weiteren dpunkt.büchern – können Sie auch das entsprechende E-Book im PDF-Format herunterladen. Werden Sie dazu einfach Mitglied bei dpunkt.plus+: www.dpunkt.plus |
Methoden, Techniken und Strategien
Unter Mitwirkung von Markus Unterauer
2., überarbeitete und aktualisierte Auflage
Johannes Bergsmann
johannes.bergsmann@software-quality-lab.com
Markus Unterauer
markus.unterauer@software-quality-lab.com
Lektorat: Christa Preisendanz
Copy-Editing: Ursula Zimpfer, Herrenberg
Satz: Birgit Bäuerlein
Herstellung: Susanne Bröckelmann
Umschlaggestaltung: Helmut Kraus, www.exclam.de
Druck und Bindung: M.P. Media-Print Informationstechnologie GmbH, 33100 Paderborn
Bibliografische Information der Deutschen Nationalbibliothek
Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.
ISBN:
Print978-3-86490-485-1
PDF978-3-96088-189-6
ePub978-3-96088-190-2
mobi978-3-96088-191-9
2., überarbeitete und aktualisierte Auflage 2018
Copyright © 2018 dpunkt.verlag GmbH
Wieblinger Weg 17
69123 Heidelberg
Teile dieses Buches orientieren sich am Lehrplan RE@Agile des IREB e.V. Der Besitz und das Urheberrecht dieses Lehrplans und Studienleitfadens liegt bei IREB e.V. und den Autoren: Lars Baumann, Peter Hruschka, Kim Lauenroth, Markus Meuten, Sacha Reis, Gareth Rogers, Francois Salazar, Thorsten Weyer.
Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.
Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.
Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.
5 4 3 2 1 0
Als Berater habe ich in meiner bisherigen beruflichen Tätigkeit mehr als 200 verschiedene Projekte bei Kunden begleitet oder auch selbst in unterschiedlichen Rollen (Entwickler, Tester, Projektleiter, Architekt, Produktmanager, Analytiker, Coach, Berater etc.) mitgearbeitet. Viele dieser Projekte – vor allem in den letzten 15 Jahren – waren agile Projekte oder Projekte, in denen die Mitwirkenden zumindest versuchten, die agilen Prinzipien und Praktiken umzusetzen. Am erfolgreichsten und effizientesten waren fast immer diejenigen Projekte, bei denen agile Vorgehensweisen mit Elementen aus dem klassischen Requirements Engineering und Projektmanagement ergänzt und so die Stärken beider Bereiche genutzt wurden.
Requirements Engineering ist ein Aspekt, der in vielen agilen Vorgehensweisen nur sehr grob beschrieben wird. In der Begeisterung der ersten Stunde möchten viele Teams möglichst rasch starten und erste Erfolge zeigen und beginnen mit einem sehr intuitiven Ansatz, wie z.B. einer einfachen Liste von User Stories. User Stories sind eine sinnvolle Technik und ich baue in vielen Abschnitten dieses Buches auf dieser Technik auf. Es gibt jedoch noch viele andere Techniken aus dem Requirements Engineering, die in agilen Vorgehensweisen angewendet werden können und sollen. In Kombination mit einigen passenden, langjährig bewährten Techniken des Requirements Engineering bieten sie gute Lösungen für die Requirements-Herausforderungen in agilen Projekten.
Aus diesem Grund entschloss ich mich auch dazu, im Jahr 2014 die erste Auflage dieses Buches zu schreiben. Darin werden viele verschiedene Techniken und Methoden aus den agilen Vorgehensweisen vorgestellt, mit klassischen Methoden verknüpft und ergänzt und in einen strukturierten und systematischen Zusammenhang mit Requirements Engineering gebracht.
Mittlerweile sind einige Jahre vergangen und es wurde 2017 ein Lehrplan RE@Agile für eine Ausbildung des International Requirements Engineering Board (IREB®) herausgegeben, der die Lücke zwischen Requirements-Engineering-Methoden und agilen Methoden schließt. Sehr viele Inhalte dieses Lehrplans decken sich bereits mit der ersten Auflage dieses Buches und die Motivation hinter diesem Lehrplan ist dieselbe, wie sie hinter meinem Buch steht.
Daher waren eine Anpassung und Überarbeitung der ersten Auflage ein logischer und sinnvoller Schritt zur zweiten Auflage dieses Buches. Die Struktur und die Inhalte dieses Buches sind an den offiziellen Lehrplan des International Requirements Engineering Board (IREB®) angepasst. Damit bietet es den an dieser offiziellen Ausbildung und Zertifizierung Interessierten nun eine praxisnahe Vorbereitung und Lerngrundlage sowie noch viele ergänzende Inhalte, die über den Lehrplan hinausgehen.
Im Wesentlichen wurden folgende Abschnitte aufgrund des neuen IREB®-Lehrplans umfangreicher angepasst: Abschnitte 1.1 und 1.2, 2.1 und 2.2 sowie 3.1. Neu hinzugekommen ist Kapitel 7. Alle anderen Kapitel wurden durchgesehen und teilweise mit kleineren Überarbeitungen und Ergänzungen an aktuelle Erfordernisse angepasst und erkannte Fehler bereinigt. Zusätzlich zu inhaltlichen Anpassungen erfolgte auch eine grundlegende Umstellung der Reihenfolge der Kapitel, die sich nun ebenfalls weitgehend am Lehrplan des IREB® orientiert, sowie eine Umbenennung einzelner Kapitelüberschriften.
Ich freue mich, wenn dieses Buch für Sie als Anwender oder Experte in Ihrer täglichen Praxis Unterstützung und Anregung bietet und für Sie als Interessenten an der Schulung und Zertifizierung RE@Agile eine gute Informations- und Lerngrundlage ist.
Für die Weiterentwicklung dieses Buches hoffe ich auch auf zahlreiches Feedback und interessante Diskussionen (bitte direkt an johannes@bergsmann.com).
Johannes Bergsmann
Linz, im Februar 2018
Viele Projekte werden aus verschiedenen Gründen nicht so effizient und effektiv abgewickelt, wie dies möglich wäre: Zum Beispiel wenn die Fachexperten zwar wissen, dass sie mit den Entwicklern täglich kommunizieren sollten, dies jedoch nicht können,
Als Berater habe ich in meiner bisherigen beruflichen Tätigkeit mehr als 200 verschiedene Projekte bei Kunden begleitet oder auch selbst in unterschiedlichen Rollen (Entwickler, Tester, Projektleiter, Architekt, Produktmanager, Analytiker, Coach, Berater etc.) mitgearbeitet. Viele dieser Projekte – vor allem in den letzten 10 Jahren – waren agile Projekte oder Projekte, in denen die Mitwirkenden zumindest versuchten, Teile der agilen Prinzipien umzusetzen.
Am erfolgreichsten und effizientesten waren in dieser langen Zeit immer diejenigen Projekte, bei denen ich agile Vorgehensweisen mit Elementen aus dem klassischen Requirements Engineering und Projektmanagement ergänzte und so die Stärken jeder Methodik voll ausnutzen konnte.
Man könnte alle diese Softwareprojekte mit einer Autofahrt von München nach Rom vergleichen. Im Idealfall fahren wir auf gerader Strecke mit konstanter und optimaler Geschwindigkeit mit unserem Auto alleine auf der Straße. In der Praxis aber hat die Straße Kurven, es gibt Verkehrsbeschränkungen, in den Bergen ist eventuell auch Eis auf der Straße, es gibt Staus, andere Autofahrer, die rücksichtslos unterwegs sind und nur ihr eigenes Ziel im Blick haben, unser Auto hat eine Panne etc.
Auf alle diese individuellen Situationen sollten wir vorbereitet sein und unser Vorgehen den jeweiligen Situationen entsprechend anpassen, damit wir unser Ziel auch erreichen. Generell werden wir grob planend vorgehen, z.B. den Startzeitpunkt bestimmen, den ungefähren Zeitrahmen der Fahrt abschätzen und den Streckenverlauf z.B. für die Alpenquerung über den Brenner planen. Wir sollten auch ungefähr wissen, welches Wetter zu erwarten ist, und eventuell die Reifen, Frostschutz, Klimaanlage etc. entsprechend vorbereiten. Im Verlauf der Fahrt wird es vielleicht zu Änderungen kommen, z.B. wenn der Brennertunnel wegen eines Unfalls gesperrt ist. In diesem Fall werden wir agil darauf reagieren müssen und die Umleitungsstrecke über den Pass nehmen (schließlich haben wir ja Google Maps dabei ;-). Wenn wir im Vorfeld in der »Architektur« unseres Autos diese Situation mangels vorausschauender Planung nicht berücksichtigt haben und beim ersten kurzen Anstieg der Passstraße feststellen, dass wir ohne Ketten auf der verschneiten Straße nicht weiterkommen, müssen wir wiederum agil reagieren und nun eventuell einen großen Umweg über die Tauernautobahn nehmen. Beide Vorgehensweisen haben daher ihre Berechtigung. Als Softwareentwickler, Projektleiter, Agile Master, Product Owner – oder welche Rolle auch immer wir im Projekt inne haben – sollten wir viele unterschiedliche Methoden im Köcher haben und diese für unser Projekt zur optimalen Vorgehensweise kombinieren.
Das Agile Manifest [Agile Manifesto] (siehe Abschnitt 1.2) beschreibt in seinen vier agilen Leitsätzen und zwölf Prinzipien die Eckpfeiler, an denen sich praktisch alle agilen Vorgehensweisen orientieren. Darin wird unter anderem festgehalten, dass funktionierende Software und Zusammenarbeit mit dem Kunden wichtiger sind als umfassende Dokumentation und Vertragsverhandlungen, wobei im Zusatz angeführt ist, dass umfassende Dokumentation und Vertragsverhandlungen auch als wichtig angesehen werden. So sollten Projekte idealerweise ablaufen. Wenn man die Praxis in vielen Softwareprojekten erlebt hat, wird man dem Agilen Manifest begeistert zustimmen und die Aussage und Sichtweise uneingeschränkt unterstützen.
Ausgehend vom Agilen Manifest wurden verschiedene Vorgehensweisen entwickelt, z.B. Extreme Programming (XP) und Scrum. Diese Vorgehensweisen sind keine umfassenden Entwicklungsmodelle, sondern greifen bestimmte Aspekte und Themen auf und lassen andere Themen bewusst offen und unkonkret. Dies ermöglicht es und fordert gleichzeitig jedes Projektteam dazu auf, den konkreten Weg unter Berücksichtigung der Projektsituation und Rahmenbedingungen selbst zu finden und festzulegen.
Requirements Engineering ist ein Aspekt, der in vielen agilen Vorgehensmodellen nur sehr grob beschrieben wird. Aus diesem Grund habe ich mich auch dazu entschlossen, dieses Buch zu schreiben.
Sehr oft wurde und wird in verschiedenen Stadien eines Projekts das Requirements Engineering und Requirements Management zum Thema, z.B. wenn …
Alle diese geschilderten Fälle sind primär auf mangelndes Requirements Engineering und Requirements Management zurückzuführen. Tendenziell treten solche Probleme in Projekten auf, in denen ein Vorgehensmodell gewählt wurde, das viele thematische Freiheiten bietet, die offengelassenen Teile aber nicht vorab zwischen den beteiligten Personen festgelegt wurden oder das Modell nicht an die gegebene Situation angepasst wurde.
Gerade agile Vorgehensweisen überlassen die konkrete Ausgestaltung des Requirements Engineering zum Großteil der Entscheidung des Teams. In der Begeisterung der ersten Stunde möchten viele Teams möglichst rasch starten und erste Erfolge zeigen und beginnen mit einem sehr intuitiven Ansatz, wie z.B. einer einfachen Liste von User Stories. User Stories sind eine sinnvolle Technik, und ich baue in vielen Abschnitten dieses Buches auf dieser Technik auf. Es gibt jedoch noch viele andere Techniken aus dem Requirements Engineering, die in agilen Vorgehensweisen angewendet werden können und sollen. In Kombination mit einigen passenden klassischen Techniken des Requirements Engineering bieten sie gute Lösungen für die Requirements-Herausforderungen in agilen Projekten.
In diesem Buch werden daher viele verschiedene Techniken und Methoden aus den agilen Vorgehensweisen vorgestellt, mit klassischen Methoden verknüpft und ergänzt und in einen strukturierten und systematischen Zusammenhang mit Requirements Engineering gebracht.
Der Fokus dieses Buches liegt darauf, gute Methoden und Techniken – egal aus welchem Zeitalter oder mit welcher Ausrichtung – unvoreingenommen aufzugreifen und sie nicht von vornherein auszuschließen, nur weil es sich dabei um »klassische« oder »agile« Methoden oder Techniken handelt. Aussagen wie »klassische Methoden sind überfrachtet, ineffizient und schlecht« oder »agile Methoden sind was für Individualisten oder Dokumentationsfeinde« gehören für mich nicht zu einer weitsichtigen und nachhaltigen Denkweise.
Jede genannte Methode und Technik stellt ein Werkzeug im Werkzeugkasten der Softwareentwicklung dar und soll hier mit ihren Vorteilen und Nachteilen in bestimmten Projektsituationen betrachtet werden. Es soll klar werden, wo und wie diese Methoden und Techniken in agilen Projekten eingesetzt werden können, um einen Nutzen für das Projekt zu stiften. Es werden daher auch sinnvolle Anwendungsmöglichkeiten und Fallstricke der einzelnen Methoden und Techniken dargestellt und im Kontext eines nachhaltigen, systematischen und praxisorientierten Requirements Engineering in der agilen Softwareentwicklung betrachtet.
Ziel ist es, einen Überblick und einen Werkzeugkasten anzubieten, der zeigt, welche Methoden und Techniken zusätzlich zu den sehr oft angewendeten User Stories noch sinnvoll sind und welche Hindernisse und Problemstellungen im Zusammenhang mit Requirements Engineering in agilen Projekten auftreten können.
Abgerundet wird das Thema durch die Behandlung von Qualitätsaspekten für Requirements, durch einen Blick auf die Zusammenhänge und durch rechtliche Aspekte sowie durch Tipps und Tricks bei der Anwendung von Requirements-Themen im agilen Umfeld.
Das Buch richtet sich an Product Owner, Produktmanager, Projektmanager, Softwareauftraggeber, Scrum Master, Entwickler, Tester und alle anderen Personen, die sich mit nachhaltigem und systematischem Requirements Engineering und Requirements Management in der agilen Softwareentwicklung beschäftigen oder davon betroffen sind.
Dieses Buch ist keine komplette Einführung in agile Methoden. Kapitel 1 gibt zwar einen kurzen Überblick über das Agile Manifest, wesentliche agile Konzepte und Scrum, als am häufigsten eingesetzten Vertreter agiler Methoden. Der Hauptfokus des Buches liegt jedoch im Requirements Engineering und Requirements Management.
Hilfreich beim Lesen ist ein grundlegendes Verständnis des aktuellen Stands im Bereich Requirements Engineering und insbesondere die Kenntnis der allgemein anerkannten Begriffe, Techniken und Grundlagen aus diesem Themenbereich. Der Inhalt und die Begriffe, die das International Requirements Engineering Board [IREB] für die Ausbildung zum »Certified Professional for Requirements Engineering (CPRE) – Foundation Level« in seinem Lehrplan [IREB CPRE FL 2012] vorgibt, stellen den grundlegenden Stand der Technik zum Thema Requirements Engineering dar, der als Basiswissen für das Lesen dieses Buches empfohlen wird.
Das Buch soll Einführungslektüre sowie Praxisleitfaden sein und ist nicht als wissenschaftlich komplette Abhandlung über das Thema Requirements Engineering in der agilen Softwareentwicklung gedacht. Es kann daher sequenziell oder auch auszugsweise gelesen werden. Als Autor ist es mir natürlich am liebsten, wenn Sie dieses Buch ständig an Ihrem Arbeitsplatz griffbereit haben und bei Fragen oder Unklarheiten zu Requirements-Engineering-Techniken oder -Vorgehensweisen darin einen schnellen Rat und brauchbare Infos finden.
In der Praxis hat man leider oft nicht die Zeit, beim Auftauchen einer Frage ein ganzes Buch z.B. zu Use Cases, User Stories oder Behaviour Driven Development zu lesen. Ich habe daher auf eine möglichst große Unabhängigkeit der einzelnen Themen und Kapitel geachtet, sodass das Buch auch als Nachschlagewerk in der täglichen Arbeit verwendet werden kann. Mit entsprechendem Vorwissen in agilen Methoden und Requirements Engineering kann es auch auszugsweise gelesen und verstanden werden. Für Praktiker müssen das Wichtigste und die Zusammenhänge in Kürze ersichtlich sein. Daher gibt es in vielen Kapiteln eine tabellarische Übersicht über wesentliche Punkte und verschiedene Überblicksgrafiken, die die Zusammenhänge auf einen Blick darstellen.
Auch wenn in vielen Kapiteln Begriffe aus Scrum verwendet oder zitiert werden, so wurde darauf geachtet, die einzelnen Themenbereiche möglichst allgemeingültig zu halten. Das Buch adressiert nicht »Requirements Engineering in Scrum«, sondern behandelt generell das Thema Requirements Engineering im agilen Umfeld. Die beschriebenen Techniken und Methoden können auch in anderen agilen Vorgehensweisen angewendet werden.
Beispiele werden mit einem grauen Hintergrund versehen:
In diesem Buch werden verschiedene Beispiele und Formulierungen aus der Praxis und für die Praxis aufgeführt. Die meisten dieser Beispiele sind abgeleitet aus einem Projekt zum Thema »Zeiterfassung«. Es geht in diesem Beispielszenario darum, dass die Tagesarbeitszeiten inklusive der Pausen und Abwesenheitszeiten von Mitarbeitern eines Unternehmens erfasst, ausgewertet und verwaltet werden können und dass auch die Erfassung, Auswertung und Verwaltung von Projektarbeitszeiten durchgeführt werden kann – also von einzelnen Zeitblöcken der Tagesarbeitszeit, die bestimmten Projekten zugeordnet werden.
Weiterführende Literatur zum Thema Requirements und agile Vorgehensweisen ist im Anhang D zu finden.
Ich freue mich, wenn dieses Buch für Sie als Anwender oder Experte in Ihrer täglichen Praxis eine Unterstützung und Anregung ist. Für die Weiterentwicklung dieses Themas hoffe ich natürlich auch auf zahlreiches Feedback und interessante Diskussionen (bitte direkt an johannes.bergsmann@software-quality-lab.com).
Johannes Bergsmann
Linz, im April 2014
Mein großer Dank gilt Markus Unterauer, der mich als Koautor bei der Erstellung dieses Buches maßgeblich unterstützt hat. Markus hat primär die Kapitel 4 »Requirements-Validierung und -Abstimmung« und Kapitel 8 »Requirements-Engineering-Rollen« federführend ausgearbeitet und zum Kapitel 6 »Requirements Management« wesentliche Teile beigetragen sowie beim Review und Feinschliff des gesamten Buches viele gute Anregungen gegeben.
Des Weiteren danke ich allen Experten und Personen, mit denen ich im Laufe der letzten Jahre zum Thema Requirements Engineering und agile Methoden diskutieren durfte und die schlussendlich dazu beigetragen haben, dass ich mich zum Schreiben dieses Buches entschlossen habe und entsprechende Sichtweisen aus der Praxis mit einfließen lassen konnte.
Vielen Dank auch dem dpunkt.verlag – insbesondere Christa Preisendanz – für die initiale Anregung und für die wertvolle Unterstützung im Laufe der Ausarbeitung dieses Buches.
Und schlussendlich gilt ein ganz großer Dank meiner Frau Petra und meinen Kindern Beate und Barbara, die mich dadurch unterstützt haben, dass sie mir die Zeit zum Schreiben dieses Buches gegeben haben.
1Einleitung und Motivation
2Grundlagen
3Requirements-Ermittlung und -Dokumentation
4Requirements-Validierung und -Abstimmung
5Qualität von Requirements
6Requirements Management
7Organisatorische Aspekte
8Requirements-Engineering-Rollen
9Rechtliche Themen
Anhang
AAgile Methoden zur Unterstützung des Requirements Engineering
BAbkürzungen
CGlossar
DLiteratur
Index
1Einleitung und Motivation
1.1Über dieses Buch
1.1.1Zielgruppen
1.1.2Abbildung des Lehrplans IREB RE@Agile
1.1.3Allgemeine Begriffseinordnung
1.2Verbindung zwischen Requirements Engineering und agilem Vorgehen
1.2.1Mindsets und Werte im Requirements Engineering und agilem Vorgehen
1.2.2Requirements Engineering im Kontext des Agilen Manifests
1.2.3Nutzen von Requirements Engineering im agilen Vorgehen
1.2.4Vorurteile und Probleme beim Requirements Engineering im agilen Umfeld
1.2.5Fallstricke bei RE@Agile
1.2.6Resü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.3Die fünf Grundprinzipien des Requirements Engineering in der agilen Softwareentwicklung
2.4Umfang des Requirements Engineering
3Requirements-Ermittlung und -Dokumentation
3.1Allgemeines
3.1.1Requirements
3.1.2Ermittlung
3.1.3Dokumentation
3.1.4Spezifikationsdokumente vs. Product Backlog
3.1.5Granularität funktionaler Requirements
3.1.6Grafische Modelle und textuelle Beschreibungen
3.1.7Artefakte
3.1.8Definition von Begriffen, Glossare und Informationsmodelle
3.1.9Akzeptanz- und Abnahmekriterien
3.2Übergeordnete Artefakte
3.2.1Vision und Goals (Ziele)
3.2.2Epics
3.2.3Kontextmodelle
3.2.4Stakeholder-Liste
3.2.5Personas
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.3Nicht funktionale Anforderungen (NFA)
3.4.3.1 Qualitätsanforderungen
3.4.3.2 Randbedingungen (Constraints)
3.5Benutzerschnittstelle
3.5.1Wireframes
3.5.2Sketchy UI /Sketches
3.5.3Finales UI
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.1Themen
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.3Analyse von Nutzen und Geschäftswert
4.3.1Messung des Nutzens
4.3.2Das Kano-Modell
4.3.3Ordnung nach relativem Nutzen
4.3.4Abstrakter Geschäftswert (Business Value)
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 Projekten
4.5.2Prinzipien agiler Schätzungen
4.5.3Schätzen im Projektverlauf
4.5.4Schätzmethoden
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 von Requirements
5.1Qualitätskriterien für Requirements
5.1.1Qualitätskriterien nach IEEE 830-1998 und IREB
5.1.2DEEP-Qualitätskriterien
5.1.3INVEST-Qualitätskriterien
5.2Definition of Ready (DoR)
5.3Definition of Done (DoD)
5.4Review von Requirements
6Requirements Management
6.1Inhalt vs. Management des Inhalts
6.2Requirements-Management-Aktivitäten
6.3Planende Aktivitäten des Requirements Managements
6.3.1Portfolio- und Programmplanung
6.3.2Systemplanung
6.3.3Releaseplanung
6.3.4Sprint-Planung
6.3.5Daily Meeting
6.4Artefakte für das Requirements Management
6.4.1Backlog
6.4.2Story Maps
6.4.3Listenbasierte Requirements-Verwaltung
6.4.4Story-Card-basierte Requirements-Verwaltung
6.4.5Agiles Requirements-Board
6.4.6Taskboard
7Organisatorische Aspekte
7.1Einfluss der Organisation
7.2Agile Entwicklung im nicht agilen Umfeld
7.2.1Interaktion mit Stakeholdern außerhalb der Softwareorganisation
7.2.2Produkt- vs. Projektorganisation
7.2.3Die Rolle des Managements im agilen Kontext
7.3Der Umgang mit komplexen Problemen durch Skalierung
7.3.1Motivation für die Skalierung
7.3.2Ansätze für das Organisieren von Teams
7.3.3Ansätze für das Organisieren der Kommunikation
7.3.4Beispiel-Frameworks für das Skalieren von RE@Agile
7.3.5Auswirkungen der Skalierung auf RE@Agile
7.4Vorab- und kontinuierliche Aufgaben des Requirements Engineering im Zusammenhang mit Skalierung
7.4.1Initiale Requirements-Definition
7.4.2Detaillierungsgrad für Backlog Items
7.4.3Validität von Backlog-Einträgen
7.4.4Feedback zum Backlog und dessen Aktualisierung
7.4.5Zeitlicher Ablauf des Entwicklungszyklus
8Requirements-Engineering-Rollen
8.1Product Owner
8.1.1Der Product Owner als Stellvertreter des Kunden im Team
8.1.2Schwierige Ausprägungen von Product Ownern
8.2Agiles Entwicklungsteam
8.2.1Das Entwicklungsteam als Umsetzer und Berater des Product Owners
8.2.2Schwierige Ausprägungen im Entwicklungsteam
8.3Agile Master
8.3.1Der Agile Master als Coach und Problemlöser
8.3.2Schwierige Ausprägungen von Agile Master
8.4Tester
8.4.1Der Tester als Prüfer und Qualitätsberater
8.4.2Schwierige Ausprägungen von Testern
8.5Architekt
8.5.1Der Architekt als Berater für das Gesamtsystem
8.5.2Schwierige Ausprägungen von Architekten
8.6Produktmanager
8.6.1Der Produktmanager als Dirigent mehrerer Teams
8.6.2Schwierige Ausprägungen von Produktmanagern
9Rechtliche Themen
9.1Allgemeine rechtliche Aspekte
9.2Vertragsbasis und Vertragserfüllungspflicht
9.3Gewährleistung
9.4Agile Vorgehensweisen und Festpreis
9.5Das Vier-Stufen-Modell für agile Festpreisprojekte
9.5.1Stufe 1: Definition der Projektziele und ersten Kundenanforderungen
9.5.2Stufe 2: Agiles Erstellen der Vertragsbasis
9.5.3Stufe 3: Festpreisangebot durch den Lieferanten
9.5.4Stufe 4: Agile Projektabwicklung
9.6Öffentliche Ausschreibungen
9.7Standards und Normen
9.8Absicherung des Auftraggebers
9.9Absicherung des Lieferanten
Anhang
AAgile Methoden zur Unterstützung des Requirements Engineering
A.1Specification by Example
A.2Test Driven Development
A.3Behaviour Driven Development
BAbkürzungen
CGlossar
DLiteratur
Index
Der Fokus dieses Buches liegt darauf, gute Methoden und Techniken – egal welchen Alters oder welcher Ausrichtung – unvoreingenommen aufzugreifen und sie nicht von vornherein auszuschließen, nur weil es sich dabei um »klassische« oder »agile« Methoden oder Techniken handelt. Aussagen wie »nicht agile Methoden sind überfrachtet, ineffizient und schlecht« oder »agile Methoden sind was für Individualisten oder Dokumentationsfeinde« gehören nicht zu einer weitsichtigen und nachhaltigen Denkweise.
Jede der in diesem Buch genannten Methoden und Techniken stellt ein Werkzeug im Werkzeugkasten der Softwareentwicklung dar und soll hier mit ihren Vorteilen und Nachteilen in bestimmten Projektsituationen betrachtet werden. Es soll klar werden, wo und wie diese Methoden und Techniken in agilen Projekten eingesetzt werden können, um einen Nutzen für das Projekt zu stiften. Es werden daher auch sinnvolle Anwendungsmöglichkeiten und Fallstricke der einzelnen Methoden und Techniken dargestellt und im Kontext eines nachhaltigen, systematischen und praxisorientierten Requirements Engineering in der agilen Softwareentwicklung betrachtet.
Abgerundet wird das Buch durch die Behandlung von Qualitätsaspekten für Requirements, organisatorische Aspekte sowie durch rechtliche Aspekte bei der Anwendung von Requirements im agilen Umfeld.
Dieses Buch ist keine komplette Einführung in agile Methoden. Die Kapitel 1 und 2 geben zwar einen kurzen Überblick über das Agile Manifest, wesentliche agile Konzepte und Scrum, als am häufigsten eingesetzten Vertreter agiler Methoden. Der Hauptfokus des Buches liegt jedoch im Requirements Engineering und Requirements Management im agilen Kontext.
Hilfreich beim Lesen ist ein grundlegendes Verständnis des aktuellen Stands im Bereich Requirements Engineering und agiles Vorgehen sowie insbesondere die Kenntnis der allgemein anerkannten Begriffe, Techniken und Grundlagen aus diesen Themenbereichen. Zur vertiefenden Betrachtung wird z.B. auch der Lehrplan und die darin genannten Originalquellen für die Ausbildung zum »Certified Professional for Requirements Engineering (CPRE)« [IREB CPRE FL 2017] des International Requirements Engineering Board [IREB] empfohlen, der den grundlegenden Stand der Technik zum Thema Requirements Engineering darstellt.
Das Buch soll Einführungslektüre sowie Praxisleitfaden sein und ist nicht als wissenschaftlich komplette Abhandlung über das Thema Requirements Engineering in der agilen Softwareentwicklung gedacht. Es kann sequenziell oder auch auszugsweise gelesen werden. Als Autor ist es mir natürlich am liebsten, wenn Sie dieses Buch ständig an Ihrem Arbeitsplatz griffbereit haben und bei Fragen oder Unklarheiten zu Requirements-Engineering-Techniken oder -Vorgehensweisen darin einen schnellen Rat und brauchbare Infos finden.
In der Praxis hat man oft nicht die Zeit, beim Auftauchen einer Frage ein ganzes Buch z.B. zu Use Cases, User Stories oder Behaviour Driven Development zu lesen. Ich habe daher auf eine möglichst große Unabhängigkeit der einzelnen Themen und Kapitel geachtet, sodass das Buch auch als Nachschlagewerk in der täglichen Arbeit verwendet werden kann. Mit entsprechendem Vorwissen in agilen Methoden und Requirements Engineering kann es auch auszugsweise gelesen und verstanden werden. Für Praktiker müssen das Wichtigste und die Zusammenhänge in Kürze ersichtlich sein. Daher gibt es in vielen Kapiteln eine tabellarische Übersicht über wesentliche Punkte und verschiedene Überblicksgrafiken, die die Zusammenhänge auf einen Blick darstellen.
Auch wenn in vielen Kapiteln Begriffe aus Scrum verwendet oder zitiert werden, so wurde darauf geachtet, die einzelnen Themenbereiche möglichst allgemeingültig zu halten. Das Buch adressiert nicht »Requirements Engineering in Scrum«, sondern behandelt generell das Thema Requirements Engineering im agilen Umfeld. Die beschriebenen Techniken und Methoden können auch in anderen agilen Vorgehensweisen angewendet werden.
Beispiele werden mit einem grauen Hintergrund versehen:
In diesem Buch werden verschiedene Beispiele und Formulierungen aus der Praxis und für die Praxis aufgeführt. Die meisten dieser Beispiele sind abgeleitet aus einem Projekt zum Thema »Zeiterfassung«. Es geht in diesem Beispielszenario darum, dass die Tagesarbeitszeiten inkl. der Pausen und Abwesenheitszeiten von Mitarbeitern eines Unternehmens erfasst, ausgewertet und verwaltet werden können und dass auch die Erfassung, Auswertung und Verwaltung von Projektarbeitszeiten durchgeführt werden können – also von einzelnen Zeitblöcken der Tagesarbeitszeit, die bestimmten Projekten zugeordnet werden.
Das Buch richtet sich an Product Owner, Produktmanager, Projektmanager, Softwareauftraggeber, Scrum Master, Entwicklungsleiter, Entwickler, Tester und alle anderen Personen, die sich mit nachhaltigem und systematischem Requirements Engineering und Requirements Management in der agilen Softwareentwicklung beschäftigen oder davon betroffen sind.
Folgende Zielgruppen werden primär durch den [IREB CPRE FL 2017] adressiert:
[IREB RE@Agile FL 2017] LE 1.3
Seit 2017 gibt es einen neuen Lehrplan des International Requirements Engineering Board (IREB®), der die Lücke zwischen Requirements-Engineering-Methoden und agilen Methoden schließt.
Einerseits wird die Sicht des IREB-Standards auf agile Werte abgebildet und andererseits wird eine agile Sicht auf die Werte des Requirements Engineering dargestellt. Zum Inhalt des Lehrplans IREB RE@Agile gehören Klassifizierung und Beurteilung von Requirements-Engineering-Artefakten und -Techniken im Zusammenhang mit Agilität, agilen Artefakten und Techniken, Requirements Engineering und wesentlichen Prozesselementen in der agilen Produktentwicklung. RE@Agile zeigt die Motivation für die Verwendung agiler Methoden in Entwicklungsprozessen auf und betont die Synergie zwischen Requirements Engineering und Agilität.
Da dieses Buch viele ergänzende und vertiefende Inhalte umfasst, die nicht im Lehrplan IREB RE@Agile enthalten sind, ist in einigen Bereichen eine andere Strukturierung gegeben. Nachfolgend ist ein erster Überblick und einige Hinweise angeführt, wo in diesem Buch die wichtigsten Inhalte des Lehrplans zu finden sind:
Lehrplan RE@Agile |
in diesem Buch |
LE 1 Motivation und Mindset |
▪ Abschnitt 1.2 »Verbindung zwischen Requirements Engineering und agilem Vorgehen« und Abschnitt 2.1 »Methodenüberblick« |
LE 2 Grundlagen von RE@Agile |
▪ Kapitel 2 »Grundlagen« |
LE 3 Artefakte und Techniken in RE@Agile |
▪ Kapitel 3 »Requirements-Ermittlung und -Dokumentation« ▪ Kapitel 4 »Requirements-Validierung und -Abstimmung« (LE 3.2.3) ▪ Kapitel 6 »Requirements Management« (LE 3.2.4) ▪ Einige Aspekte aus LE3 sind auch in Kapitel 8 »Requirements-Engineering-Rollen« enthalten. |
LE 4 Organisatorische Aspekte von RE@Agile |
▪ Kapitel 7 »Organisatorische Aspekte« |
– |
▪ Die Kapitel 8 »Requirements-Engineering-Rollen« und 9 »Rechtliche Themen« sind Ergänzungen in diesem Buch, die detailliertere Aspekte beschreiben bzw. über den Lehrplan hinaus gehen. |
Die für den Lehrplan [IREB RE@Agile FL 2017] relevanten Kapitel und Stellen werden mit »[IREB RE@Agile FL 2017]« sowie ggf. mit der Ergänzung »LE xxx« gekennzeichnet und sind prüfungsrelevant. LE xxx referenziert auf die jeweilige Lerneinheit (LE bzw. EU = »Educational Unit«) des Lehrplans. Alle anderen Kapitel sind ergänzende Informationen und Hinweise oder Anregungen für die Praxis.
Wenn die Bezeichnung »RE@Agile« als Kurzbegriff verwendet wird, so bezieht sich dies immer auf den Lehrplan [IREB RE@Agile FL 2017].
Weiterführende Literatur zum Thema Requirements und agile Vorgehensweisen ist im Literaturverzeichnis im Anhang des Buches zu finden.
[IREB RE@Agile FL 2017]
Das umfangreiche Wissen in der Softwarebranche wird in unterschiedlichen Abstraktionsebenen beschrieben: [Meyer 2014] unterscheidet zwischen Prinzipien, Praktiken und Techniken. Diese Ebenen werden durch die Begriffe »präskriptiv« (vorschreibend), »abstrakt« und »falsifizierbar« (widerlegbar) unterschieden (siehe auch das Glossar im Anhang des Buches).
Die Kenntnis der Prinzipien ist wichtig, um bewusste Entscheidungen treffen zu können. Die Falsifizierbarkeit ist wichtig, um Diskussionen und Nachdenken über Prinzipien und auch Praktiken in Gang zu bringen und zu entscheiden, ob diese in einem bestimmten Kontext angewendet werden sollen.
Abhängig von der jeweiligen Situation und Kontext können auch jeweils unterschiedliche Praktiken zur Erfüllung eines Prinzips angewendet werden.
Sowohl der Lehrplan [IREB RE@Agile FL 2017] als auch dieses Buch mit seinen erweiterten Ausführungen und Inhalten vermitteln Wissen von Requirements Engineering im Kontext der agilen Vorgehensweisen und stellen diese Abstraktionselemente in sachlicher Form vor bzw. regen zum Nachdenken und zur Diskussion über deren Anwendbarkeit an.
[IREB RE@Agile FL 2017] LE 1.1
Heute ist die Software und IT ein »Enabler« und Treiber in vielen Bereichen. Viele über lange Jahre etablierte plangetriebene Entwicklungsmethoden wurden nicht für ein sich schnell änderndes Umfeld ausgelegt. Agile Methoden (siehe auch Abschnitt 2.1) haben sich hier mittlerweile etabliert und schließen diese Lücke.
»Agile« oder »Agilität« wird in [Sheppard & Young 2006] wie folgt definiert: »A rapid whole-body movement with change of velocity or direction in response to a stimulus.«
Die Motivation für die Verwendung agiler Methoden ist hier definiert als Reaktion (z.B. eine schnelle Veränderung der Ausrichtung oder der Umsetzungsgeschwindigkeit) auf eine Stimulation (z.B. aus dem Projektumfeld).
Wenn man sich das Agile Manifest [Agile Manifesto] und die agilen Methodenbeschreibungen durchliest, dann geht es darin um mehr als nur Schnelligkeit. Im Grunde fokussieren alle agilen Prinzipien und Vorgehensweisen auf eine Lieferung von für den Kunden nützlichen Ergebnissen in kurzen Intervallen.
Agile Methoden oder Agilität sind jedoch kein Selbstzweck. Nicht in allen Situationen passt dieses Vorgehen gleich gut. Wenn z.B. längerfristige Planung, Vorhersagbarkeit oder Nachvollziehbarkeit erforderlich ist, müssen ggf. andere Vorgehensweisen oder Anpassungen der agilen Methoden angewendet werden.
Es ist daher wichtig, im Vorfeld darüber nachzudenken und ein passendes bzw. angepasstes Entwicklungsvorgehen zu wählen. Dies kann grundsätzlich auch dazu führen, dass in unterschiedlichen Teams entsprechend dem jeweiligen Bedarf unterschiedliche Vorgehensweisen oder auch Kombinationen aus agilen und plangetriebenen Vorgehensweisen angewendet werden (z.B. wenn im Maschinenbau in der Hardwareentwicklung plangetriebenes Vorgehen und in der dazugehörenden Softwareentwicklung agiles Vorgehen in Kombination angewendet werden). Gartner hat dafür den Begriff »bimodale IT« geprägt. Dieses angepasste pragmatische Vorgehen ist auch einer der wesentlichen Erfolgsfaktoren der Softwareentwicklung und IT in dem heute sehr dynamischen Umfeld.
[IREB RE@Agile FL 2017] LE 1.2
In der IREB-Definition von Requirements Engineering im Lehrplan von 2017 sind Mindset und Werte von Requirements Engineering angegeben:
Requirements Engineering ist eine systematische und disziplinierte Herangehensweise zur Spezifikation und Management von Anforderungen mit den folgenden Zielen: