Aus Sicht einer prozessorientierten Unternehmenssteuerung ist die laufend aktualisierte Dokumentation bestehender und neu geplanter Geschäftsprozesse und daraus abgeleiteter Anforderungen für interne Abläufe und IT-Services unverzichtbar für die kontinuierliche Evaluation und Verbesserung von Prozesse auf allen Ebenen einer Organisation. Da die Lebensdauer eines "Projektes" sinnvollerweise begrenzt ist, muss diese Dokumentation Projekt- und Produkt- übergreifend angelegt werden, mindestens aber für die Lebesdauer eines geplanten Produktes.
Nur eine im Intranet online verfügbare Prozess- und Anforderungssammlung oder ein Product-Backlog mit entsprechenden Inhalten z.B. Schnittstellen/API-Dokumentationen und strukturierte Anforderungen (z.B. in UML Notation) taugt als Grundlage für die Wertsicherung bestehender Geschäftsprozesse und damit verbundener digitaler Produkte. Diese Techniken können auch für das agile Umfeld adaptiert werden, siehe z.B. "Erweiterte User Stories".
Das Pflichtenheft - ein überholter Dinosaurier?
Ja und Nein, denn es gibt unverändert wichtige Bestandteile eines "Pflichtenheftes" zur Initiierung von herkömmlichen oder agilen Projekten, die gut in ein (Wegwerf-)Dokument passen. Auf der anderen Seite steht die initiale Sammlung möglichst strukturierter, funktionaler und nicht funktionaler Anforderungen, für die ein Dokument mit begrenzter Lebensdauer nicht geeignet ist, insbesonders im agilen Umfeld.
Ja, klassische Pflichtenhefte sind überholt, wenn es darum geht, geforderte "online" verfügbare Dokumentation bereit zu stellen, die über die Grenzen eines Projektes hinaus aktuell und konsistent gehalten werden muss. Ein modernes Pflichtenheft verweist über Links auf die während der vorbereitenden Analyse angepassten oder neu erstellten Online-Dokumentation, z.B. ein inital befülltes Product-Backlog, das unter anderem folgende Inhalte abdecken sollte:
- Die Online-Dokumentation zu einem neu geplanten oder gerade überarbeiteten Produkt (IT-System) enthält eine grobe Beschreibung fachlicher Abläufe mit den Austausch von Informationen mit angebundenen IT-Systemen (z.B. über Service Aufrufe) und ausgetauschten Datenformaten und Schlüsselfeldern, Berechnungen, beteiligte Akteure (Menschen und Maschinen!), deren Rollen und Berechtigungen, Beschreibung der internen Daten-Formate, Benutzer-Masken mit Navigation und angezeigten Datenobjekten, der dabei ausgetauschten oder gespeicherten (persistierten) Daten mit entsprechenden Schlüsselfeldern.
- Im agilen Umfeld werden diese "strukturierten Anforderungen" in Workshops mit geeigneten fachlichen Ansprechpartnern erarbeitet und in einer Product-Backlog Applikation z.B. mit Hilfe "erweiterter User Stories" beschrieben und schrittweise verfeinert.
- Falls Schnittstellen betroffen sind: Verweis auf alte / neue Schnittstellen Dokumentation (GUI und API Beschreibung)
- Besonderheit: Bei standardisierten IT-Systemen, z.B. SAP, kann die Dokumentation darauf beschränkt werden, welche Module, Schnittstellen und Masken in welcher Version benutzt werden, welche Konfigurationen vorzunehmen sind, und welche benutzerspezifischen Anpassungen (z.B. Z-Tabellen) erfolgen.
- Bitte beachten: Diese Informationen werden über die Projektlaufzeit verteilt gesammelt, ergänzt und verfeinert. Im agilen Umfeld sind zumindest monatliche lauffähige Inkremente des Endproduktes zu entwickeln, wobei die geforderte Spezifikation nur für die bereits enthaltene Funktionalität ausgearbeitet wurde.
Nein, Pflichtenhefte sind nicht überholt, um die unverändert wichtigen sonstigen Inhalte eines Pflichtenheftes zu dokumentieren:
- Definition der initalen Ziele und Vision für das geplante Produkt aus Sicht des Auftragnehmers in der Sprache des Auftragnehmers
- Zuordnung von fachlichen Themen/Domänen zum Produkt, und Klärung der Verantwortung für die damit verbundenen Prozesse, Daten und Schnittstellen.
- Klare Abgrenzung durch Formulierung von "Nichtzielen" durch den Auftragnehmer / Product-Owner
- Liste aller Stakeholder und Informations-Matrix: Wer liefert Anforderungen? Wer führt Review durch? Wer wird informiert?
- Verweis auf Online-Dokumentation zu bereits bestehenden Produkten, und der betroffenen Funktionaltitäten, z.B. falls vorhanden, der Geschäftsprozesse (bzw. Epics), Anwendungsfälle (bzw. Epics) und IT-Systeme / Schnittstellen, die für das Vorhaben benötigt und ggfs. auch angepasst werden müssen.
- Liste von im Vorfeld vereinbarten, nicht funktionalen Anforderungen (fachlich wie technisch), die relevant für die Lösungsarchitektur und damit verbundene Aufwände sind
- Risiko Abwägung und Maßnahmen
- Projekt-Zeitplan oder Verweis auf laufende Sprint-Dokumentation und Backlog
- Liste der betroffenen IT-Systeme / Schnittstellen, der Ansprechpartner für Entwicklung, Test und Betrieb
- Annahmen und grobe Aufwandschätzung zur Entwicklungs-, Test-, und Produktionsumgebung (Stages) und zu geplanten Integrationstests
- Vorgaben zu Abnahme-Tests und Inbetriebnahmen
Diese Inhalte sollten für jedes neue Projekt gesammelt und verteilt werden. Ziele, Nichtziele, ein grober Zeitplan und Schnittstellendefinitionen sind im Zuge eines Reviews vom Auftragnehmer (Product-Owner) und von den beteiligten Mitarbeitern vor dem Start der entsprechenden Umsetzung zu prüfen und abzunehmen.
Bewährte Dokumentations-Methode: Schlanke Unified Modeling Language (Lean UML)
Die Anforderungssammlung wird häufig von weniger erfahrenen Business Analysten als lose Sammlungen unstrukturierter Anforderungen gestartet, die in der Folge viel Aufwand bei der Verwaltung und Überprüfung erfordern. Effizienter ist es, Anforderungen von Anfang an in strukturierter Form mit Hilfe bewährter Techniken zu sammeln, und auf das Management und das arbeitsintensive "Tracking" unstrukturierter Anforderungen gänzlich zu verzichten.
Bei der Dokumentation sind zunächst funktionale (WAS wird benötigt?) und nicht funktionale (WIE ist es umzusetzen?) Anforderungen zu unterscheiden, die mit entsprechender Erfahrung am Besten in vorgegeben Kapiteln des Pflichtenheftes oder in der funktionalen Dokumentation zu den entsprechenden Geschäftsprozessen oder IT-Systemen gesammelt werden.
Im Beitrag Anforderungs-Management zur Umsetzung von Geschäftsprozessen wird das Konzept des "Anwendungsfalles" (Use Case) und Möglichkeiten zur Spezifikation strukturierte Daten und Dokumente (OOD) mit Hilfe ausgewählter Notationen "Unified Modeling Language" unabhängig von der technischen Realisierung in den beteiligten IT-Systemen erläutert. Diese Beschreibung beruht auf dem Prinzip des "Unified Models" eines digitalen Produktes, das unterschiedliche Sichtweisen bzw. Aspekte des Produktes (Laufzeitkomponenten, Daten- und Beziehungsarchitektur, Abläufe, Abhängigkeiten von Modulen usw.) mit Hilfe unterschiedlicher Beschreibungstechniken (Notationen) in einem über Querverweise "vereinten" Model beschreibt.
Eine modernisierte Variante der enthaltenen Anwendungsfälle bietet die "User Case 2.0" Methode. Diese Analyse-Technik vereint unterschiedliche Sichtweisen auf ein IT-System, z.B. die verhaltensorientierte Sichtweise die über Zustands- und Ablaufdiagramme veranschaulicht werden kann, oder die strukturelle Sichtweise der zur Laufzeit verfügbaren Daten-Objekte und deren Aufbau und Beziehungen.
In Kombination mit Methoden zur Darstellung von Benutzerschnittstellen (z.B. App-Screens, Web-Masken ...) können auf diese Weise funktionale Anforderungen an ein IT-System so genau wie nötig beschrieben werden, vgl den Beitrag "Lean UML und Use Case 2.0".
Nicht funktionale Aspekte z.B. im Zusammenhang mit technischen Vorgaben (z.B. unterstützte Webbrowser, technische Protokoll-Standards), mit der IT-Sicherheit usw. können in dafür vorgesehen Kapiteln im Pflichtenheft oder im initalen Product-Backlog in Form spezieller User Stories gesammelt werden. Es wird empfohlen, während der Projekt-Vorbereitung nicht funktionale Anforderungen mit beträchtlicher Auswirkung auf die spätere Lösungsarchitektur zu ermitteln.
Geht das auch agil?
Ausgewählte Aspekte der zuvor beschriebenen strukturierten Anforderungen sind auch im agilen Umfeld einsetzbar, wie die Beiträge "Agiles Anforderungsmanagement", "Lean UML", "Erweiterter User Stories" und "Agile Missverständisse" erläutern.