Öffnet in einem neuen Tab
Pflichtenheft für Software

Pflichtenheft für Software im Mittelstand: Anforderungen strukturiert erfassen und verbindlich festlegen

Ein Pflichtenheft für Software legt fest, was ein neues System im Betrieb konkret leisten muss und woran die Erfüllung später gemessen wird. Es überführt die Wünsche der Fachbereiche in überprüfbare Anforderungen und bildet die Grundlage für Auswahl, Angebotsvergleich, Vertrag, Einführung und Abnahme. In vielen mittelständischen Unternehmen wird dieses Dokument übersprungen oder auf eine Liste von Stichworten reduziert, weil der Zeitdruck groß ist und der Anbieter ohnehin eine Vorführung anbietet.

Die Folgen zeigen sich nach dem Vertragsschluss. Funktionen, die als selbstverständlich galten, fehlen im Standardumfang. Schnittstellen zu bestehenden Systemen werden zum Zusatzprojekt, Anpassungen werden nach Aufwand berechnet, und die Abnahme gerät zum Streit, weil niemand schriftlich festgehalten hat, was vereinbart war. Ein sorgfältig erarbeitetes Pflichtenheft verlagert diese Auseinandersetzung an den Anfang, wo sie wenig kostet.

Dieser Beitrag beschreibt die Abgrenzung zwischen Lastenheft und Pflichtenheft, den Aufbau und die Anforderungsarten. Er zeigt, wie Anforderungen erhoben, formuliert und priorisiert werden, wie das Dokument in die Anbieterauswahl einfließt und welche Fehler zu vermeiden sind. Eine Beispielrechnung und eine Checkliste runden die Darstellung ab.

Titelbild: Foto von Alvaro Reyes auf Unsplash.

Lastenheft und Pflichtenheft: die Abgrenzung

Die Begriffe werden im Alltag häufig vermischt. Die Unterscheidung ist jedoch wichtig, weil sie festlegt, wer welches Dokument verantwortet.

  • Lastenheft: Es beschreibt aus Sicht des Auftraggebers, was erreicht werden soll. Es enthält Ziele, Rahmenbedingungen und Anforderungen in der Sprache der Fachbereiche und beantwortet die Frage nach dem Was und Wofür.
  • Pflichtenheft: Es beschreibt aus Sicht des Auftragnehmers, wie die Anforderungen umgesetzt werden. Es konkretisiert das Lastenheft, ergänzt technische Details und wird zum verbindlichen Vertragsbestandteil.

Im Mittelstand erstellt häufig der Auftraggeber beide Dokumente in einem, oder der Anbieter antwortet auf das Lastenheft mit einem eigenen Pflichtenheft. Beide Wege sind zulässig, solange erkennbar bleibt, wer welche Aussage trifft. Als Orientierung für Begriffe und Gliederung dient die Normenreihe zum Projektmanagement. Eine Einführung bietet die Seite des Deutschen Instituts für Normung.

Warum sich der Aufwand lohnt

Ein Pflichtenheft kostet Zeit, meist mehrere Wochen Arbeit der Fachbereiche. Dem stehen Einsparungen an mehreren Stellen gegenüber.

  • Angebote werden vergleichbar, weil alle Anbieter dieselbe Fragestellung beantworten.
  • Nachforderungen und Änderungswünsche während der Einführung nehmen ab.
  • Die Abnahme folgt vereinbarten Kriterien statt persönlichen Eindrücken.
  • Das Wissen über Prozesse wird dokumentiert und steht auch bei Personalwechseln zur Verfügung.
  • Die Einführung lässt sich besser planen, weil Umfang und Abhängigkeiten bekannt sind.

Wichtig ist die Verhältnismäßigkeit. Für ein Programm zur Zeiterfassung genügt ein schlankes Dokument von wenigen Seiten. Für ein ERP-System oder ein Produktionsplanungssystem ist ein umfangreiches Pflichtenheft angemessen. Der Umfang richtet sich nach Risiko, Kosten und Reichweite im Betrieb.

Aufbau eines Pflichtenhefts für Software

