Das Pflichtenheft legt (verbal) die Anforderungen an die fertige Software fest.
Ziel ist es, aus den Anforderungen des Kunden (Lastenheft) eine möglichst vollständige konsistente und eindeutige Produktdefinition zu erstellen, die Grundlage für das zu erstellende Produkt ist.
Das Pflichtenheft bildet ein verbindliches Dokument zwischen Auftraggeber und Softwareproduzent und ist Grundlage für den abzuschließenden Vertrag, nach dessen Unterzeichnung es nur im gegenseitigen Einverständnis geändert werden darf. [INFODUDEN S. 659]
Das Pflichtenheft ist ein Dokument, welches als Vorgabe das Lastenheft erfordert. Die Erarbeitung des Pflichtenhefts beginnt in der Regel mit der Analyse (Problemanalyse) der im Lastenheft angeführten Anforderungen und Wünsche.
Während dieser Phase sieht sich der Softwareproduzent als fachlich versierter Kundenbetreuer im Rahmen der Kundenakquise und der Vertragsbildung. In enger Zusammenarbeit mit dem Kunden werden das WAS und das WOMIT definiert:

• WAS MUSS WOFÜR PRODUZIERT WERDEN?
• Für WAS wird das Endprodukt eingesetzt?
• WAS muss das Endprodukt demnach beinhalten?
• WAS müssen die Funktionen des Endprodukts bewerkstelligen?
• WAS muss über kurz oder lang gespeichert werden?
• Und gegebenenfalls — WAS kann im Laufe des Wandels noch hinzukommen?
• WOMIT wird entwickelt?

Das Deutsche Institut für Normierung e. V. normiert das Pflichtenheft unter DIN 69905.

Das Gegenstück zum WAS (hier Anforderungsspezifikation) ist das WIE — praktisch die Realisierung — und hat im Pflichtenheft nichts zu suchen! Erst nach Vertragsabschluss wird mit der eigentlichen Produktion begonnen, erst dann kümmert sich der Softwareproduzent als Informatiker darum, WIE das WAS realisiert werden soll.

Ein Softwareprodukt benötigt wie jedes andere Produkt ein Handbuch, welches das Produkt in allen Einzelheiten beschreibt. Praktisch gesehen, ist das Pflichtenheft bereits das Handbuch. Nur in die richtige Form übertragen, für den Endbenutzer verständlich gemacht, dürfte der Aufwand für das Handbuch nicht weiter ins Gewicht fallen.
Dem modernen Softwareproduzenten sei deshalb empfohlen, das Pflichtenheft gleich parallel zum Handbuch aspektorientiert zu erstellen. Bei nachträglicher Korrektur im Pflichtenheft würde das dazugehörige Handbuch nämlich (ggf. voll−) automatisch mitkorrigiert werden. Dieser Ansatz würde sogar die parallele Erstellung von Handbüchern für unterschiedliche Zielgruppen erlauben.
Zudem verspricht [SWTECHNIK] bei einer vorgezogenen Handbucherstellung eine bessere Handhabung (Usability) des Endprodukts, da der Entwickler schon vor dem Entwurf gezwungen sei, sich in die Lage des Endbenutzers hineinzuversetzen. Bis zur Auslieferung des Endprodukts blieben etwa 50 bis 70 Prozent vom vorgezogenen Handbuch erhalten. Meines Erachtens handelt es sich dabei um eine kluge Erkenntnis, wenn man bedenkt, dass allein die Usability über den Erfolg eines Produkts entscheiden kann.

Ein Pflichtenheft definiert die Anforderungen im Allgemeinen für ein beliebiges Produkt — es gibt keine Beschränkung auf Softwareprodukte. Mit einem Pflichtenheft können Sie ebensogut Anforderungen für ein Auto oder für irgendetwas anderes definieren.

In DIN 69905 wird die Anforderungsspezifikation des Auftragnehmers als Pflichtenheft bezeichnet. Es gibt aber auch andere Bezeichnungen dafür, die sich offenbar eingebürgert haben wie zum Beispiel:

• Fachfeinkonzept
• Sollkonzept
• Anforderungsspezifikation
• Fachspezifikation
• Funktionsspezifikation

Für „Pflichtenheft” habe ich mehrere mögliche Übersetzungen gefunden, die da lauten:

• „design requirement specification” (m. E. die beste Übersetzung)
• „design specification” (Begriff in der deutschen Raumfahrt)
• „feature specification”
• „product requirements document” (PRD)
• „specification book”
• „work statement”

