Lastenheft für Software­projekte: Aufbau und Checkliste

Drei Angebote für dasselbe Softwareprojekt – und die Preise liegen weit auseinander. Das liegt selten an unseriösen Anbietern, sondern meist daran, dass jeder etwas anderes verstanden hat. Ein gutes Lastenheft für Softwareprojekte sorgt dafür, dass alle über dasselbe sprechen: Sie, der Dienstleister und später die Nutzer.

In diesem Beitrag erklären wir den Unterschied zwischen Lastenheft und Pflichtenheft, zeigen den bewährten Aufbau und geben Ihnen eine Checkliste an die Hand, mit der Sie belastbare Angebote erhalten.

Lastenheft und Pflichtenheft: der Unterschied

Das Lastenheft beschreibt aus Sicht des Auftraggebers, was die Software leisten soll und warum. Es enthält Ziele, Anforderungen und Rahmenbedingungen. Die Norm DIN 69901-5 definiert es als die vom Auftraggeber festgelegte Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Auftragnehmers.

Das Pflichtenheft ist die Antwort des Auftragnehmers. Es beschreibt, wie die Anforderungen umgesetzt werden: mit welcher Architektur, welchen Technologien und welchen Lösungswegen. Kurz gesagt: Das Lastenheft schreiben Sie, das Pflichtenheft entsteht gemeinsam mit dem Entwicklungspartner.

Warum sich ein gutes Lastenheft auszahlt

• Vergleichbare Angebote: Alle Anbieter kalkulieren auf derselben Grundlage.
• Festpreis wird möglich: Je klarer der Umfang, desto verlässlicher lässt sich ein Festpreis kalkulieren.
• Weniger Nachträge: Was beschrieben ist, wird später nicht zur Überraschung.
• Klare Abnahme: Sie können prüfen, ob das Ergebnis den Anforderungen entspricht.
• Interne Klarheit: Schon das Schreiben zwingt dazu, offene Fragen im eigenen Haus zu klären.

Der Aufbau eines Lastenhefts

Ein Lastenheft muss kein dickes Dokument sein. Für viele mittelständische Projekte genügen wenige, gut strukturierte Seiten. Bewährt hat sich diese Gliederung:

1. Ausgangslage und Ziele

Wie läuft der Prozess heute, wo liegen die Probleme, und was soll sich durch die Software ändern? Formulieren Sie überprüfbare Ziele, etwa „Angebote sollen ohne manuelles Abtippen erstellt werden“.

2. Nutzergruppen und Rollen

Wer arbeitet mit der Software, und was darf wer? Innendienst, Außendienst, Kunden, Administratoren – jede Gruppe hat eigene Aufgaben und Rechte.

3. Funktionale Anforderungen

Was soll die Software konkret können? Bewährt hat sich die Form von User Stories: „Als Disponent möchte ich Aufträge per Drag-and-drop einem Techniker zuweisen, damit ich die Tagesplanung schneller erstelle.“ So wird nicht nur die Funktion klar, sondern auch ihr Zweck.

4. Nicht-funktionale Anforderungen

Wie gut muss die Software sein? Dazu zählen Antwortzeiten, Verfügbarkeit, Sicherheit, Datenschutz, Barrierefreiheit, unterstützte Geräte und Browser sowie Vorgaben zum Hosting.

5. Schnittstellen und Daten

Mit welchen Systemen muss die Software Daten austauschen – ERP, CRM, Buchhaltung, Shop? Welche Bestandsdaten sollen übernommen werden, und in welchem Format liegen sie vor?

6. Mengengerüst

Wie viele Nutzer, Datensätze, Dokumente oder Transaktionen sind heute und in einigen Jahren zu erwarten? Diese Zahlen beeinflussen Architektur und Kosten erheblich.

7. Rahmenbedingungen

Gewünschter Zeitrahmen, Budgetrahmen, Ansprechpartner, interne Ressourcen für Tests und Abnahme sowie vorhandene technische Vorgaben.

Viele Auftraggeber scheuen sich, einen Budgetrahmen zu nennen – aus Sorge, dass er dann voll ausgeschöpft wird. Dabei hilft ein Rahmen allen Beteiligten: Anbieter können Lösungen vorschlagen, die dazu passen, statt im Blindflug zu kalkulieren. Und Sie erhalten Angebote, die realistisch statt geschönt sind.

