Lastenheft für Individualsoftware: Anleitung und Vorlage

Wer ein Lastenheft schreibt, steht kurz davor, ein Softwareprojekt zu vergeben. Genau an dieser Stelle entscheidet sich, ob die späteren Angebote vergleichbar sind, ob das Budget hält und ob am Ende die Software entsteht, die der Betrieb wirklich braucht. Dieser Leitfaden zeigt Ihnen, was in ein Lastenheft für Individualsoftware gehört, wie ausführlich es sein muss, wie gute und schlechte Anforderungen konkret aussehen und stellt Ihnen eine Gliederung zur Verfügung, die Sie sofort übernehmen können.

Was ist ein Lastenheft?

Ein Lastenheft ist die vom Auftraggeber erstellte Beschreibung aller Anforderungen an ein zu entwickelndes System. Es beschreibt das Was und das Wofür, nicht das Wie. Die technische Lösung ist ausdrücklich Sache des Auftragnehmers.

Die klassische Definition stammt aus der DIN 69901-5 zum Projektmanagement: Das Lastenheft umfasst die Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Auftragnehmers. Die VDI-Richtlinie 2519 beschreibt Lastenheft und Pflichtenheft als aufeinander aufbauendes Paar und liefert bis heute die in der Praxis gebräuchlichste Struktur.

Für ein KMU bedeutet das ganz praktisch: Sie beschreiben Ihre Prozesse, Ihre Probleme und Ihre Ziele in Ihrer Fachsprache. Sie müssen weder Datenbanken noch Frameworks noch Architekturen festlegen. Wenn Sie noch klären möchten, ob Individualsoftware für Ihren Fall überhaupt der richtige Weg ist, hilft unsere Erklärung, was Individualsoftware ausmacht.

Lastenheft oder Pflichtenheft: Was ist der Unterschied?

Der Unterschied ist einfach: Das Lastenheft schreibt der Auftraggeber vor der Vergabe, das Pflichtenheft schreibt der Auftragnehmer als Antwort darauf. Das eine formuliert die Anforderung, das andere die zugesagte Umsetzung.

In der Praxis fließen beide Dokumente ineinander: Ein sauber formuliertes Lastenheft lässt sich vom Dienstleister direkt in ein Pflichtenheft überführen, das dann Vertragsbestandteil wird. Wie dieser Ablauf insgesamt aussieht, beschreiben wir im Beitrag zum Prozess der Individualsoftware-Entwicklung.

Warum lohnt sich der Aufwand für ein KMU?

Ein gutes Lastenheft macht Angebote vergleichbar und schützt vor Nachträgen. Erfahrungsgemäß können Dienstleister auf Basis eines belastbaren Lastenhefts ein Angebot abgeben, das am Ende in einem Korridor von rund plus/minus 20 Prozent trifft. Ohne Lastenheft liegen Angebote für dieselbe Idee nicht selten um den Faktor drei auseinander.

Der Grund ist banal: Fehlt die Beschreibung, kalkuliert jeder Anbieter etwas anderes. Der eine denkt an eine schlanke Auftragsliste, der andere an ein System mit Zeiterfassung, Materialwirtschaft und Schnittstelle zur Buchhaltung. Sie vergleichen dann Preise für völlig unterschiedliche Produkte.

Drei weitere Effekte kommen hinzu, die im Tagesgeschäft mehr wert sind als der Preisvergleich:

• Klärung im eigenen Haus: Beim Schreiben merken Sie, wo Abteilungen unterschiedliche Vorstellungen vom gleichen Prozess haben. Diese Konflikte im Vorfeld zu lösen ist deutlich günstiger, als sie im laufenden Projekt zu entdecken.
• Verhandlungsposition: Wer seine Anforderungen schriftlich hat, verhandelt über Umfang statt über Stundensätze.
• Abnahmefähigkeit: Nur was vorher beschrieben wurde, lässt sich hinterher prüfen. Ein Lastenheft ohne Abnahmekriterien führt fast zwangsläufig zu Streit darüber, wann eine Funktion fertig ist.