Wenn Sie erfahren möchten, was ich von dem Begriffsdschungel halte und warum ich vorzugsweise den Begriff „Pflichtenheft” benutze, dann sollten Sie sich meine Ausführungen unter Anforderungsdefinition durchlesen.

Die Erstellung des Pflichtenheftes erfordert ungeheuren Weitblick des Softwareproduzenten. Hier werden indirekt die Weichen gestellt, wie das gesamte Softwareprodukt am Ende funktionieren soll und welche Bestandteile es enthalten muss. Zudem ist es notwendig, die Realisierbarkeit der Anforderungen erst zu prüfen und gegebenenfalls realisierbare Alternativen herauszuarbeiten. Dabei sollte der Kontakt zum Kunden sehr nah und projektbezogen sein, um Missverständnisse aus der Welt zu schaffen, da kleine Fehler im Pflichtenheft möglicherweise einen immens hohen und unnötigen Aufwand zur Folge haben.
Aufgrund der hohen Verantwortung, die der Verfasser des Pflichtenheftes trägt, müssen die Zusammenhänge in diesem stets erneut plausibel gemacht werden, um Widersprüche aufdecken zu können. Selbst erfahrene Softwareproduzenten haben Schwierigkeiten, ein Pflichtenheft widerspruchsfrei zu halten.

Experten unterschiedlicher Fachrichtungen können fabelhaft aneinander vorbeireden. Es ist ja nicht einmal sichergestellt, dass Experten vom selben Fach sich richtig verständigen können. Deshalb muss in den meisten Fällen erst ein gemeinsamer Nenner geschaffen werden.

• Oftmals sagen Skizzen mehr als tausend Worte.
• Aber auch Crashkurse im jeweiligen Fachgebiet tragen sehr zur effektiven Kommunikation bei.

Da das Pflichtenheft nicht nur ein zentrales Dokument des fachkundigen Softwareherstellers, sondern auch des fachunkundigen Auftraggebers ist, muss es in seiner Form und sprachlichen Gestaltung für beide Seiten verständlich und präzise sein. Da Anwender und Entwickler einander nur selten verstehen, versucht man manchmal, aus der Anforderungsspezifikation (aus dem vorläufigen Pflichtenheft) zunächst ein lauffähiges Modell (vorläufiges, teilimplementiertes Produkt) zu entwickeln (siehe evolutionäres Modell), an diesem wichtige Eigenschaften des Systems zu studieren und hieraus dann eine präzisere Anforderungsspezifikation (Pflichtenheft) zu erarbeiten, vergleiche [INFODUDEN S. 659].
Der dabei entstehende Aufwand lohnt sich allemal, wenn man bedenkt, dass das Pflichtenheft die Anforderungen des neuen Softwareprodukts bis zur Fertigstellung starr definiert.

Die Anforderungen an eine neue Software sind vage, verschwommen, unzusammenhängend, unvollständig und widersprüchlich. Dabei spielt die sprachliche Formulierung eine entscheidende Rolle.
Das Lastenheft kann trotz aller Bemühungen des Auftraggebers aus Sicht des Softwareproduzenten ungenau formuliert sein. Der Auftraggeber kann sich manchmal nicht vorstellen, welchen Einfluss so manches Adjektiv auf das Softwareprodukt haben kann.
Mit großer Wahrscheinlichkeit wird aber auch das Pflichtenheft stellenweise inkonsistent formuliert sein.
Oftmals entscheiden Adjektive wie multilingual, modular oder erweiterbar über die Gesamtstruktur des Softwareprodukts.
Auch das Weglassen von Adjektiven kann viel ausmachen. Beispielsweise ist der Unterschied zwischen „alle Browser” und „alle gängigen Browser” immens! Besonders bei „Browser” sollte der Entwickler konkret werden und Standards festlegen wie z. B. „HTML 4.01” oder „korrekt verifizierbar nach W3C”. Alternativ gibt es auch die Möglichkeit Browser bzw. Browserversionen aufzulisten wie zum Beispiel „[...] für folgende Browser: Internet−Explorer (ab 5.0), Firefox (ab 1.5), Safari, [...]”

Ungenaue Formulierungen im Lastenheft müssen präzisiert werden — am besten mit Hilfe des Auftraggebers. Lesen Sie sich dazu am Besten die Pflichtenheft−Kriterien durch.

