Lastenheft erstellen: Schritt für Schritt

Eine Software soll neu eingeführt, abgelöst oder erweitert werden, und nun werden belastbare Angebote gebraucht. Genau dafür ist ein Lastenheft da: Es beschreibt Ziele, Anforderungen und Rahmenbedingungen aus Sicht des Auftraggebers. Wenn Sie so ein Dokument zum ersten Mal schreiben, muss es nicht perfekt klingen. Es soll vor allem für Rückfragen, Vergleichbarkeit und Entscheidungen taugen.

Dieser Beitrag zeigt Ihnen das praktische Vorgehen beim Schreiben, nicht technische Details für Entwickler. Wenn Sie stattdessen eine vollständige Gliederung suchen, finden Sie in der Lastenheft-Vorlage mit Aufbau und Inhalten die passende Struktur.

Warum sich ein Lastenheft vor der Angebotsanfrage lohnt

Ohne klar beschriebene Anforderungen sind Angebote oft nur schwer vergleichbar. Der Grund ist einfach: Jeder Anbieter ergänzt gedanklich etwas anderes, setzt andere Schwerpunkte und kalkuliert auf einer anderen Annahmebasis. Das erschwert Entscheidungen schon zu Beginn.

Ein Lastenheft macht deshalb vor den ersten Gesprächen greifbar,

• welches Ziel die Software erfüllen soll,
• was zum Projektumfang gehört,
• welche Erwartungen an Ergebnis und Zusammenarbeit bestehen.

Das reduziert Missverständnisse früh. Gleichzeitig hilft das Dokument intern: Fachabteilung, IT und Entscheidungsträger arbeiten mit demselben Bild auf das Vorhaben. Gerade bei Projekten rund um individuelle Software und Betrieb ist das ein wichtiger Vorteil.

Wichtig ist dabei: Es zählen nicht nur Funktionen. Auch Nutzergruppen, Schnittstellen, Daten, Berichte, Zugriffe und der spätere Betrieb beeinflussen die Angebotsanfrage. Und selbst wenn noch nicht jedes Detail feststeht, lohnt sich das Schreiben. Offene Punkte dürfen im Lastenheft ausdrücklich als offen markiert werden.

Wenn Sie zunächst nur eine grobe Größenordnung benötigen, können Sie vorab den Kostenrechner für eine erste Spanne nutzen. Für die eigentliche Anfrage hilft außerdem der Beitrag zur Software-Ausschreibung.

Schritt für Schritt: So schreiben Sie Ihr Lastenheft

Gehen Sie beim Schreiben nicht von Funktionen aus, sondern von Ihrem Vorhaben. So entsteht ein Dokument, das für Angebote und Rückfragen wirklich nutzbar ist. Wenn Sie zusätzlich ein praktisches Muster sehen möchten, hilft auch das Beispiel für Inhalte eines Lastenhefts.

Schritt 1: Ziele festhalten

Schreiben Sie zuerst auf, welches Problem gelöst werden soll. Geht es darum, einen bisherigen Ablauf zu vereinfachen, eine alte Lösung abzulösen oder einen bestehenden Prozess zu erweitern? Benennen Sie den Anlass kurz und eindeutig: Neuentwicklung, Ablösung oder Erweiterung.

Hilfreich sind dabei drei einfache Fragen:

• Welches Problem besteht heute?
• Welchen Nutzen soll die neue Software bringen?
• Woran wäre intern erkennbar, dass das Vorhaben gelungen ist?

Solche Ziele machen Ihr Lastenheft klarer. Statt nur zu schreiben, dass „eine neue Anwendung benötigt wird“, beschreiben Sie besser, was sich fachlich verbessern soll, zum Beispiel weniger Doppelerfassung, schnellere Freigaben oder ein einheitlicher Datenstand.

Schritt 2: Nutzer und Rollen beschreiben