Welche Kapitel gehören in ein Lastenheft?

Ein vollständiges Lastenheft für ein Softwareprojekt umfasst zehn Kapitel: von der Ausgangslage über die fachlichen Anforderungen bis zu Abnahmekriterien und Rahmenbedingungen. Diese Struktur hat sich in Projekten jeder Größe bewährt und lässt sich für kleine Vorhaben problemlos kürzen.

1. Ausgangslage und Problemstellung: Wie läuft der Prozess heute, welche Systeme sind im Einsatz, was funktioniert nicht? Beschreiben Sie den Ist-Zustand so konkret, dass ein Außenstehender ihn versteht, inklusive der Mengengerüste (Aufträge pro Monat, Anzahl Nutzer, Datenvolumen).
2. Ziele und Nutzen: Was soll nach der Einführung besser sein? Formulieren Sie messbar, etwa "Doppelerfassung zwischen Angebot und Rechnung entfällt" statt "effizientere Prozesse".
3. Anwender und Rollen: Wer arbeitet mit dem System, mit welchen Rechten, an welchem Ort und auf welchem Gerät? Rollen wie Disponent, Monteur, Buchhaltung oder Geschäftsführung strukturieren später die gesamten Anforderungen.
4. Fachliche Anforderungen: Das Herzstück. Beschreiben Sie jede benötigte Funktion aus Sicht einer Rolle, am besten als User Story mit Akzeptanzkriterien. Nummerieren Sie durchgehend, damit sich Angebote darauf beziehen können.
5. Schnittstellen: Welche Systeme müssen Daten austauschen? Nennen Sie Name, Hersteller, Version, Richtung des Datenflusses und ob eine API vorhanden ist. Unklare Schnittstellen sind der häufigste Grund für Nachträge.
6. Daten und Datenschutz: Welche Daten werden verarbeitet, welche davon sind personenbezogen, wie lange müssen sie aufbewahrt werden, welche Altdaten sind zu migrieren? Eine Orientierung bietet unsere Checkliste für DSGVO-konforme Softwareentwicklung.
7. Nicht-funktionale Anforderungen: Verfügbarkeit, Antwortzeiten, gleichzeitige Nutzer, Browser- und Geräteunterstützung, Barrierefreiheit, Betrieb in einem Rechenzentrum in Deutschland, Backup- und Wiederherstellungszeiten.
8. Abnahmekriterien: Woran wird gemessen, dass die Lieferung vollständig ist? Zum Beispiel: alle Anforderungen der Priorität "Muss" umgesetzt, Testfälle bestanden, Dokumentation und Einweisung erfolgt.
9. Rahmenbedingungen: Vorgaben, die nicht verhandelbar sind: bestehende Infrastruktur, Compliance-Vorgaben, Ansprechpartner, benötigte Schulungen, gewünschte Wartung nach dem Go-live.
10. Budget und Zeitplan: Grober Kostenrahmen und Wunschtermine samt fixer Stichtage, etwa ein Messetermin oder ein auslaufender Lizenzvertrag.

Zum Budget herrscht oft Unsicherheit, ob man es nennen sollte. Unsere Erfahrung: Ja. Ein genannter Rahmen ist keine Einladung, ihn auszuschöpfen, sondern die Grundlage für einen sinnvollen Zuschnitt. Anhaltspunkte für realistische Größenordnungen finden Sie in unserer Übersicht zu den Kosten bei der Beauftragung von Individualsoftware und im Kostenrechner.

Gliederungs-Vorlage zum direkten Übernehmen

Die folgende Gliederung können Sie eins zu eins in Ihr Textdokument übertragen und Kapitel für Kapitel ausfüllen. Sie deckt alle Punkte ab, die wir für ein belastbares Angebot benötigen.

