IEEE 830 & Co: Welche Normen für Lastenheft und Pflichtenheft wirklich gelten

Wenn von Lastenheft und Pflichtenheft die Rede ist, fällt früher oder später ein Normen-Name: IEEE 830, DIN 69901, manchmal auch VDI 2519. Was diese Normen tatsächlich regeln, wird selten erklärt - und noch seltener, ob du sie für dein Softwareprojekt überhaupt brauchst. Die kurze Antwort: In den allermeisten Fällen ist keine dieser Normen für dich verpflichtend. Die etwas längere Antwort ist der Grund, warum sich der Blick auf sie trotzdem lohnt - sie geben dir ein bewährtes Gerüst dafür, was eine gute Anforderung ausmacht, ohne dass du sie formal einhalten oder zertifizieren lassen musst.

Warum Softwareprojekte überhaupt Normen kennen

Anforderungsdokumentation ist kein neues Problem. Lange bevor es agile Sprints oder Pflichtenhefte für Individualsoftware gab, mussten Ingenieurdisziplinen wie der Maschinen- und Anlagenbau bereits beschreiben, was gebaut werden soll und wer welche Aufgabe übernimmt. Aus dieser Praxis sind Normen entstanden, die festhalten, welche Fragen ein gutes Anforderungsdokument beantworten muss und welche Qualitätskriterien einzelne Anforderungen erfüllen sollten. Für die Softwarebranche wurden diese Ideen übernommen und teils eigenständig weiterentwickelt. Wenn du weißt, worauf sich diese Normen konkret beziehen, kannst du gezielt entscheiden, welche Struktur davon für dein Projekt sinnvoll ist, statt blind einer Vorlage zu folgen oder ganz ohne Struktur zu starten.

IEEE 830: der Klassiker für die Software Requirements Specification

IEEE 830 war über viele Jahre der meistzitierte Standard für die sogenannte "Software Requirements Specification" (SRS) - im deutschen Sprachraum am ehesten mit dem Pflichtenheft vergleichbar. Der Standard beschreibt, wie ein Anforderungsdokument gegliedert sein kann, und formuliert Qualitätskriterien, an denen sich einzelne Anforderungen messen lassen sollten:

Eindeutig: Eine Anforderung darf nur eine Interpretation zulassen.
Verifizierbar: Es muss überprüfbar sein, ob eine Anforderung erfüllt ist oder nicht.
Vollständig: Alle relevanten Funktionen, Randbedingungen und Ausnahmefälle sind beschrieben.
Widerspruchsfrei: Anforderungen dürfen sich nicht gegenseitig ausschließen.
Nachverfolgbar: Jede Anforderung lässt sich zu ihrem Ursprung (z. B. einem Geschäftsziel) und später zu ihrer Umsetzung zurückverfolgen.

IEEE 830 selbst wurde inzwischen zurückgezogen und durch die Nachfolgenorm ISO/IEC/IEEE 29148 ersetzt, die Anforderungsmanagement über den gesamten System- und Software-Lebenszyklus hinweg behandelt und dabei die Grundideen von IEEE 830 aufgreift und erweitert. In der Praxis wird IEEE 830 aber immer noch häufig zitiert, weil seine Qualitätskriterien einfach zu merken und direkt anwendbar sind - unabhängig davon, ob du dich formal auf die Norm beziehst.

ISO/IEC/IEEE 29148: der aktuelle Nachfolger

ISO/IEC/IEEE 29148 ist die heute gültige internationale Norm für Requirements Engineering in System- und Softwareprojekten. Sie deckt einen größeren Bogen ab als IEEE 830: von der Ermittlung von Stakeholder-Anforderungen über die eigentliche Spezifikation bis zur Verifikation. Für ein mittelständisches Softwareprojekt ist die vollständige Norm meist zu umfangreich, um sie eins zu eins anzuwenden - relevant ist eher die dahinterliegende Idee, Anforderungen in sauber getrennte Ebenen zu gliedern: Was will der Auftraggeber erreichen (Geschäftsziele), was muss das System dafür leisten (Systemanforderungen), und wie wird das im Detail umgesetzt (Software- bzw. Pflichtenheft-Anforderungen). Genau diese Trennung ist auch der Kern der Unterscheidung zwischen Lastenheft und Pflichtenheft.

VDI 2519: die deutsche Wurzel von Lastenheft und Pflichtenheft

Die Begriffe Lastenheft und Pflichtenheft selbst stammen ursprünglich nicht aus der Softwarebranche, sondern aus dem deutschen Maschinen- und Anlagenbau. Die VDI-Richtlinie 2519 (Vorgehensweise bei der Erstellung von Lasten-/Pflichtenheften) definiert dort, wie ein Lastenheft die Anforderungen des Auftraggebers und ein Pflichtenheft die daraus abgeleitete technische Umsetzung des Auftragnehmers beschreibt. Die Softwarebranche in Deutschland und Österreich hat diese Begriffe und die dahinterliegende Rollenverteilung übernommen, ohne dass VDI 2519 selbst eine Software-Norm ist. Das erklärt auch, warum die Begriffe im englischsprachigen Raum keine direkte Entsprechung haben und stattdessen von "requirements specification" die Rede ist.

DIN 69901: Projektmanagement-Begriffe, keine Vorlage

DIN 69901 ist eine Normenreihe zum Projektmanagement und liefert unter anderem Begriffsdefinitionen, die auch Lastenheft und Pflichtenheft betreffen. Sie beschreibt keine konkrete Dokumentenvorlage für Softwareprojekte, sondern schafft eine einheitliche Terminologie, damit Auftraggeber und Auftragnehmer beim Wort "Pflichtenheft" dasselbe meinen. Für dein Projekt ist DIN 69901 vor allem dann relevant, wenn dein Auftraggeber oder ein Fördermittelgeber eine normkonforme Terminologie verlangt - inhaltlich ersetzt sie aber nicht die eigentliche fachliche Ausarbeitung deiner Anforderungen.