Im nächsten Schritt halten Sie fest, wer mit der Software arbeitet und in welcher Form. Denken Sie dabei nicht nur an die Menschen, die Daten eingeben. Oft gibt es auch Personen, die nur prüfen, freigeben, auswerten oder die Anwendung administrieren.

Eine Rolle bündelt ähnliche Rechte und Aufgaben, damit Anforderungen nicht pro Person beschrieben werden müssen.

Typische Rollen können zum Beispiel sein:

• Sachbearbeitung
• Teamleitung
• Fachliche Freigabe
• Auswertung oder Controlling
• Administration

Diese Unterscheidung hilft später, Zugriffe und Abläufe verständlich zu beschreiben. Gerade wenn mehrere Bereiche beteiligt sind, macht das Ihr Lastenheft deutlich belastbarer.

Schritt 3: Den heutigen Prozess dokumentieren

Beschreiben Sie nun kurz, wie die Aufgabe heute erledigt wird. Dafür reichen oft wenige Absätze oder eine einfache Schrittfolge. Wichtig ist nicht die perfekte Darstellung, sondern ein realistisches Bild des Ist-Zustands.

Notieren Sie dabei vor allem,

• wo Excel-Listen genutzt werden,
• welche Informationen per E-Mail weitergegeben werden,
• an welchen Stellen Daten doppelt erfasst werden,
• wo Rückfragen, Wartezeiten oder Medienbrüche entstehen.

Genau dieser Ist-Prozess ist wichtig, weil Anbieter daraus Risiken, Vereinfachungen und sinnvolle Prioritäten ableiten können. Viele spätere Änderungen entstehen nicht durch fehlende Funktionen, sondern weil der bisherige Ablauf anfangs zu grob beschrieben wurde. Wenn Sie dieses Thema weiter vertiefen möchten, finden Sie im Beitrag zu nachträglichen Anforderungsänderungen eine hilfreiche Einordnung.

Schritt 4: Funktionale Anforderungen formulieren

Erst danach sollten Sie die eigentlichen Anforderungen an die Software aufschreiben. Funktionale Anforderungen sind die konkreten Fähigkeiten, die die Software bereitstellen soll.

Für Erstverfasser ist eine einfache Form besonders praktikabel:

• Als [Rolle] möchte ich [Ziel], damit [Nutzen].

Beispiele wären etwa:

• Als Sachbearbeitung möchte ich Vorgänge anlegen, damit Anfragen zentral erfasst sind.
• Als Teamleitung möchte ich Einträge freigeben, damit Änderungen geprüft nachvollziehbar werden.
• Als Auswertung möchte ich Berichte exportieren, damit ich Daten weiterverwenden kann.

Diese Form zwingt nicht zu technischem Detailwissen, macht Anforderungen aber trotzdem greifbar. Wenn aus Ihrem Lastenheft später ein Umsetzungsplan werden soll, zeigt das Pflichtenheft-Beispiel, wie daraus der nächste Schritt entstehen kann. Und wenn Sie aus Ihrem Entwurf eine strukturierte Rückmeldung mit offenen Fragen ableiten möchten, ist der Projekt-Check ein sinnvoller nächster Schritt.

Wer beteiligt sein sollte und wie Sie die Arbeit organisieren

Schreiben Sie ein Lastenheft möglichst nicht allein. Sinnvoll ist, Fachabteilung, IT, Projektverantwortliche und die Stelle einzubeziehen, die am Ende Ziele, Prioritäten und Freigaben verantwortet.

Jede dieser Gruppen bringt eine andere Sicht ein:

• Fachbereiche kennen Abläufe, Sonderfälle und praktische Hürden im Alltag.
• IT kennt bestehende Systeme, Schnittstellen und technische Randbedingungen.
• Entscheider sorgen dafür, dass Ziele, Prioritäten und Umfang zusammenpassen.

Wichtig ist dabei eine klare Verantwortung. Eine Person sollte die Inhalte sammeln, strukturieren und zu einem einheitlichen Dokument zusammenführen. Sonst entsteht leicht ein Sammelstand aus Einzelbeiträgen, der Lücken, Widersprüche oder Dopplungen enthält.