Es gibt keine verbindliche Gliederung, aber eine bewährte Struktur, die sich auf die meisten Vorhaben übertragen lässt.

Ausgangslage und Zielsetzung

Hier wird beschrieben, warum das Vorhaben stattfindet. Typische Inhalte sind der bisherige Prozess, die Probleme, die Ziele und die Erfolgskriterien. Zielgrößen sollten messbar sein, etwa eine verkürzte Durchlaufzeit oder eine geringere Fehlerquote.

Geltungsbereich und Abgrenzung

Welche Abteilungen, Standorte und Prozesse sind betroffen, und was gehört ausdrücklich nicht zum Vorhaben? Die Abgrenzung verhindert, dass der Umfang während des Projekts unmerklich wächst.

Ist-Prozesse und Soll-Prozesse

Die wichtigsten Abläufe werden vorher und nachher dargestellt, am besten als einfache Ablaufdiagramme mit Rollen und Systemen. Anforderungen entstehen dann nicht aus dem Bauch, sondern aus dem Prozess.

Funktionale Anforderungen

Sie beschreiben, was das System tun muss, etwa Aufträge erfassen, Rechnungen erzeugen, Freigaben abbilden oder Berichte liefern.

Nichtfunktionale Anforderungen

Dazu gehören Leistung, Verfügbarkeit, Datensicherheit, Datenschutz, Bedienbarkeit, Skalierbarkeit und Betriebsmodell. Diese Anforderungen werden häufig vergessen und verursachen später die größten Probleme.

Schnittstellen und Daten

Welche Systeme müssen angebunden werden, welche Daten werden übernommen, und in welchem Format? Die Datenmigration ist ein eigenes Teilprojekt, das im Pflichtenheft gesondert beschrieben werden sollte.

Rahmenbedingungen

Budget, Zeitplan, vorhandene Infrastruktur, Rollen im Projekt und rechtliche Vorgaben gehören hierher. Bei Software mit personenbezogenen Daten sind die Anforderungen der Datenschutz-Grundverordnung zu berücksichtigen, etwa zu Auftragsverarbeitung und Löschkonzept.

Abnahmekriterien

Jede wesentliche Anforderung benötigt ein Kriterium, mit dem die Erfüllung geprüft werden kann. Ohne diese Kriterien bleibt das Dokument eine Absichtserklärung.

Anforderungen erheben: Wer muss einbezogen werden

Die Qualität des Pflichtenhefts hängt von der Beteiligung der richtigen Personen ab. Reine Führungsrunden erzeugen Anforderungen, die an der Praxis vorbeigehen. Reine Anwenderrunden erzeugen Wunschlisten ohne Priorität. Bewährt hat sich ein kleines Kernteam aus Projektleitung, Prozessverantwortlichen, ausgewählten Anwendern und IT.

Für die Erhebung stehen mehrere Techniken zur Verfügung:

  • Interviews: Einzelgespräche mit Anwendern decken Besonderheiten auf, die in Gruppen untergehen.
  • Prozessbegehungen: Das Beobachten der tatsächlichen Arbeit zeigt Umwege und Behelfslösungen.
  • Workshops: Gemeinsame Sitzungen klären Konflikte zwischen Bereichen und führen zu abgestimmten Sollprozessen.
  • Auswertung vorhandener Unterlagen: Formulare, Auswertungen und Excel-Listen verraten, welche Daten tatsächlich gebraucht werden.
  • Störungsanalyse: Reklamationen und Supportfälle zeigen, wo das alte System versagt.

Besonders aufschlussreich sind die Behelfslösungen. Eine Excel-Tabelle neben dem Hauptsystem weist fast immer auf eine fehlende Anforderung hin, die sonst unbemerkt bleibt.

Anforderungen richtig formulieren

Eine Anforderung ist nur dann brauchbar, wenn sie eindeutig und prüfbar ist. Formulierungen wie „Das System soll benutzerfreundlich sein“ oder „schnell reagieren“ lassen sich nicht abnehmen. Besser ist: „Die Suche nach einem Kundendatensatz liefert bei bis zu 50.000 Datensätzen das Ergebnis innerhalb von zwei Sekunden.“