Wie formuliere ich Anforderungen richtig?

Gute Anforderungen sind prüfbar, benennen eine Rolle und einen Zweck. Schlechte Anforderungen sind Adjektive. "Benutzerfreundlich", "modern" oder "schnell" lassen sich nicht kalkulieren und nicht abnehmen.

Bewährt hat sich das Format der User Story: Als [Rolle] möchte ich [Funktion], damit [Nutzen], ergänzt um ein bis drei Akzeptanzkriterien. Nehmen wir als Beispiel einen Handwerksbetrieb mit zwölf Monteuren, der seine Auftragsverwaltung von Excel und Papier auf eine eigene Anwendung umstellen möchte.

Zwei Details machen den Unterschied. Erstens die durchgehende Nummerierung: Sie erlaubt es, im Angebot und später in der Abnahme eindeutig auf eine Anforderung zu verweisen. Zweitens die Priorisierung. Kennzeichnen Sie jede Anforderung als Muss, Soll oder Kann. Damit geben Sie dem Dienstleister die Möglichkeit, ein Projekt in Stufen anzubieten, statt es an einem zu großen Gesamtpaket scheitern zu lassen.

Wie detailliert muss ein Lastenheft sein?

Für ein typisches KMU-Projekt sind 5 bis 15 Seiten ein guter Erfahrungswert. Entscheidend ist nicht die Seitenzahl, sondern ob ein fachkundiger Leser ohne Rückfragen versteht, was gebraucht wird, und daraus ein Angebot mit einer Genauigkeit von rund plus/minus 20 Prozent ableiten kann.

Als Orientierung aus unserer Praxis:

• Kleines Projekt (eine abgegrenzte Anwendung, eine bis zwei Rollen): 4 bis 6 Seiten mit rund 15 bis 25 Anforderungen.
• Mittleres Projekt (mehrere Rollen, ein bis zwei Schnittstellen, Datenmigration): 8 bis 15 Seiten mit 30 bis 60 Anforderungen.
• Großes Projekt (mehrere Abteilungen, viele Fremdsysteme): sinnvollerweise als Vorstudie mit anschließendem, detailliertem Lastenheft je Teilbereich.

Zu wenig Detail führt zu Angeboten mit dicken Risikoaufschlägen. Zu viel Detail an der falschen Stelle ist ebenfalls teuer: Wer Bildschirmmasken bis zur Feldbreite vorgibt, nimmt dem Dienstleister genau die Lösungskompetenz weg, für die er bezahlt wird. Die Faustregel lautet: Beschreiben Sie Ergebnisse und Regeln in maximaler Genauigkeit, technische Umsetzung in minimaler.

Welche Fehler kommen am häufigsten vor?

Die meisten Probleme entstehen nicht durch fehlende Kapitel, sondern durch fünf wiederkehrende Muster. Wer sie kennt, vermeidet den Großteil der späteren Nachträge.

1. Die Lösung wird vorgeschrieben statt das Problem beschrieben. Statt "Wir brauchen eine Oracle-Datenbank" gehört ins Lastenheft, welche Datenmengen und Auswertungen anfallen. Sonst bekommen Sie eine teure Lösung für ein Problem, das eventuell gar nicht existiert.
2. Der Ist-Zustand fehlt. Ohne die heutigen Abläufe, Systeme und Mengen kann niemand einschätzen, wie aufwendig Migration und Umstellung werden.
3. Schnittstellen bleiben vage. "Anbindung an unsere Warenwirtschaft" ist keine Anforderung. Nennen Sie Produkt, Version, Hersteller und ob eine dokumentierte API existiert. Fehlt sie, ist das eine der größten Kostenpositionen überhaupt.
4. Keine Priorisierung. Wenn alles "Muss" ist, gibt es keinen Verhandlungsspielraum und keine Möglichkeit, in einer ersten Stufe schnell produktiv zu werden.
5. Nur die IT schreibt mit. Ein Lastenheft ohne Beteiligung der Personen, die täglich mit dem Prozess arbeiten, beschreibt regelmäßig einen Ablauf, den es so im Betrieb nicht gibt.

