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 Zeit und Kosten bewertet. So wird neben einer präzisen Kostenschätzung auch eine genaue Information ü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 Aufwand und Nutzen von finanzieller Tragweite. Ein falsch gelegter Schwerpunkt gefährdet den Projekterfolg.

Was ist ein Pflichtenheft?

Das Verständnis über Aufbau und Inhalt eines Pflichtenhefts orientiert sich daran, vor welchem Hintergrund ein Pflichtenheft betrachtet wird. Für den Begriff des Pflichtenhefts gibt es verschiedenste Definitionen. Dies liegt daran, dass dieser Begriff mehrfach belegt ist. So wird ein Pflichtenheft nicht nur zur Erstellung von Software geschrieben. Auch in anderen Bereichen wie z.B. im Maschinenbau und der Fertigung gibt es die Form des Pflichtenhefts als Vorgabe für bestimmte Arbeiten. Für die weitere Betrachtungsweise wird das Pflichtenheft hier als die organisatorische und/oder technische Vorgabe zur Erstellung von Software definiert. In einem weiteren Schritt wird es in verschiedene Bereiche unterteilt, die im einzelnen separat behandelt werden.

Der rechtliche Teil

Das Pflichtenheft ist Bestandteil eines Vertrags zwischen Auftraggeber und Entwickler. Im Falle einer Auseinandersetzung zwischen den beiden Geschäftspartnern ist das Pflichtenheft die Grundlage auf der die Leistungserfüllung beurteilt wird. Die Abnahme eines Pflichtenhefts durch eine Abnahmeerklärung sichert sowohl den Auftraggeber als auch den Entwickler ab. Den Entwickler sichert es in der Hinsicht ab, dass der Auftrageber nachträglich keine Funktionen einfordern kann, die nicht Bestandteil des abgenommenen Pflichtenhefts gewesen sind. Den Auftraggeber sichert es dahingehend ab, dass die fertigte Software alle im Pflichtenheft festgelegten Funktionen enthält.

Damit der rechtliche Teil der Pflichtenhefterstellung korrekt abläuft sollte folgende Reihenfolge eingehalten werden: