Was ist ein Pflichtenheft?

Das Pflichtenheft dient der reibungslosen Umsetzung eines Projektes. Das Pflichtenheft bildet praktisch die Antwort auf das Lastenheft. Es wird vom Auftragnehmer erstellt und beinhaltet Informationen darüber, wie der Auftragnehmer das Geforderte umsetzen will.

Sinn und Zweck des Pflichtenheftes ist, dass die Anforderungen des Lastenheftes geprüft werden.

Das Pflichtenheft ist Vertragsgegenstand, also ein verbindliches Dokument.

In der Softwareentwicklung wird auch von dem Standard „IEEE Std 830-1998“ gesprochen. Eine Weiterentwicklung von diesem Standard ist die „Software Requirements Specification (SRS)“ oder auch die „System Requirements Specification (SyRS)“. Laut den Spezifikationen umfassen diese Spezifikationen das Lastenheft und das Pflichtenheft.

Die Erarbeitung eines Pflichtenheftes nimmt meist viel Zeit in Anspruch und wird im Allgemeinen vom Auftraggeber vergütet. Oft kommt es vor, dass Auftraggeber (meist kleinere Unternehmen) aus Kostengründen auf die Erstellung verzichten wollen. Dies ist aber nicht anzuraten, da bei größeren Projekten, vor allem Softwareprojekten die Auseinandersetzungen dann schon vorprogrammiert sind. Da in einem Pflichtenheft die konkret erbrachte Leistung definiert ist, schützt es also nicht nur den Auftragnehmer, sondern auch den Auftraggeber.

Die Vorteile eines Pflichtenheftes

• Transparenz
• Planungssicherheit
• Weniger Ärger oder Streitigkeiten zum Ende des Projektes
• Erspart zähe Nachverhandlungen
• Wahrscheinlichkeit für ein erfolgreiches Projekt steigt
• Vorteil für Auftragnehmer, da nachträgliche Anforderungswünsche eine Auftragsänderung bedeuten.
• Das schleichende Aufblähen von Anforderungen wird vermieden.
• Der Auftraggeber weiß genau, was er für sein Geld bekommt (Kosten).
• Der Auftragnehmer kalkuliert sicher seine Aufwände
• Bessere Schätzung von Risiken

Sprachliche Anforderungen an das Pflichtenheft

• Konkret formulieren (muss, nicht, soll, kann) – Die Anforderungen sind verbindlich!
• Genaue formuliert – S.M.A.R.T
• Formulierung in verständlicher Sprache (natursprachlich)
• Nicht zu viel verschachtelte Sätze
• Allgemeine Aussagen vermeiden
• Anforderungen sollen sich nicht widersprechen
• Vermeidung von „weak words“ wie z.B. (könnte, sollte, müsste, ausreichend, beinahe, circa, eben, eher, einfach, fast, gar, genug, gering, gut, häufig, irgendein, irgendjemand, irgendwas, kaum, klein, leicht, manchmal, mehr, meist, nahezu, öfters, sehr, schnell, schon, schön, sonstige, übrige, verschieden, viel, zahlreich, zunächst, usw.)
• Grafische Darstellungen, um komplexe Inhalte verständlich zu vermitteln (z.B. mit Diagrammen, Tabellen, UML, oder Mind-Maps, Kuchendiagramme, Balkendiagramme, usw..)

Die IEEE-Spezifikation einer SRS bestimmt vor allem die folgenden Charakteristika:

• Korrekt
• unzweideutig (eindeutig)
• vollständig
• widerspruchsfrei
• bewerte nach Wichtigkeit und/oder Stabilität
• verifizierbar
• modifizierbar
• verfolgbar (traceable)

Formelle Ansprüche

Ein Pflichtenheft sollte mindestens folgende formelle Ansprüche haben

• Ein Deckblatt mit der Projektbezeichnung, dem Wort „Pflichtenheft“, dem Datum der letzten Änderung und ggf. der Versionsnummer.
• Namen und Adresse des Unternehmens sowie des zuständigen Ansprechpartners benennen. Diese Informationen können bereits auf dem Deckblatt enthalten sein, sollten aber unabhängig davon in einem eigenen Kapitel vollständig ausgeführt werden.
• Kopf- und Fußzeile müssen neben der durchgehenden Seitennummerierung das Datum der letzten Änderung und (mindestens) die Kurzbezeichnung des Projektes aufweisen.
• Inhaltsverzeichnis mit klaren, sinnvoll abgestuften Gliederungen.
• Eine tabellarische Historie des Dokuments mit Datum, Autor und eine Aufstellung der vorgenommenen Änderungen des Inhalts.
• Eine Liste mit Verweisen auf Dokumente, die zum Pflichtenheft gehören (z.B. Berichte vorangegangener Projekte, Richtlinien, Verfahrensvorschriften, etc.)
• Ein Glossar der im Pflichtenheft verwendete, unternehmens-, produkt- und projektspezifische Fachbegriffe. Es muss insbesondere Akronyme und Abkürzungen erklären.

Die Inhalte eines Pflichtenheftes

• Ziel und Zweck des Dokumentes
• Projektbeschreibung
• Die Ausgangssituation (IST-Zustand)
• Das Ziel / Aufgabenstellung (SOLL-Zustand)
• Teams & Schnittstellen
• Zielgruppe(n)
• Systemvoraussetzungen
• Bereits bestehende oder betroffene Systeme oder Produkte
• Festlegung von Terminen
• Funktionale Anforderungen
• Nichtfunktionale Anforderungen
• Problemanalyse
• Test und Qualitätsmanagement
• Gewährleistung
• Wartung
• Schulungen
• Kostenaufstellung/Kostenplan
• Abnahmebedingungen