Was das für dein Projekt praktisch bedeutet

Für die allermeisten KMU-Softwareprojekte ist keine dieser Normen vertraglich bindend, und eine formale Zertifizierung gegen sie ist unüblich und in der Regel auch nicht nötig. Trotzdem lohnt sich der Blick auf sie aus drei praktischen Gründen:

Qualitätskriterien statt Bauchgefühl: Die IEEE-830-Kriterien (eindeutig, verifizierbar, vollständig, widerspruchsfrei, nachverfolgbar) sind eine einfache Checkliste, mit der du jede einzelne Anforderung in deinem Pflichtenheft selbst prüfen kannst, bevor du sie an einen Entwicklungspartner gibst.
Klare Rollentrennung: Die VDI-2519-Logik - Lastenheft beschreibt das WAS aus Sicht des Auftraggebers, Pflichtenheft das WIE aus Sicht des Auftragnehmers - verhindert, dass technische Umsetzungsdetails schon im Lastenheft landen und dir damit unnötig Entscheidungsspielraum nehmen.
Gemeinsame Sprache: Wenn beide Seiten wissen, worauf sich Begriffe wie "Anforderung", "Lastenheft" oder "Abnahmekriterium" normativ beziehen, sinkt das Risiko von Missverständnissen, die später zu Nachforderungen führen - ein Muster, das wir bereits im Artikel zu teuren Pflichtenheft-Fehlern beschrieben haben.

Der Fehler, den wir in der Praxis auch ab und an sehen, ist die Überkorrektur: ein zehnseitiges Lastenheft für eine App mit drei Kernfunktionen, weil eine Vorlage aus dem Anlagenbau eins zu eins übernommen wurde. Die Normen liefern eine Struktur, keine Pflicht zur Vollständigkeit um ihrer selbst willen. Für ein kleines Projekt reicht es oft, die Qualitätskriterien auf eine handvoll zentraler Anforderungen anzuwenden, statt jede denkbare Ausnahme zu dokumentieren.

Wann sich ein normnäherer Ansatz trotzdem lohnt

Es gibt Situationen, in denen sich eine striktere Orientierung an diesen Normen auszahlt: bei Projekten mit mehreren externen Beteiligten, bei regulierten Branchen (z. B. Medizintechnik-nahe Software, wo angrenzende Normen ohnehin Pflicht sind), oder wenn ein Investor beziehungsweise Fördermittelgeber eine nachvollziehbare, auditierbare Anforderungsdokumentation verlangt. In diesen Fällen lohnt es sich, die Gliederung von ISO/IEC/IEEE 29148 als Grundgerüst zu verwenden und Nachverfolgbarkeit (welche Anforderung erfüllt welches Ziel, welcher Test prüft welche Anforderung) von Anfang an mitzudenken, statt sie nachträglich zu rekonstruieren.

Fazit

IEEE 830, sein Nachfolger ISO/IEC/IEEE 29148, die deutsche VDI 2519 und die Begriffsnorm DIN 69901 sind für die meisten Softwareprojekte im Mittelstand keine Pflicht, sondern ein Werkzeugkasten. Der praktische Wert liegt nicht darin, eine Norm formal einzuhalten, sondern ihre Qualitätskriterien und Rollentrennung auf dein eigenes Lastenheft oder Pflichtenheft anzuwenden - in einem Umfang, der zur Größe deines Projekts passt.

Häufig gestellte Fragen

Muss ich mein Pflichtenheft nach IEEE 830 zertifizieren lassen?

Nein. IEEE 830 ist zudem inzwischen zurückgezogen und durch ISO/IEC/IEEE 29148 ersetzt. Für die meisten KMU-Softwareprojekte ist keine formale Zertifizierung nötig oder üblich - relevant sind die dahinterliegenden Qualitätskriterien, nicht ein Zertifikat.

Was ist der Unterschied zwischen IEEE 830 und ISO/IEC/IEEE 29148?

IEEE 830 konzentrierte sich auf die Struktur und Qualität einer einzelnen Software Requirements Specification. ISO/IEC/IEEE 29148 ist die aktuelle Nachfolgenorm und deckt Requirements Engineering über den gesamten System- und Software-Lebenszyklus ab, von Stakeholder-Anforderungen bis zur Verifikation.

Woher kommen die Begriffe Lastenheft und Pflichtenheft eigentlich?

Sie stammen ursprünglich aus dem deutschen Maschinen- und Anlagenbau und sind in der VDI-Richtlinie 2519 definiert. Die Softwarebranche hat die Begriffe und die Rollentrennung - Lastenheft vom Auftraggeber, Pflichtenheft vom Auftragnehmer - übernommen, ohne dass VDI 2519 eine Software-Norm ist.

Was regelt DIN 69901 in diesem Zusammenhang?

DIN 69901 ist eine Normenreihe zum Projektmanagement, die unter anderem einheitliche Begriffsdefinitionen liefert, etwa für Lastenheft und Pflichtenheft. Sie gibt keine konkrete Dokumentvorlage vor, sondern sorgt für eine gemeinsame Terminologie zwischen den Projektbeteiligten.

Für welche Projekte lohnt sich eine striktere Normorientierung?

Vor allem für Projekte mit mehreren externen Beteiligten, in regulierten Branchen oder wenn ein Investor beziehungsweise Fördermittelgeber eine nachvollziehbare, auditierbare Anforderungsdokumentation verlangt. Für ein kleineres Projekt reicht es meist, die Qualitätskriterien gezielt auf die zentralen Anforderungen anzuwenden.