Folgende Regeln helfen bei der Formulierung:

  1. Eine Anforderung enthält genau eine Aussage.
  2. Sie nennt den Akteur und die erwartete Funktion.
  3. Sie enthält, wo möglich, einen messbaren Wert.
  4. Sie vermeidet Lösungsvorgaben, sofern diese nicht zwingend sind.
  5. Sie erhält eine eindeutige Kennung, damit sie in Angebot, Test und Abnahme zitiert werden kann.
  6. Sie wird mit „muss“, „soll“ und „kann“ abgestuft, wobei die Bedeutung dieser Wörter einmal definiert wird.

Eine knappe Satzschablone erleichtert die Arbeit: „Das System muss dem Sachbearbeiter ermöglichen, [Funktion] innerhalb von [Wert], wenn [Bedingung].“

Priorisierung: Muss, Soll, Kann

Nicht jede Anforderung hat dasselbe Gewicht. Wer alles als zwingend einstuft, verteuert das Vorhaben und schränkt die Auswahl ein. Eine einfache Dreiteilung genügt:

StufeBedeutungFolge bei Nichterfüllung
MussOhne die Funktion ist der Betrieb nicht möglich oder rechtlich unzulässigAusschlusskriterium
SollFunktion bringt deutlichen Nutzen, Behelf ist möglichPunktabzug in der Bewertung
KannWünschenswert, ohne wesentlichen EinflussKeine oder geringe Wirkung

Die Einstufung sollte gemeinsam mit den Fachbereichen erfolgen und von der Geschäftsführung bestätigt werden. Streitpunkte lassen sich oft lösen, indem gefragt wird, was geschieht, wenn die Funktion fehlt.

Beispielrechnung: Was eine Lücke im Pflichtenheft kosten kann

Die folgenden Zahlen sind frei gewählt und dienen ausschließlich der Veranschaulichung. Ein Betrieb führt eine Auftragsverwaltung ein. Das Angebot umfasst 40 Beratertage zu 1.000 Euro je Tag, also 40.000 Euro. In der Einführung stellt sich heraus, dass eine Schnittstelle zum Lagerverwaltungssystem nicht Bestandteil des Angebots war, weil sie im Anforderungspapier nicht ausdrücklich genannt wurde.

Der Anbieter schätzt den Aufwand für die Schnittstelle auf 12 Tage, also 12.000 Euro. Hinzu kommen zwei Tage interne Abstimmung auf Kundenseite und eine Verzögerung des Starts um vier Wochen. Die Mehrkosten betragen damit rund 30 Prozent des ursprünglichen Auftragswerts, ohne dass die Qualität des Systems besser geworden wäre.

Hätte das Pflichtenheft die Schnittstelle als Muss-Anforderung mit Datenumfang und Taktung enthalten, wäre sie im Festpreis enthalten gewesen oder zumindest transparent bepreist worden. Der Vergleich der Angebote hätte dies sichtbar gemacht.

Jede Anforderung, die nicht schriftlich festgehalten ist, wird später entweder zur Nachforderung oder zur Enttäuschung.

Vom Pflichtenheft zur Anbieterauswahl

Das fertige Dokument ist nicht nur Spezifikation, sondern Auswahlinstrument. Es dient als Grundlage für die Anfrage und für die Bewertung der Angebote.

  1. Anbieterliste erstellen: Zwei bis fünf Anbieter, die nach erster Prüfung zu Branche und Größe passen.
  2. Anforderungen als Fragenkatalog versenden: Der Anbieter beantwortet jede Anforderung mit „erfüllt“, „erfüllt mit Anpassung“ oder „nicht erfüllt“ und nennt den Aufwand.
  3. Antworten vergleichen: Eine Matrix mit Gewichtung der Anforderungen macht Unterschiede sichtbar.
  4. Vorführung mit Testszenarien: Der Anbieter führt reale Geschäftsvorfälle vor, nicht Standarddemos.
  5. Referenzen einholen: Gespräche mit vergleichbaren Kunden klären, wie die Einführung tatsächlich verlief.
  6. Vertrag auf das Pflichtenheft stützen: Das Dokument wird Anlage zum Vertrag, mit Abnahmekriterien und Regelung zu Änderungen.

