Pflichtenhefte im agilen Umfeld

Ein pragmatisches Vorgehen in modernen Projektumgebungen

Vertriebler: „Der Kunde hat uns seine Wünsche in diesem Foliensatz beschrieben. Damit wissen Sie ja, was zu tun ist. In drei Monaten kann ich doch mit dem neuen Produkt rechnen, oder?“

Wer in der Entwicklung tätig ist, hat eine solche Situation vermutlich schon einmal erlebt. Keine Sorge: Damit sind Sie nicht alleine. Denn was hier falsch läuft, passiert jede Woche mehrfach in sehr vielen Entwicklungszentren auf der Welt. Wünsche an ein neues Produkt werden beschrieben und einfach so in die Entwicklungsteams geworfen.

Durch die starke Vernetzung der Systeme ist dieses Vorgehen nicht mehr Stand der Methodik. Es muss zwangsläufig mehr kommuniziert und es müssen auch mehr Untersuchungen gemacht werden. Nur so können neben den Kundenwünschen auch Anforderungen der Gesetzgeber der jeweiligen Zielländer betrachtet und die Anforderungen der hauseigenen Produktion einbezogen werden. Und auch die Anforderungen des Service an die Wartbarkeit sollte für einen langen Produktlebenszyklus nicht außer Acht gelassen werden. Eine Nicht-Erfüllung dieser Anforderungen reduziert den Projekterfolg und stellt daher ein eklatantes Risiko für den Auftraggeber dar.

In der Wertschöpfungskette eines Unternehmens tauchen daher – wenn es richtig dargestellt wird – das Lastenheft und das Pflichtenheft auf. Diese beiden Dokumente sind ein sehr wichtiger Bestandteil des Entwicklungsprojekts, denn durch sie kann das Projektrisiko erheblich gesenkt werden. Dokumentierte Anforderungen helfen, den Projektumfang zu verstehen, Randbedingungen zu erfassen und Lösungen zu erarbeiten. Das Ergebnis dieses Vorgehens ist eine, auf die Organisationseinheit zugeschnittene Architektur, mit deren Hilfe der Autor des Pflichtenhefts die Anforderungen gezielt den Entwicklungsteams zuweisen kann.

Was ist das Pflichtenheft eigentlich? Und was ist es nicht?

Ein Pflichtenheft hat eine andere Funktion als ein Lastenheft, es ist sozusagen die Antwort eines Projektes auf das Lastenheft. In diesem Dokument werden die Anforderungen aus dem Lastenheft geklärt, sie können abgelehnt, übernommen und weiter verfeinert werden. Das Pflichtenheft wird klassischerweise als „System Requirements Specification“ oder im agilen Umfeld als Backlog mit Epics und User Storys vorliegen.

Lastenheft und Pflichtenheft dürfen nicht miteinander vermischt werden: Das Lastenheft liegt in der Verantwortung des Auftraggebers (Kunden, Vertrieb oder Produktmanagement) und das Pflichtenheft ist die Antwort des Entwicklungsprojektes darauf.

Bei Vermischungen entstehen zwei Probleme:

1. Die Möglichkeit, gewünschte von umzusetzenden Anforderungen zu trennen, geht verloren
2. Lastenhefte und Pflichtenhefte sind oftmals rechtliche Bestandteile eines Vertrags – wenn sie nicht getrennt werden, entstehen leicht rechtliche Probleme.

Das Pflichtenheft besteht aus zwei Teilen:

• Die Anforderungen, durch die das zu erstellende Produkt vollumfänglich beschrieben wird.
• Lösungsvorschläge in Form einer Systemarchitektur, die darstellt, wie diese Anforderungen umgesetzt werden sollen.

 

Input für das Pflichtenheft

Für die Erstellung des Pflichtenheftes steht zunächst das Lastenheft ganz oben auf der Liste möglicher Inputs. Ohne das Lastenheft beginnt die Entwicklungsabteilung zu suchen, was genau gefordert wird. Es dient als zentraler Einstieg und liefert die Beschreibung der Kundenwünsche an das Produkt.

Weitere Inputs für das Pflichtenheft sind Anforderungen, die hausintern vorhanden sind, damit

• das Produkt produziert werden kann.
• die Serviceabteilung in kürzester Zeit eine Wartung oder Fehlersuche durchführen kann.
• die Intralogistik die Variabilität der Produkte verwalten kann.
• das Produkt am Ende seines Lebenszyklus nicht mit hohen Entsorgungskosten zubuche schlägt.

Darüber hinaus schreibt ggf. der Gesetzgeber vor, wie Produkte produziert oder konfiguriert werden müssen, damit sie in den Verkauf gelangen dürfen.

Wie ist die Vorgehensweise zur Erstellung eines Pflichtenhefts?

