Ob Software entwickelt, ob Hardware gebaut oder Maschinen konstruiert werden sollen: Am Anfang steht das Pflichtenheft. Es dokumentiert die Beschreibung des zu entwickelnden Systems, nennt die an der Entwicklung beteiligten Gruppen sowie die Voraussetzungen, die berücksichtigt werden müssen.
 
 

Was ist ein Pflichtenheft?

Ein Pflichtenheft dokumentiert schriftlich die Ergebnisse der Problemanalyse und dient als Grundlage für das weitere Vorgehen auf beiden Seiten. Es stellt später die einzige vertragliche Beschreibung des Auftrags dar. Es sagt der Entwicklungsgruppe möglichst genau, welche Anforderungen gestellt werden und dem Auftraggeber, welche Erwartungen er haben darf. Es ist für beide Seiten rechtlich bindend. Sofern im Heft nicht anders vermerkt, verlieren alle anderen Vereinbarungen ihre Gültigkeit.

Es sind deshalb in erster Linie Antworten auf folgende Fragen zu liefern:

• Beschreibung des zu entwicklenden Systems 
  (Was soll gemacht werden?)
• Das zu entwickelnde System muß genau beschrieben werden. 
• Das gewünschte Verhalten und die Schnittstellen müssen genau spezifiziert werden.
• An der Entwicklung beteiligte Gruppen (Wer macht es für Wen?)
• Auftraggeber und Auftragnehmer sollten noch mal explizit aufgeführt werden.
• Welche Voraussetzungen müssen berücksichtigt werden?
• Welche Vorleistungen liefert der Auftraggeber? 
• Welche Hardware soll verwendet werden? 
• Wieviel Entwicklungszeit steht zur Verfügung?

Teile des Pflichtenheftes

Das Pflichtenheft besteht aus den folgenden Teilen, zu denen, je nach Umfang des Projektes, weitere hinzugefügt werden können:

• Einführung 
• Auftrag
• Abgrenzung des zu entwickelnden Systems
• Beschreibung der Schnittstellen
• Analyse des Problems
• Externe Einflüsse
• Gewünschte Situation, Verhalten bei Fehlbedienungen und Störungen
• Beurteilung der Machbarkeit des Auftrags
• Gültigkeit des Pflichtenhefts
• Projektorganisation
• Phasenplan
• Ablaufkontrolle
• Vereinbarungen
• Benutzeranleitung? Schulung? Service?

 

Es folgt die grobe Beschreibung des Auftrags.

Dann wird kurz beschrieben, was entwickelt werden soll. Ist es z.B. die Steuerung für ein Bügeleisen oder für ein Atomkraftwerk. Die Beschreibung soll Personen, die nicht mit dem Projekt vertraut sind, kurz den Inhalt vermitteln.

Auftrag
Zuerst kommt die formale Auftragsformulierung.

Dann wird die Auftragsbeschreibung weiter erläutert. Beschreibung des Entwicklungszieles. Wie soll sich das System verhalten?

Es müssen Beschränkungen und Randbedingungen genannt werden. Was soll bei der Systementwicklung berücksichtigt werden? Welche Zeitspannen sind einzuhalten? Wie schnell muß das System auf Anforderungen reagieren?

Abgrenzung des zu entwickelnden Systems
Welche Systembereiche sind schon gegeben und brauchen nicht vom Auftragnehmer entwickelt zu werden? Die Mitarbeit von anderen Gruppen wird näher spezifiziert.

Beschreibung der Schnittstellen
Jedes System muß mit anderen Systemen (z.B. mit dem Benutzer) kommunizieren. Auf welchen Wegen findet die Kommunikation statt? Auf welche Signale muß das System reagieren und welche Signale muß das System erzeugen?

Diese Punkte sind auch wichtig für den Abnahmetest, der vom Auftraggeber auszuführen ist. Er muß sich dabei ebenfalls auf die im Pflichtenheft vereinbarten Eigenschaften beschränken.

Analyse des Problems
Wichtigste Probleme, die man bei der Entwicklung vorhersieht.

Ist die zur Verfügung stehende Hardware der Aufgabe gewachsen? Kann das System überfordert werden, weil sich die Ereignisse (Anforderungen) überstürzen? Was soll dann geschehen?

Externe Einflüsse
Welchen physikalischen Einwirkungen ist das System ausgesetzt? Wie sehen die Betriebszeiten aus? Soll das System permanent in Betrieb sein? Ist ein bewachter Betrieb vorgesehen oder soll das System unbeobachtet arbeiten?

Gewünschte Situation, Verhalten bei Fehlbedienungen und Störungen
Welche unvorhergesehene Ereignisse können eintreten und wie soll das System darauf reagieren? Welche Störungen sollen wie abgefangen werden? Kann die Energieversorgung gestört sein? Darf das System abstürzen? 

Kann davon ausgegangen werden, daß der Benutzer mit der Bedienung des Systems vertraut ist? Welche Fehlbedienungen sollen berücksichtigt werden?

Beurteilung der Machbarkeit des Auftrags
a) organisatorisch / betriebswirtschaftlich
Kann die Aufgabe mit verfügbaren Mitteln gelöst werden? Wieviel Arbeitsstunden werden zur Entwicklung nötig sein? Verfügt der Auftragnehmer über genug Leute, um die Entwicklung in der geforderten Zeit abzuschließen? 

b) technisch
Ist die zur Verfügung stehende Hardware der Aufgabe gewachsen? Kann gegebenenfalls geeignetere Hardware beschafft werden?

Gültigkeit des Pflichtenhefts
Einteilung der Aufgaben. Wer ist auf der der Ansprechpartner, wenn Fragen auftreten. Sind Änderungen möglich?

Es kann nicht ausgeschlossen werden, daß sich während der Entwicklung Änderungen ergeben. Hier muß geklärt werden, unter welchen Bedingungen das Pflichtenheft geändert werden kann. Wer ist zu welcher Änderung befugt.

Projektorganisation
Wer macht was? Aufteilung?

Phasenplan
Wann sind welche Vorergebnisse fertigzustellen?

Ablaufkontrolle
Zeitüberwachung; Bericht von/an wen?

Vereinbarungen
Dokumentation des Herstellungsprozesses. Wie soll der Entwicklungsfortschritt dokumentiert werden?
 

Benutzeranleitung? Schulung? Service?
Soll der Entwickler auch die Schulung des Bedienpersonals übernehmen? Wie weit soll der Auftragnehmer später die Wartung des Systems übernehmen?
 

Wie schreibt man ein Pflichtenheft?

Bei der Erstellung des Pflichtenheftes muß bedacht werden, daß das Pflichtenheft von vielen Leuten gelesen wird, die u.U. wenig mit der in der EDV üblichen Fachsprache anfangen können. Deshalb sind Fachbegriffe zu vermeiden oder für den Laien verständlich zu erklären.

Komplexe technische Abläufe lassen sich schwer mit natürlicher Sprache beschreiben. Dabei sind folgende Punkte zu vermeiden:

• Interpretationsspielräume 
• romanhafter Stil ohne klare Struktur
• Oft bieten sich grafische Darstellungen und Tabellen zur Beschreibung an. Dabei ist aber zu beachten, daß die verwendeten Symbole falsch interpretiert werden können und deshalb in einer Legende erklärt werden müssen.

Beispiele für Formulierungen, die zu vermeiden sind:

Das System muß dem aktuellen Stand der Technik entsprechen.
Das System muß leicht erweiterbar sein.
Antworten im Dialog müssen in angemessener Zeit erfolgen.
Das System muß auch bei Spitzenbelastung zufriedenstellend arbeiten.