Pflichtenhefte und das Unified Model

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 Umgestaltung von Prozesse auf allen Ebenen einer Organisation. Da die Lebensdauer einer "Projekts" sinnvollerweise begrenzt ist, muss diese Dokumentation Projekt übergreifend angelegt werden.

Nur eine im Intranet online verfügbare Prozess- und Anforderungssammlung und eine aktuelle Schnittstellen-,  Service- und Api-Dokumentation taugt als Grundlage für die Wertsicherung bestehender Prozesse und IT-Lösungen.

Das Pflichtenheft - ein überholter Dinosaurier?

Ja und Nein, denn es gibt unverändert wichtige Bestandteile des klassischen "Pflichtenheftes" auf der einen Seite, und die "funktionale Spezifikation" auf der anderen Seite, die besser online statt über ein Dokument mit begrenzter Lebensdauer bereit gestellt wird.

Ja, klassische Pflichtenhefte sind überholt, wenn es darum geht, die 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 Analyse angepassten oder neu erstellten Online-Dokumentation, die unter anderem folgende Inhalte abdecken muss:

  • Verweis auf Online-Dokumentation zu betroffenen Geschäftsprozessen, Anwendungsfällen und IT-Systemen
  • Die Online-Dokumentation zu einem IT-System enthält: technische 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
  • Falls Schnittstellen betroffen sind: Verweis auf alte / neue Schnittstellen Dokumentation und Api Spezifikationen
  • 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.

Nein, Pflichtenhefte sind nicht überholt, um die unverändert wichtigen sonstigen Inhalte eines Pflichtenheftes zu dokumentieren:

  • Definition der Ziele aus Sicht des Auftragnehmers in der Sprache des Auftragnehmers
  • Klare Abgrenzung durch Formulierung von "Nichtzielen" durch den Auftragnehmer
  • Liste aller Stakeholder und Informations-Matrix: Wer liefert Anforderungen? Wer führt Review durch? Wer wird informiert?
  • Risiko Abwägung und Maßnahmen
  • Projekt-Zeitplan oder Verweis auf laufende Sprint-Dokumentation und Backlog
  • Liste der betroffenen IT-Systeme, der Ansprechpartner für Entwicklung, Test und Betrieb
  • Technische Details zur Entwicklungs-, Test-, und Produktionsumgebung und zu geplanten Integrationstests
  • Vorgaben zu Abnahme-Tests und Inbetriebnahmen

Diese Inhalte müssen für jedes neue Projekt gesammelt und verteilt werden. Ziele, Nichtziele, der Zeitplan und Schnittstellendefinitionen sind im Zuge eines Reviews vom Auftragnehmer und von den Beteiligten Mitarbeitern vor dem Start der entsprechenden Umsetzung zu prüfen und abzunehmen.

Bewährte Dokumentations-Methode: Unified Modeling Language

Andi AnalytikerDie Anforderungssammlung wird häufig von weniger erfahrenen Business Analysten als lose Sammlungen von 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 der "Unified Modeling Language" unabhängig von der physischen Realisierung in den beteiligten IT-Systemen erläutert. 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.

Nicht funktionale Aspekte z.B. im Zusammenhang mit technischen Vorgaben (z.B. unterstützte Webbrowser, Standards), mit der IT-Sicherheit usw. werden in der Regel in Prosa in dafür vorgesehen Kapiteln im Pflichtenheft ergänzt und später bei Bedarf auch in die Dokumentation der Applikation übernommen.

Nachtrag zum agilen Vorgehen

Die zuvor aufgezählten Inhalte eines modernen Pflichtenheftes sind kein "Ballast" aus Sicht der schlanken Softwareentwicklung, wenn Sie effizient und zeitnah dokumentiert werden. Bei iterativem Vorgehen kann dafür bei Bedarf ein eigener Sprint vorgesehen werden. Ausgewählte Inhalte z.B. der Ziele müssen bei größeren Projekten schrittweise in der Sprint-Planung für die gerade bearbeiteten Komponenten vorbereitet werden, z.B. in dem zu große Anforderungen (Epics) laufend in umsetzbare "Userstories" zerlegt werden. Dabei ändert sich in der Regel der Zeitplan und die Dokumentation von Datenmodellen, Schnittstellen- und APIs.

In jedem Fall sind diese Informationen in einem laufend aktualisiertem Dokument oder auf einer Projekt-Wiki Seite für alle Projekt-Mitarbeiter über die einzelnen Sprints hinaus zugänglich zu machen. Die übergreifende Dokumentation unterstützt die Sprint-Planung und den schrittweisen Ausbau der System-Landschaft.