8. Abnahmekriterien

Woran erkennen Sie, dass eine Anforderung erfüllt ist? Legen Sie Kriterien fest, die sich prüfen lassen – idealerweise mit konkreten Testfällen.

Ein Beispiel aus der Praxis

Wie konkret eine gute Anforderung sein sollte, zeigt ein Vergleich. Unklar formuliert: „Das System soll Aufträge verwalten.“ Gut formuliert: „Der Innendienst legt Aufträge mit Kunde, Leistung, Wunschtermin und Anhängen an. Jeder Auftrag hat einen Status – neu, geplant, erledigt, abgerechnet. Beim Wechsel auf ‚erledigt‘ erhält die Buchhaltung automatisch eine Aufgabe zur Rechnungsstellung.“

Die zweite Variante ist länger, aber jeder Entwickler versteht sie gleich. Genau darin liegt der Wert: Missverständnisse werden vor dem Projekt ausgeräumt, nicht danach.

Priorisieren mit Muss, Soll und Kann

Nicht jede Anforderung ist gleich wichtig. Kennzeichnen Sie jede Anforderung als Muss, Soll oder Kann. Muss-Anforderungen bilden die erste Version, Soll-Anforderungen folgen bei verfügbarem Budget, Kann-Anforderungen sind Ideen für später. Diese Einteilung macht Angebote flexibel und schützt vor einem überladenen ersten Release.

Lastenheft und agile Entwicklung – ein Widerspruch?

Agile Entwicklung lebt davon, Anforderungen im Projekt zu schärfen. Ein Lastenheft steht dem nicht im Weg. Es beschreibt Ziele, Rahmen und die wichtigsten Anforderungen – die Details werden dann in kurzen Etappen gemeinsam ausgearbeitet. So verbinden Sie Planungssicherheit mit der Freiheit, auf neue Erkenntnisse zu reagieren.

Typische Fehler im Lastenheft

• Lösungen statt Anforderungen: „Wir brauchen eine Tabelle mit zwölf Spalten“ statt „Wir müssen Aufträge nach Status filtern können“.
• Unklare Begriffe: „schnell“, „einfach“, „modern“ – ohne Maßstab nicht prüfbar.
• Fehlende Sonderfälle: Was passiert bei Stornierungen, Teillieferungen oder Vertretungen?
• Nutzer nicht gefragt: Wer die Software täglich nutzt, kennt die Stolpersteine am besten.
• Alles ist Muss: Ohne Prioritäten wird die erste Version zu groß.

Kein Lastenheft? Kein Problem

Viele Unternehmen haben weder Zeit noch Erfahrung, ein vollständiges Lastenheft zu schreiben. Das ist kein Hindernis. Im kostenlosen Erstgespräch und auf Wunsch in einem anschließenden Workshop erarbeiten wir die Anforderungen gemeinsam mit Ihnen und halten sie in einem klaren Konzept fest. Diese technische Beratung ist oft der wirtschaftlichste Einstieg, weil sie spätere Missverständnisse verhindert.

Checkliste: Ist Ihr Lastenheft vollständig?

• Ausgangslage und überprüfbare Ziele beschrieben
• alle Nutzergruppen und Rollen benannt
• funktionale Anforderungen als User Stories formuliert
• nicht-funktionale Anforderungen festgelegt
• Schnittstellen und Datenübernahme beschrieben
• Mengengerüst für heute und morgen angegeben
• Zeit- und Budgetrahmen genannt
• Anforderungen nach Muss, Soll und Kann priorisiert
• prüfbare Abnahmekriterien definiert

Fazit

Ein gutes Lastenheft ist die beste Versicherung für Ihr Softwareprojekt: Es macht Angebote vergleichbar, ermöglicht Festpreise und sorgt für eine klare Abnahme. Ob Sie mit einem fertigen Dokument kommen oder mit einer ersten Idee – wir übersetzen Ihre Anforderungen in ein umsetzbares Konzept und begleiten Sie in der Softwareentwicklung bis zum laufenden System. Für Vorhaben, die exakt zu Ihren Abläufen passen müssen, lesen Sie mehr über unsere Individualsoftware.