Das Pflichtenheft in der Softwareentwicklung

Lästiges Übel oder unverzichtbare Notwendigkeit? Im Bereich der Softwareentwicklung wird die Erstellung eines qualifizierten Pflichtenhefts oft mit geringer Priorität behandelt. Doch der Katzenjammer kommt meist hinterher, wenn immer wieder neue Forderungen die Entwicklungskosten in das Unermessliche treiben oder zugesagte Funktionen fehlen. Bernd Hilgenberg erläutert die wichtigen Bestandteile eines Pflichtenhefts. Eine fertig erstellte Vorlage zum Downloaden führt Sie Schritt für Schritt durch die Pflichtenhefterstellung.

Das Pflichtenheft in der Softwareentwicklung

Lästiges Übel oder unverzichtbare Notwendigkeit? Im Bereich der Softwareentwicklung wird die Erstellung eines qualifizierten Pflichtenhefts oft mit geringer Priorität behandelt. Doch der Katzenjammer kommt meist hinterher, wenn immer wieder neue Forderungen die Entwicklungskosten in das Unermessliche treiben oder zugesagte Funktionen fehlen. Bernd Hilgenberg erläutert die wichtigen Bestandteile eines Pflichtenhefts. Eine fertig erstellte Vorlage zum Downloaden führt Sie Schritt für Schritt durch die Pflichtenhefterstellung.

Im Bereich der Softwareentwicklung wird die Erstellung eines qualifizierten Pflichtenhefts oft mit geringer Priorität behandelt. Dokumentationen dieser Art, so eine verbreitete Meinung, verzögern und verteuern den Entwicklungsprozess nur unnötig. Es scheint zunächst wichtiger zu sein, eine Software fertig zu stellen, als eine Vorgabe dafür zu erarbeiten. Übertragen auf industrielle Fertigungsmethoden würde das bedeuten, zuerst eine Maschine zu bauen und entweder parallel, hinterher oder gar nicht die technischen Zeichnungen zu liefern. Hier käme niemand auf die Idee, solch eine Forderung an seine Ingenieure heranzutragen. Im Bereich der Softwareentwicklung sieht das allerdings ganz anders aus.

Ein guter Entwickler beginnt sehr früh mit der Produktrealisierung. Seine Arbeitsleistung wird nach "Lines-of-Code" bewertet. Dabei gilt: Je früher man etwas sehen kann, desto besser. Die schnellen Lösungen sind die besten. So oder ähnlich sind die Rahmenbedingungen unter denen Software häufig programmiert wird. Solche Einstellungen produzieren allerdings auch automatisch viele Probleme.

Jede Softwareentwicklung wird vor dem Hintergrund von ZeitZeitZeit ist eine der zentralen Steuerungsgrößen des Projektmanagements und bildet neben Kosten und Leistungsumfang im sog. Magischen Dreieck einen der drei Eckpunkte. Mittlerweile sind Qualität, Risiko und Nutzen als weitere Steuerungsgrößen etabliert. Je nach Projektart ist der Faktor Zeit besonders kritisch, z.B. im Veranstaltungsmanagement oder bei Wartungs- und Instandhaltungsprojekten. und Kosten bewertet. So wird neben einer präzisen Kostenschätzung auch eine genaue InformationInformationIm Projektmanagement wird der Begriff " Information " aus Sicht der Disziplinen Wissensmanagement, Kommunikationstheorie und Informationstheorie verwendet. Dabei ist Information zu verstehen als strukturiert und zweckorientiert aufbereitete Daten, siehe hierzu auch ↑Projektinformation . über die zu tätigenden Aufwände erwartet. Dies gilt auch für Projekte, in denen ein Pflichtenheft von nachgelagerter Bedeutung ist.