Viel zu oft habe ich gesehen, wie wochen- und monatelang an Pflichtenheften geschrieben wurde und im Anschluss viele Wochen bis zur Freigabe ins Land gingen. Das verzögert nicht nur die Realisierung des Produktes, sondern sorgt auch für Unmut zwischen Vertrieb und Produktmanagement auf der einen und der Entwicklung auf der anderen Seite.

Wie kann aber nun ein Pflichtenheft auf pragmatische Weise erstellt werden? Und welche Aufgaben sind zu erledigen? Ich habe dazu zwei Phasen definiert, die helfen, ein Pflichtenheft strukturiert und zielgerichtet zu erstellen:

Phase 1: Basis schaffen

Diese Phase wird dazu genutzt, sich aus den vorhanden Dokumenten, Lastenheften und Zeichnungen eine Übersicht zu erstellen. Es handelt sich also im klassischen Sinne um eine Dokumentenanalyse. Sichten Sie in dieser Phase die Dokumente, die zur Verfügung stehen und suchen Sie weitere heraus, die referenziert aber nicht auf den Laufwerken vorhanden sind. Arbeiten Sie  heraus, um was es bei diesem Projekt geht. Falls es noch nicht gemacht wurde, erstellen Sie einen System-Footprint, um die Ergebnisse visuell darzustellen.

Im Rahmen dieser Recherche tauchen meist Fragen auf, die Sie mit anderen Projektbeteiligten klären müssen.

Bevor es dann an das Füllen des Pflichtenhefts geht, erstellen Sie eine Struktur des Dokuments, um eine Übersicht über die kommenden Inhalte zu erhalten. Als letzten Schritt in dieser Phase beschreiben Sie den Systemkontext. Damit stellen Sie dar, welche Teile durch das Projektteam bearbeitet und bereitgestellt werden müssen und welche außerhalb des Projekts liegen und entsprechend weder beachtet noch umgesetzt werden.

Phase 2: Problem beschreiben

In dieser Phase geht es darum, die Systemanforderungen aus den Kunden- oder Marktanforderungen abzuleiten, sowie die technischen Randbedingungen zu analysieren und daraus ebenfalls Systemanforderungen zu machen.

Grundlage dafür sind freigegebene Lastenhefte. Die Anforderungen im Lastenheft müssen bewertet und freigegeben sein, damit eine weitere Verarbeitung der Anforderungen einfacher von der Hand geht. Die Bewertung kann im selben Dokument, besser aber noch in einem Requirements Engineering Tool erfolgen.

Mit der Identifikation der Systemfunktionen wird der Nutzen des Systems für den Kunden beschrieben. Ein erster Schritt dazu ist das zentrale Feld im System Footprint, welches schon bei der Erarbeitung des Lastenhefts erfasst wurde. Weitere Funktionen sollten jetzt bei der Bearbeitung des Pflichtenhefts gefunden werden, die diese zentralen Funktionen unterstützen oder ihnen zuarbeiten.

Mit dem nächsten Schritt ist es möglich, die funktionalen Anforderungen daraus abzuleiten. Funktionale Anforderungen beschreiben all das, was das System ausführen soll. Die nicht-funktionalen Anforderungen folgen oder werden parallel erhoben. Wichtig ist es zu wissen, um welchen Typ Anforderungen (funktional / nicht-funktional) es sich bei der Erhebung handelt. Eine funktionale Anforderung bei einem Email-Programm wäre als Beispiel, dass eine Mail geschrieben und versendet werden kann. Wieviel Mails zu gleichen Zeit gesendet werden können, ist eine sog. nicht-funktionale Anforderung, da sie nicht die Funktionalität an sich beschreibt, sondern das Mengengerüst bzw. die Performanz des Programms.

Kurzum: Es werden also alle Anforderungen erfasst, die die Funktionen des Systems bestimmen, und alle Randbedingungen, die technische, funktionale oder organisatorische Grenzen des Systems beschreiben.

Um zielgerichtet und gleichzeitig nachvollziehbar zu entwickeln, ist es wichtig, die Herkunft und die Hintergründe von Anforderungen zu dokumentieren. Diese Nachvollziehbarkeit wird Traceability genannt. Durch eine existierende und gepflegte Traceability ergeben sich folgende Vorteile:

• Entwickler können erkennen aus welchen Gründen System-Anforderungen erstellt wurden.
• Querverbindungen und Abhängigkeiten zwischen Teilsystemen lassen sich besprechen.
• Bei Änderungswünschen kann in einem kurzen Zeitraum ermittelt werden, welche Auswirkungen diese auf das Gesamtsystem haben werden.
• Umsetzungen ohne Anforderungsbezug sind evtl. zu viel und werden im System nicht benötigt.

 