Zur Bewertung bietet sich die Nutzwertanalyse an, bei der Anforderungen gewichtet, Erfüllungsgrade bewertet und Punktwerte addiert werden. Sie macht die Entscheidung nachvollziehbar und schützt vor Bauchentscheidungen.

Datenschutz und IT-Sicherheit im Pflichtenheft

Sobald ein System personenbezogene Daten verarbeitet, sind datenschutzrechtliche Anforderungen Teil der Spezifikation. Dazu zählen die Rollen- und Berechtigungskonzepte, die Protokollierung von Zugriffen, die Löschfristen und die Möglichkeit, Auskunftsersuchen zu bedienen. Wird die Software als Dienst eines Anbieters betrieben, ist zusätzlich ein Vertrag zur Auftragsverarbeitung erforderlich, dessen Inhalte sich aus Artikel 28 der Datenschutz-Grundverordnung ergeben. Den Verordnungstext können Sie bei EUR-Lex nachlesen.

Auch Anforderungen an die Informationssicherheit gehören in das Dokument: Verschlüsselung bei Übertragung und Speicherung, Mehrfaktor-Authentifizierung, Datensicherung mit Wiederherstellungszeiten, Standort der Rechenzentren und Verfahren bei Sicherheitsvorfällen. Je nach Branche kommen Vorgaben von Kunden oder Aufsichtsstellen hinzu. Diese Punkte lassen sich später nur mit hohem Aufwand nachrüsten und sollten deshalb von Beginn an als Muss-Anforderungen geführt werden.

Rollen und Verantwortlichkeiten im Projekt

Ein Pflichtenheft entsteht nicht nebenbei. Es braucht eine verantwortliche Person, die Entscheidungen herbeiführt und das Dokument pflegt. In der Praxis hat sich eine klare Rollenverteilung bewährt:

  • Projektleitung: Koordiniert Termine, führt das Dokument und stellt sicher, dass Entscheidungen getroffen werden.
  • Prozessverantwortliche: Beschreiben Abläufe und bestätigen, dass die Anforderungen die Praxis abbilden.
  • Anwendervertretung: Bringt Alltagswissen ein und prüft die Bedienbarkeit.
  • IT oder externe Beratung: Bewertet Machbarkeit, Schnittstellen und Betrieb.
  • Geschäftsführung: Legt Ziele, Budget und Prioritäten fest und gibt das Dokument frei.

Die Freigabe durch die Geschäftsführung ist keine Formalität. Sie stellt sicher, dass Prioritätenkonflikte zwischen Bereichen entschieden werden und nicht im Projekt weiterschwelen.

Beispiel: Schlankes Pflichtenheft für eine Zeiterfassung

Wie ein Dokument in kleiner Form aussehen kann, zeigt das Beispiel einer Zeiterfassung für einen Betrieb mit etwa achtzig Beschäftigten. Das Dokument umfasst sieben Abschnitte auf rund zehn Seiten.

  1. Ziel: Arbeitszeiten und Projektzeiten digital erfassen, Auswertung für Lohnabrechnung und Nachkalkulation bereitstellen.
  2. Abgrenzung: Keine Personaleinsatzplanung, keine Lohnabrechnung im System.
  3. Prozesse: Kommen und Gehen am Terminal oder mobil, Korrekturen mit Freigabe durch die Führungskraft, Monatsabschluss.
  4. Muss-Anforderungen: Erfassung auch ohne Netzverbindung, Übergabe der Daten an die Lohnabrechnung, Berechtigungskonzept, Löschfristen.
  5. Soll-Anforderungen: Projektbezogene Buchung, Abwesenheitsplanung, Erinnerungen bei fehlenden Buchungen.
  6. Schnittstellen und Migration: Export in das Lohnprogramm, Übernahme der Stammdaten aus der Personalliste.
  7. Abnahme: Je Muss-Anforderung ein Testfall, Probebetrieb über einen Monatsabschluss.