Hier beginnt dann der Teufelskreis in der Softwareentwicklung. Ohne ein qualifiziertes Pflichtenheft müssen Termine abgegeben werden, ohne jedoch den definierten Leitungsumfang genau zu kennen. Ein Terminverzug ist auf diese Weise vorprogrammiert. Zudem sind die notwendigen Anwendungsfunktionalitäten ohne schriftliche Fixierung eine Sache der Interpretation. Es besteht die Gefahr, dass der Anwender im Laufe der Realisierung mit immer neuen Ideen und Anforderungen kommt. Während des Projekts kann sich dann auch noch die gewählte Software- bzw. Hardwarearchitektur als falsch herausstellen. Dies produziert zusätzliche Kosten im Bereich der Programmierung und erfordert neue Investitionen in Hardware. Im schlimmsten Fall kann jeder einzelne der aufgeführten Punkte dazu führen, das ein Projekt komplett scheitert.

Fehlende Standards

Bislang hat sich keine verbindliche Regelung durchsetzen können, wie ein Pflichtenheft auszusehen hat. Als Folge reicht die Bandbreite dessen, was alles als Pflichtenheft bezeichnet wird von einem Zweizeiler, über wilde Zeichnungen bis hin zu einer bloßen Aufzählung von gewünschten Funktionen. Deshalb werden Mitarbeiter, die mit der Erstellung eines Pflichtenhefts beauftragt werden, in der Regel mit folgenden Problemen konfrontiert:

  • Wie sollen die Anforderungen der Fachabteilungen niedergelegt werden, damit sie später noch verstanden und bewertet werden können?
  • Welche Inhalte soll ein Pflichtenheft haben, damit ein Programmierer die Anforderungen umsetzen kann?
  • Welche Struktur soll gewählt werden, um die Fülle von Informationen, die zur Erstellung eines Programms notwendig sind, in einer Systematik aufzu-bauen?
  • Wie soll das Pflichtenheft übersichtlich und für spätere Erweite-rungen leicht pflegbar gehalten werden?
  • Wie vermeidet man mehrfache Beschreibungen gleichartiger Vorgänge?

Bei allen diesen Fragestellungen kommt hinzu, dass bei der Pflichtenhefterstellung eine Gradwanderung zwischen notwendigem und noch bezahlbarem Inhalt vollzogen werden muss. Steht zuwenig im Pflichtenheft, wird die Entwicklung durch die auftretenden Reibungsverluste unvollständig dokumentierter Anforderungen teuer. Ist das Pflichtenheft zu detailliert aufgebaut, fehlt das bei der Pflichtenhefterstellung verbrauchte Budget später bei der Programmierung. Gerade für kleinere Unternehmen ist dieses Verhältnis zwischen AufwandAufwandAufwand (Projektmanagement) ist die Menge aller monetär quantifizierbaren Eingangsgrößen in ein Projekt, in ein Programm, in ein Projektportfolio oder in einen Teil eines Projekts. und Nutzen von finanzieller TragweiteTragweiteTragweite eines Risikos ist die qualitative Prognose des Umfangs, den die Auswirkungen des Risikoereignisses haben, wenn es eintritt. Üblicherweise wird die Tragweite eines Risikos in Kategorien angegeben, z.B. "niedrig", "mittel" und "hoch".. Ein falsch gelegter Schwerpunkt gefährdet den ProjekterfolgProjekterfolgGrundsätzlich gilt ein Projekt als erfolgreich, wenn es seine Ziele (Ergebnis, Termintreue, Budgettreue) erreicht oder übertroffen hat. Neben diesen objektiv messbaren Kriterien hängt die Beurteilung des Projekterfolgs aber auch vom Standpunkt des jeweiligen Stakeholders ab..

Download PDFDownload PDF
Download ZIPDownload ZIP

Jetzt Feedback geben und mitdiskutieren!

Wir würden uns über Ihre Bewertung und/oder einen Kommentar freuen ‒ nur so können wir Ihnen in Zukunft noch bessere Inhalte liefern.

Diese Funktion steht nur eingeloggten Nutzern zur Verfügung.
0 Kommentare anzeigen & selbst mitreden!
Gesamt
Bewertungen 6
Kommentare 0