Zu guter Letzt sollte das Pflichtenheft durch kurze und gezielte Peer Reviews überprüft werden. Die Rückmeldungen werden eingearbeitet und im Anschluss wird das Dokument in einem abschließenden Freigabe-Review freigegeben.

Ein Pflichtenheft mit agilen Methoden erstellen – wie geht das?

Ein Pflichtenheft muss kein statisches Dokument sein. Es beschreibt nach bestem Wissen und Gewissen den aktuellen Stand der Wünsche und Anforderungen an ein System, nicht mehr – und nicht weniger! Übersetzt in agiles Arbeiten bedeutet dies: Sie benötigen ein iteratives Vorgehen mit regelmäßigen Reviews und Freigaben einzelner Pflichtenheft-Versionen. Das Ganze funktioniert frei nach dem angepassten Prinzip des Agilen Manifests: Funktionierende Pflichtenhefte sind wichtiger als eine umfassende Dokumentation.

Wie können Sie im Detail vorgehen? Erzeugen Sie zunächst einen ersten Stand des Pflichtenhefts, idealerweise mit einer im Vorfeld definierten Kapitelstruktur. Hat sich eine Struktur in einem früheren Projekt oder einer ähnlichen Entwicklung als nützlich erwiesen, kann es sinnvoll sein, diese zu nutzen. Legen Sie den ersten Stand sofort den Kollegen und Kolleginnen zum Peer Review vor, denn so erhalten Sie kurzfristig Rückmeldungen, wohlwissend dass noch nicht alle Anforderungen enthalten und beschrieben sind. In der Zwischenzeit arbeiten Sie bereits an der zweiten Version. Diese zweite Version kann neben weiteren Anforderungen auch Änderungswünsche von Kunden und neue Erkenntnisse aus der Entwicklung berücksichtigen.

Damit das Pflichtenheft die Ergebnisse enthält, mit denen die Beteiligten im Projekt zügig weiter arbeiten und ihre eigenen Ergebnisse produzieren können, gehen Sie am besten anhand der Kapitelstruktur des Dokuments vor und suchen Sie gemeinsam mit den Beteiligten die wichtigsten Kapitel heraus. Die Bewertung erfolgt idealerweise in gemeinsamen Gesprächen und unter Berücksichtigung der größten Risiken im Projekt. So erhalten Sie eine Reihenfolge, in der die Kapitel zu füllen sind und schnell einen Nutzen stiften.

Wurde eine definierte Menge an Anforderungen und Kapiteln bearbeitet, kann das Dokument in einem Freigabe-Review freigegeben werden. Wann das ist der Fall ist, bestimmen Sie selbst: manchmal bietet sich ein Zeitfenster an, manchmal ist eine Freigabe nach der Fertigstellung eines Hauptkapitels sinnvoll und manchmal wird ein definierter Umfang des Dokuments im Vorfeld vereinbart. So oder so sollten Sie bei der Freigabe darauf achten, dass das Pflichtenheft “potenziell nutzbar” ist.

Die erste Version eines agilen Pflichtenhefts hat natürlich nicht den gleichen inhaltlichen Reifegrad wie ein Pflichtenheft nach der klassischen Vorgehensweise in zwei bis sechs Monaten. Das ist aber auch nicht das Ziel, denn bei einem agilen Pflichtenheft steht die pragmatische Vorgehensweise im Vordergrund. Mit dem beschriebenen Vorgehen erhalten Sie ein korrektes, freigegebenes Pflichtenheft, um damit schnell in die Umsetzung gehen zu können.

Meiner Erfahrung nach passt die Arbeit mit mehreren Durchläufen und verschiedenen Ständen des Pflichtenhefts wunderbar in einem agilen Umfeld, zumal die Mitarbeitenden in den nachfolgenden Gewerken nicht lange warten müssen, sondern recht zeitnah mit der Vorbereitung und den ersten Untersuchungen auf Basis der ersten Pflichtenheftversion beginnen können. Wohlweislich, dass Änderungen kommen werden.

 

Hinweise:

Interessieren Sie sich für weitere Tipps aus der Praxis? Testen Sie unseren wöchentlichen Newsletter mit interessanten Beiträgen, Downloads, Empfehlungen und aktuellem Wissen.

Wenn Sie mehr über Pflichtenhefte und agiles Vorgehen erfahren wollen, hören Sie gerne in den Podcast https://zukunftsarchitekten-podcast.de rein. Dort beschreibt Björn Schorre Tipps und Tricks beim agilen Arbeiten. Benötigen Sie Hilfe beim Thema Systems Engineering und der Erstellung einer Systemarchitektur, schauen Sie gerne bei https://bjoernschorre.de vorbei.

Björn Schorre hat einen weiteren Beitrag im t2informatik Blog veröffentlicht:

Was macht eigentlich t2informatik? Ein Klick hier und Sie wissen es.