Praktisch hat sich ein einfaches Vorgehen bewährt: Klären Sie zuerst in einem Termin Ziele und Ist-Prozess. Bündeln Sie danach die Anforderungen schriftlich. Prüfen Sie in einer zweiten Runde gezielt offene Punkte, fehlende Prioritäten und unklare Begriffe.

Arbeiten Sie dabei mit konkreten Beispielen aus dem Alltag, etwa typischen Fällen, Formularen, Listen oder Berichten. Solche Unterlagen machen Anforderungen oft schneller verständlich als abstrakte Beschreibungen.

Frühe Abstimmungen helfen erfahrungsgemäß, spätere Change Requests zu verringern. Ein Change Request ist eine nachträgliche Anforderungsänderung im Projekt. Bei komplexeren Vorhaben kann außerdem ein früher Prototyp sinnvoll sein, um Abläufe vor der Umsetzung zu schärfen.

Lastenheft und Pflichtenheft: Wer schreibt was?

Das Lastenheft beschreibt aus Sicht des Auftraggebers, was gebraucht wird und warum. Es hält also die fachlichen Ziele, Anforderungen und Rahmenbedingungen fest.

Das Pflichtenheft ist darauf aufbauend die Antwort des Anbieters. Es beschreibt, wie die Anforderungen umgesetzt werden sollen und wie das Vorgehen im Projekt konkret aussieht.

Diese Trennung ist nützlich, weil die fachliche Sicht zunächst verständlich und unabhängig von einer technischen Lösung bleibt. Erst im nächsten Schritt werden Umsetzung, Struktur und Vorgehen genauer ausgearbeitet.

Wichtig für Erstverfasser: Ein gutes Lastenheft muss noch keine technische Architektur vorwegnehmen. Sie müssen also nicht schon alle Umsetzungsentscheidungen kennen.

Wenn Anbieter Rückfragen stellen, ist das daher kein Zeichen für ein schlechtes Lastenheft, sondern Teil der Präzisierung. Wie beide Dokumente zusammenspielen, zeigt das Pflichtenheft-Beispiel.

Häufige Lücken im Lastenheft – und wie Sie sie schließen

Typische Lücken entstehen nicht nur durch fehlende Funktionen, sondern oft schon früher im Denken über das Projekt. Wenn Sie eine Software richtig planen möchten, helfen vor allem diese Punkte:

• Zu frühe Lösung statt Problem: Beschreiben Sie erst fachliche Ziele und den heutigen Prozess, bevor Sie einzelne Funktionen oder Technologien festlegen.
• Unklare Begriffe: Definieren Sie zentrale Begriffe wie Vorgang, Fall, Kunde, Standort oder Maßnahme kurz und einheitlich.
• Fehlende Prioritäten: Lange Wunschlisten ohne Gewichtung erschweren die Vergleichbarkeit von Angeboten.
• Vergessene Randbedingungen: Denken Sie an Benutzeranmeldung, bestehende Microsoft-365-Umgebung, Datenmigration, Berichte, Dokumente oder mobile Nutzung.
• Nicht beschriebene Schnittstellen: Angebundene Systeme beeinflussen Aufwand und Risiken oft stark.
• Fehlende Prüfbarkeit: Ergänzen Sie wichtige Anforderungen um Akzeptanzkriterien, also um konkrete Merkmale, an denen die Erfüllung erkennbar ist.
• Wachstum nicht mitgedacht: Nachhaltig geplante Software erleichtert spätere Erweiterungen und hilft, technische Schulden zu vermeiden. Technische Schulden sind spätere Mehrarbeit durch kurzfristige, unzureichend tragfähige Lösungen.

Bei ballmüller solutions zeigt sich in Projekten wie einer Webplattform zur Verwaltung von Kanalnetz, Zuständen und Maßnahmen oder einem CRM regelmäßig: Saubere Anforderungen erleichtern spätere Abstimmungen.