Das Erstellen eines Pflichtenheftes ist sehr aufwendig und zeitintensiv. Deshalb sei den Pflichtenheftverfassern geraten, sich ein Framework für ein (beliebiges) Pflichtenheft anzuschaffen bzw. ein solches selbst zu erstellen. Möglicherweise entwickelt sich daraus ein neues Produkt, sozusagen eine „Pflichtenheft−Software”. Es ist aber unklar, inwieweit eine Pflichtenheft−Software den Aufwand einer Pflichtenhefterstellung minimieren kann. Seien Sie deshalb sorgfältig bei der Softwareauswahl zur Pflichtenhefterstellung.

Eine ideale Pflichtenhefterstellung stelle ich mir als gemeinsame Suche nach einem größtmöglichen, sinnvollen Leistungsumfang für die zu entwickelnde Software vor. Wobei ich mit „gemeinsam” den Auftraggeber und den Auftragnehmer meine. Dies ist m. E. nur möglich, wenn der Auftragnehmer zusätzlich die Position eines Beraters einnimmt.
Es erscheint nicht sehr sinnvoll, eine Tabellenkalkulationskomponente neu zu entwickeln, wenn der Auftraggeber bereits über Hunderte von Excellizenzen verfügt. In diesem Falle sollte dem Auftraggeber verständlich gemacht werden, dass es softwaretechnisch auch möglich ist, diverse Tabellenkalkulationsaufgaben einem externen, bereits vorhandenen Tabellenkalkulationsprogramm zu übergeben. Die Entwicklungszeit, die man dabei einsparen kann, könnte weiteren sinnvollen Features zukommen. Der Vorteil liegt auf der Hand: Der Auftraggeber kann sich in voller Zufriedenheit einen Teil des Budgets einsparen — oder er erhält für das gleiche Budget einen noch größeren Leistungsumfang.
Die Maxime lautet also:

1. Der Auftragnehmer sollte sich stets verpflichtet fühlen, nach sinnvollen Verbesserungen an der zu entwickelnden Software zu suchen, um seinen Auftraggeber noch zufriedener und gegebenenfalls noch konkurrenzfähiger zu machen.

Richtlinien und Tipps zur Verbesserung der Qualität Ihrer Pflichtenhefte.

Dieser Vorschlag ist selbstverständlich nicht wortwörtlich zu verstehen. Sie sollen hiermit lediglich daran erinnert werden, dass nur der Auftraggeber genau weiß, wie er sich sein Wunschprodukt vorstellt.
Je mehr Sie sich um eine adäquate Anforderungsspezifikation während der Definitionsphase bemühen, desto weniger müssen Sie Ihren Auftraggeber in späteren Phasen konsultieren. Nur Ihr Auftraggeber kann Ihnen zu einer adäquaten Anforderungsspezifikation verhelfen. Mit gezieltem Hinterfragen können Sie die Adäquatheit Ihres Pflichtenheftes sicherstellen. Also entlocken Sie ihm so viele Informationen wie möglich, denn in späteren Phasen ist es meist zu spät.
Wenn Sie sich mit dem Thema „requirements engineering” beschäftigen, erfahren Sie im Detail,

• was Sie bei der Erhebung der Anforderungen Ihres Auftraggebers zu beachten haben und
• wie diese zu sammeln, zu strukturieren, zu bewerten und zu verwalten sind.

Unter dem Deckmantel „requirements engineering” haben Sie nun endlich auch die Möglichkeit Ihren Auftraggeber ganz professionell zu nerven. :−)

Immer wieder gibt es unklare Punkte aus dem Lastenheft zu klären, wie z. B. vage Produktvorstellungen.
Einer vagen Produktvorstellung Ihres Auftraggebers sollten Sie, auch wenn es zunächst unnötig erscheinen sollte, durch Hinterfragen nachgehen und aus den daraus resultierenden Erkenntnissen eine klare, präzise Produktdefinition formulieren. Oder wollen Sie sich in späteren Phasen durch Diskussionen um die Produktdefinition aufhalten lassen oder gar die Konsistenz des Produkts aufs Spiel setzen?
Wenn Sie vage Vorstellungen in der Definitionsphase auflösen, verhindern Sie potentielle Meinungsverschiedenheiten. Zudem dämmen Sie mit einer sauberen Anforderungsspezifikation die Risiken der technischen Realisierung ein.
Denken Sie also immer daran, dass das, was im Pflichtenheft steht, später auch realisiert werden muss. Und seien Sie hiermit mit den folgenden Worten gewarnt:

1. Nicht „ungefähr”, sondern gleich „präzise” — mit „ungefähr” läuft keine Softwähr! :−)

Für weitere Richtlinien schreiben Sie bitte eine E−Mail an info@stefan−baur.de