Ein sechster Punkt betrifft weniger das Dokument als das Verfahren: Verschicken Sie dasselbe Lastenheft an drei bis vier Anbieter und achten Sie nicht nur auf den Preis, sondern auf die Rückfragen. Anbieter, die präzise nachfragen, haben das Dokument gelesen und verstanden. Worauf Sie bei der Auswahl sonst noch achten sollten, haben wir in unserem Beitrag zur Auswahl des passenden Dienstleisters zusammengefasst.

Häufige Fragen zum Lastenheft

Muss ich ein Lastenheft schreiben, bevor ich Angebote einhole?
Zwingend ist es nicht, aber ohne eine schriftliche Anforderungsbeschreibung sind Angebote nicht vergleichbar und enthalten hohe Sicherheitsaufschläge. Wenn Ihnen der Einstieg schwerfällt, reicht für ein erstes Gespräch auch eine Stichpunktliste; die Struktur erarbeiten wir dann gemeinsam.

Wer schreibt das Pflichtenheft, wenn ich das Lastenheft geliefert habe?
Der Dienstleister. Er überführt Ihre Anforderungen in eine konkrete Umsetzungsbeschreibung inklusive Architektur, Aufwänden und Meilensteinen. Sie geben das Pflichtenheft frei, damit wird es zur verbindlichen Grundlage für Umsetzung und Abnahme.

Passt ein Lastenheft überhaupt zu agiler Entwicklung?
Ja. Das Lastenheft beschreibt Ziel, Umfang und Prioritäten, die agile Umsetzung entscheidet über Reihenfolge und Feinschliff. In der Praxis wird das Lastenheft zur Grundlage des Backlogs, die Priorisierung nach Muss, Soll und Kann bestimmt die Reihenfolge der Ausbaustufen.

Wie lange dauert es, ein Lastenheft zu erstellen?
Für ein mittleres KMU-Projekt sollten Sie mit zwei bis vier Wochen kalendarischer Laufzeit rechnen, wobei der reine Schreibaufwand meist bei drei bis fünf Personentagen liegt. Die Zeit geht überwiegend für Abstimmungen mit den Fachabteilungen drauf, und genau diese Abstimmung ist der eigentliche Nutzen.

Was passiert, wenn sich Anforderungen während des Projekts ändern?
Das ist der Normalfall und kein Problem, solange ein definierter Umgang damit vereinbart ist. Neue Anforderungen werden bewertet, priorisiert und entweder gegen andere getauscht oder als Erweiterung beauftragt. Das Lastenheft liefert dabei die Bezugsgröße, an der sich die Änderung messen lässt.

Fazit

Ein Lastenheft ist kein bürokratisches Pflichtprogramm, sondern das günstigste Werkzeug, um ein Softwareprojekt planbar zu machen. Es klärt intern die Erwartungen, macht Angebote vergleichbar und schafft die Grundlage für eine überprüfbare Abnahme. Fünf bis fünfzehn Seiten mit nummerierten, priorisierten und prüfbaren Anforderungen genügen für die allermeisten KMU-Vorhaben vollkommen.

Wenn Sie gerade an diesem Punkt stehen: Nutzen Sie die Gliederung oben als Ausgangspunkt und bringen Sie den Entwurf mit ins Gespräch. Wir gehen ihn mit Ihnen durch, ergänzen die Lücken, die uns aus vergleichbaren Projekten bekannt sind, und geben Ihnen eine erste Einschätzung zu Aufwand und Zeitrahmen. Einen Überblick über unsere Konditionen finden Sie auf der Seite Preise, für alles Weitere erreichen Sie uns über das Kontaktformular.