Dieses Gerüst lässt sich auf andere Vorhaben übertragen, indem die Inhalte ausgetauscht und der Umfang angepasst wird. Wichtig ist, dass die Struktur gleich bleibt, weil sie das Denken in prüfbaren Anforderungen schult.

Änderungen im Projekt steuern

Auch ein gutes Pflichtenheft bleibt nicht unverändert. Im Laufe der Einführung zeigen sich neue Erkenntnisse, und Rahmenbedingungen verschieben sich. Entscheidend ist ein geregeltes Verfahren für Änderungen. Jede Änderung wird schriftlich beantragt, hinsichtlich Aufwand, Kosten und Termin bewertet und von einer festgelegten Stelle freigegeben. Das Pflichtenheft wird versioniert, damit jederzeit erkennbar ist, welcher Stand gilt.

Typische Fehler und Stolperfallen

  • Das Dokument beschreibt die Lösung statt des Problems und schränkt damit unnötig ein.
  • Anforderungen sind unscharf formuliert und nicht prüfbar.
  • Nichtfunktionale Anforderungen wie Datenschutz, Backup oder Verfügbarkeit fehlen.
  • Der Fachbereich wird nicht beteiligt, und die Anwender lehnen das System später ab.
  • Alles gilt als „Muss“, sodass keine Auswahl mehr möglich ist.
  • Die Datenmigration wird nicht berücksichtigt.
  • Das Pflichtenheft wird nicht Vertragsbestandteil und verliert seine Verbindlichkeit.
  • Es gibt kein Verfahren für Änderungen.

Checkliste für das Pflichtenheft

  • Sind Ziel, Nutzen und Erfolgskriterien messbar beschrieben?
  • Ist der Geltungsbereich abgegrenzt?
  • Sind Ist- und Soll-Prozesse dokumentiert?
  • Hat jede Anforderung eine Kennung, eine Priorität und ein Abnahmekriterium?
  • Sind nichtfunktionale Anforderungen und Datenschutz berücksichtigt?
  • Sind Schnittstellen und Datenmigration beschrieben?
  • Wurden Fachbereiche und IT beteiligt?
  • Ist das Dokument Anlage zum Vertrag?
  • Gibt es ein Änderungsverfahren und eine Versionierung?

FAQ

Wie umfangreich sollte ein Pflichtenheft im Mittelstand sein?
Der Umfang richtet sich nach Kosten, Risiko und Reichweite des Vorhabens. Für kleine Anwendungen genügen wenige Seiten, für ERP- oder Produktionssysteme sind mehrere Dutzend Seiten angemessen.

Wer schreibt das Pflichtenheft, Auftraggeber oder Anbieter?
Das hängt vom Vorgehen ab. Häufig erstellt der Auftraggeber ein Lastenheft, und der Anbieter ergänzt ein Pflichtenheft. Wichtig ist, dass beide Seiten das Ergebnis bestätigen.

Brauche ich ein Pflichtenheft bei Standardsoftware?
Ja, in schlanker Form. Auch bei Standardsoftware muss geklärt werden, welche Anforderungen im Standard enthalten sind, welche Anpassungen nötig werden und welche Schnittstellen entstehen.

Wie gehe ich mit agiler Entwicklung um?
Auch agile Vorhaben profitieren von einem Rahmendokument mit Zielen, Abgrenzung und Abnahmekriterien. Details werden dann in Anforderungsbacklog und Iterationen konkretisiert.

Was gehört in die Abnahmekriterien?
Pro wesentlicher Anforderung ein Testfall mit Ausgangslage, Eingabe und erwartetem Ergebnis sowie die Festlegung, wer die Prüfung durchführt und wann sie als bestanden gilt.

Wie lange dauert die Erstellung?
Bei mittlerem Umfang rechnen Betriebe mit mehreren Wochen, abhängig von der Verfügbarkeit der Beteiligten. Die Prozessaufnahme beansprucht meist den größten Anteil.