Ziel und Zweck des Dokumentes

Beschreibung der Aufgabe des Pflichtenheftes, hauptsächlich die Veranlassung, Zielsetzung, wesentliche Aufgaben und Definition.

Die Ausgangssituation (IST-Zustand)

Zunächst beschreiben Sie die IST-Situation. Machen Sie an dieser Stelle deutlich, warum das Projekt überhaupt zustande kommt (Anlass der Durchführung). Welches Problem soll behoben werden? Die Defizite bzw. Probleme existierender Systeme. Machen Sie möglichst deutlich, warum Handlungsbedarf besteht. Welches sind die vorhandenen Systeme (Geräte, Software, Nutzung)

Das Ziel / Aufgabenstellung (SOLL-Zustand)

Definieren Sie genau, was sie mit dem Projekt oder dem fertigen Produkt erreichen wollen. Was soll das Projektergebnis sein? Welche Ziele sollen erreicht werden? Beschreiben Sie auch die NICHT-Ziele falls man diese erwarten würde in Bezug auf das Ergebnis.

Teams & Schnittstellen

Hier sollte festgehalten werden welche Teams beteiligt sind und wo die Schnittstellen sind. Bei Softwareprojekten, kann z.B. auch nützlich sein hier die technischen Schnittstellen anzugeben, falls eine Kommunikation mit externen Schnittstellen implementiert werden soll. Idealerweise auch die Art der Schnittstelle und welcher Anbieter/Partner involviert ist.

Zielgruppe(n)

Definieren wer genau die Anwender des Produktes sein sollen und wodurch sie sich auszeichnen.

Systemvoraussetzungen

Beschreibung welche Systeme für den Betrieb des Endergebnisses vorausgesetzt werden. Z.B. bei einer Webanwendung: Internetfähiger PC mit Browser XY wird benötigt.

Bereits bestehende oder betroffene Systeme oder Produkte

Bestehen eventuell projektbezogene Systeme oder Produkte, die bereits vom Auftraggeber erledigt wurden und nun nicht mehr vom Auftragnehmer umgesetzt werden müssen? Sofern diese trotzdem für das Projekt relevant sind, erwähnen Sie sie ebenfalls im Pflichtenheft.  Sind bereits bestehende Systeme vom Endergebnis betroffen und wie weit spielen diese eine Rolle.

Festlegung von Terminen

Hier können Sie beispielsweise die gesamte Bearbeitungsdauer erläutern. Gehen Sie dabei auch auf die vorgesehenen Betriebs- und Arbeitszeiten ein. Beschreiben Sie außerdem die einzelnen Etappenziele (Meilensteine) mit den geplanten Terminen für Fertigstellung, Abnahme, Tests und Deployment. Legen Sie also präzise dar, wann welche Schritte erfolgen.

Funktionale Anforderungen

Gewünschte Funktionalitäten einer Anwendung oder des Produktes im Detail beschrieben. Folgende Punkte sollten, wenn zutreffend dabei beantwortet werden. Beschreibung, Wechselwirkung, Risiken, Testhinweise, Vergleich mit bestehenden Lösungen, Prioritäten, Schätzungen des Aufwandes. Bei den Funktionalen Anforderungen kann auch mit Plänen, Diagrammen, Tabellen, UML oder Mind-Maps gearbeitet werden, um komplexe Sachverhalte verständlich darzustellen.

Nichtfunktionale Anforderungen

Hier beschreiben Sie die Anforderungen an die Qualität, das Design oder Gesetze und Vorschriften, die eingehalten werden. Folgende Gliederung bietet sich an: Allgemeine Anforderungen, Gesetzliche Anforderungen, Technische Anforderungen. Bei technischen Anforderungen halten Sie auch fest, was Sie für die Umsetzung benötigen. Dies kann Bestandteil des Auftrages sein oder vom Auftraggeber gestellt werden.

Problemanalyse

Fassen Sie die wichtigsten Probleme zusammen, die sie erwarten. Wichtig ist vor allem, dass Sie für die wahrscheinlichsten Probleme bereits ein Lösungsansatz formulieren, um später Zeit zu sparen. Machen sie sich auch um unwahrscheinliche Probleme Gedanken.

Test und Qualitätsmanagement

Welche Anforderungen stellen sie an die Qualität. Beschreiben Sie auch, wie die Qualitätssicherung und Qualitätskontrolle aussehen.

Gewährleistung

Hier wird beschrieben, inwieweit eine Gewährleistung für die Hardware oder auch die erstelle Software übernommen wird. Sollten nur die gesetzlichen Gewährleistungen gelten, sind diese hier auch zu erwähnen.

Wartung

Wird eine regelmäßige Wartung für Infrastrukturprojekte oder Geräte angeboten, sollte hier der Umfang festgehalten werden. Bei Softwareprodukten sollte hier angegeben werden inwieweit ein First-, Second- oder Third-Level Support angeboten wird.

Schulungen

Erforderliche Schulungen für Mitarbeiter sollten hier angegeben werden. Es sollte darauf eingegangen werden, welche Voraussetzungen notwendig sind und wie groß der Umfang der Schulung sein wird.

Kostenaufstellung/Kostenplan

Um die gesamten Kosten des Projektes beziffern zu können, ist ein detaillierter Kostenplan notwendig. Kosten für Hardware, Software, Lizenzen, Wartung, Schulung usw.

Abnahmebedingungen

Hier wird definiert, wie die Abnahme des Projektes erfolgt. Es wird festgelegt welche Personen bei der Abnahme beteiligt sind und wer für die Abnahme verantwortlich ist. Stichwort „Abnahmeprotokoll“.