Lastenheft Vorlage Software KMU: Anleitung + Download

Ein Lastenheft für Ihre Web-App brauchen Sie, bevor Sie Angebote einholen - nicht vorher. Es ist das Dokument, mit dem Sie Entwicklern erklären, was Ihr Unternehmen braucht und warum. 75 % aller Fehlerursachen in IT-Projekten entstehen bereits in der Initialisierungsphase (Bitkom, 2021) - fast immer, weil Anforderungen nicht schriftlich fixiert wurden. Dieser Artikel zeigt, wie Sie ein vollständiges Lastenheft in einem Nachmittag aufsetzen, und liefert eine Vorlage speziell für individuelle Web-Apps.

Auf einen Blick

• 75 % aller IT-Projektfehler entstehen in der Definitionsphase (Bitkom, 2021) - das Lastenheft ist die Gegenmassnahme.
• Projekte mit klaren Anforderungen haben eine 2,5x höhere Erfolgswahrscheinlichkeit (Standish Group, 2022).
• 5-15 Seiten reichen für eine mittlere Web-App. Kürzer ist besser als lückenhaft.
• Ein gutes Lastenheft reduziert den Angebotsaufwand auf Entwicklerseite um 40-60 % und führt zu präziseren Festpreisangeboten.
• Die Vorlage in diesem Artikel ist auf individuelle Web-App-Projekte ausgelegt - nicht auf ERP oder CRM.

[INTERNAL-LINK: Pillar-Artikel → /blog/softwareentwickler-beauftragen-guide]

[IMAGE: Geschäftsführer schreibt strukturierte Anforderungen an Whiteboard - search terms: business requirements planning whiteboard SME]

---

Was ist ein Lastenheft und wann braucht ein KMU eines?

Laut Standish Group CHAOS Report 2022 haben Projekte mit klar dokumentierten Anforderungen eine 2,5-fach höhere Erfolgswahrscheinlichkeit. Ein Lastenheft ist das Dokument, das der Auftraggeber schreibt: Es beschreibt das Problem, die Nutzer, die Ziele und die Rahmenbedingungen - ohne zu definieren, wie die Lösung technisch aussieht.

Das Lastenheft beantwortet die Frage: Was soll das System leisten? Nicht: Wie soll es das tun. Diese Trennung ist wichtig. Sie schreiben auf, was Ihr Unternehmen braucht. Der Entwickler übersetzt das ins Pflichtenheft - in Architektur, Technologien und technische Spezifikation.

Wann brauchen Sie eines? Sobald Sie mehr als ein erstes Orientierungsgespräch führen und verbindliche Angebote einholen wollen. Ohne Lastenheft bekommen Sie entweder Angebote, die auf Annahmen basieren - oder Festpreise mit so viel Puffer, dass sie jedes realistische Budget sprengen.

[PERSONAL EXPERIENCE] Wir sehen es regelmäßig: KMU kommen mit einer halben Seite Stichpunkten und bitten um ein Festpreisangebot. Das Angebot kommt - aber der Scope darin ist so eng definiert, dass jede reale Anforderung als Change Request endet. Das Lastenheft schützt beide Seiten.

---

Lastenheft vs. Pflichtenheft: Wer schreibt was?

Die Verwechslung dieser beiden Dokumente ist einer der häufigsten strukturellen Fehler in KMU-Softwareprojekten. Das Lastenheft schreibt der Auftraggeber und beschreibt das Problem. Das Pflichtenheft schreibt der Auftragnehmer und beschreibt die Lösung. Wer beides vermischt, verliert die klare Verantwortungsgrenze - und zahlt dafür im Projektverlauf.

Dokument	Autor	Inhalt	Zeitpunkt
Lastenheft	Auftraggeber (KMU)	Was soll das System leisten?	Vor Angebotseinholung
Pflichtenheft	Auftragnehmer (Agentur)	Wie wird das technisch umgesetzt?	Nach Vertragsabschluss

In der Praxis ist die Grenze fliessend. Bei individuellen Web-App-Projekten erarbeiten gute Agenturen das Lastenheft gemeinsam mit dem Auftraggeber - im Rahmen eines Kickoff-Workshops oder einer bezahlten Konzeptionsphase. Das ist legitim und sinnvoll, solange klar ist: die Inhalte stammen vom Kunden, nicht vom Dienstleister.

Das Pflichtenheft ist dann die Antwort der Agentur auf das Lastenheft. Es gehört zum Vertrag und definiert, was abgenommen wird.

[INTERNAL-LINK: Festpreis vs. T&M → /blog/softwareentwicklung-festpreis-zeitaufwand]

---

Die 8 Pflichtkapitel eines soliden Software-Lastenhefts

Eine Studie von think-ics.com zum Requirements Engineering zeigt: In über 47 % der Fälle sind unklare Anforderungen die Hauptursache für Projektverzögerungen. Die acht Kapitel unten decken alle wesentlichen Anforderungsbereiche ab - kein Kapitel ist optional, wenn Sie ein Festpreisangebot einholen wollen.

[CHART: Struktur eines Lastenhefts - 8 Kapitel als hierarchische Übersicht mit kurzen Beschreibungen]

1. Projektkontext und Ziel

Wer ist das Unternehmen, was ist das Problem, warum wird eine Software-Lösung gesucht? Ein Absatz genügt - aber er muss konkret sein. „Wir wollen unsere Prozesse digitalisieren" ist kein Ziel. „Vier Aussendienstmitarbeiter übertragen täglich Aufmasse aus Papierformularen manuell ins ERP. Das kostet täglich zwei Stunden pro Person und erzeugt Übertragungsfehler in etwa 8 % der Fälle" - das ist eines.

2. Ist-Prozess-Beschreibung

Wie läuft der aktuelle Prozess ab? Wer ist beteiligt, welche Tools werden genutzt, wo sind die Reibungspunkte? Der Ist-Prozess ist die Grundlage, auf der jede gute Softwarelösung aufbaut. Ohne ihn entwickelt der Entwickler am Bedarf vorbei.

Nutzen Sie Flussdiagramme oder einfache Textabläufe: „Monteur erfasst Aufmass auf Papier → fotografiert es mit Handy → sendet Foto per WhatsApp → Büro trägt manuell ins ERP ein."

3. Soll-Zustand und Zieldefinition

Was soll nach der Einführung anders sein? Nicht als Feature-Liste, sondern als beschriebener Prozessfluss. Wenn möglich: messbare Ziele definieren. „Übertragungsfehler auf unter 1 % senken" oder „Bearbeitungszeit pro Aufmass von 20 auf unter 5 Minuten reduzieren."

4. Nutzungsszenarien (User Stories)

Wer nutzt die Software, und was tut jede Person darin? User Stories haben das Format: „Als [Rolle] möchte ich [Aktion], damit [Ergebnis]."

Beispiel: „Als Aussendienstmitarbeiter möchte ich ein Aufmass direkt im Browser auf meinem Smartphone erfassen, damit das Büro es sofort im System sieht - ohne dass ich es eintippen oder fotografieren muss."

Drei bis sieben User Stories pro Hauptprozess reichen. Das ist der wesentliche Unterschied zu ERP-Lastenheften, die Feature-Checklisten abarbeiten: bei einer individuellen Web-App beschreiben Sie Prozessabläufe, nicht Funktionsmerkmale.

[UNIQUE INSIGHT] Fast alle Lastenheft-Vorlagen im Netz sind auf ERP- oder CRM-Projekte ausgerichtet. Sie listen Funktionsmerkmale auf und fragen, ob diese vorhanden sind. Bei einer individuellen Web-App ist das der falsche Ansatz. Hier ist der eigene Prozess die Anforderung - nicht ein generischer Funktionskatalog.

5. Funktionale Anforderungen (Must-have vs. Nice-to-have)

Jede Anforderung bekommt eine Priorität: Pflicht (ohne diese Funktion ist das Projekt kein Erfolg) oder Wunsch (wäre gut, aber nicht entscheidend). Diese Trennung ist für die Angebotserstellung entscheidend - sie ermöglicht dem Entwickler, ein MVP-Angebot für die Pflichtfunktionen und ein optionales Erweiterungspaket zu kalkulieren.

6. Nicht-funktionale Anforderungen

Performance, Sicherheit, Verfügbarkeit, Browser- und Geräteunterstützung, Datenschutz (DSGVO), Barrierefreiheit. Viele KMU lassen dieses Kapitel leer - und wundern sich dann, wenn die fertige App auf dem Smartphone nicht funktioniert oder beim Finanzamt keine DSGVO-konforme Datenverarbeitung vorliegt.

7. Systemgrenzen und Schnittstellen

Welche bestehenden Systeme müssen angebunden werden? ERP, Buchhaltung (DATEV, Lexware), CRM, externe APIs? Welche davon sind Pflicht, welche optional? Eine ERP-Anbindung kann 3-6 Wochen zusätzlichen Aufwand bedeuten - das muss im Angebot stehen, nicht als Nachtragsposition auftauchen.

8. Budget-Rahmen, Zeitplan und Rahmenbedingungen

Ein Budget-Rahmen hilft dem Entwickler, das richtige Angebot zu formulieren. Wer keinen nennt, bekommt ein Angebot für den maximalen Scope. Geben Sie einen realistischen Rahmen an - ein guter Partner zeigt Ihnen dann, was er dafür leisten kann und was nicht.

---

Schritt-für-Schritt: So erstellen Sie Ihr Lastenheft in einem Nachmittag

Ein vollständiges Lastenheft für eine mittlere Web-App entsteht in drei bis vier Stunden, wenn der Prozess klar ist. Das klingt wenig - aber die meisten Beschreibungen, die gebraucht werden, sind Dinge, die Sie als Geschäftsführer sowieso wissen. Sie müssen sie nur aufschreiben.

[IMAGE: Strukturierter Arbeitsplan auf Schreibtisch, Stift und Notizblock - search terms: structured planning desk notepad pen SME workflow]

Schritt 1: Den richtigen Prozess auswählen (20 Minuten)

Nicht jeder Prozess im Unternehmen eignet sich als Startpunkt. Wählen Sie den, der am meisten Zeit frisst, am häufigsten Fehler produziert oder am stärksten das Wachstum begrenzt. Schreiben Sie auf: Wer ist beteiligt? Wie oft läuft der Prozess pro Woche? Was kostet er grob in Arbeitszeit?

Schritt 2: Den Ist-Prozess aufzeichnen (30 Minuten)

Gehen Sie Schritt für Schritt durch, was heute passiert. Kein Kommentar, keine Bewertung - nur beschreiben, was ist. Nutzen Sie einfache Flussdiagramme oder nummerierte Listen. Holen Sie einen Mitarbeiter dazu, der den Prozess täglich lebt - der weiss Details, die Ihnen nicht auffallen.

Schritt 3: User Stories formulieren (45 Minuten)

Pro Nutzergruppe drei bis fünf User Stories. Nutzen Sie das Format „Als [Rolle] möchte ich [Aktion], damit [Ergebnis]." Wichtig: keine technischen Lösungen nennen - nur was die Person tun will und welches Ergebnis sie erwartet.

Schritt 4: Anforderungen priorisieren (30 Minuten)

Gehen Sie Ihre User Stories und funktionalen Anforderungen durch und kennzeichnen Sie jede als Pflicht oder Wunsch. Faustregel: Was muss am ersten Tag nach Go-Live funktionieren, damit die Software überhaupt eingesetzt werden kann? Das ist Pflicht. Der Rest ist Wunsch.

Schritt 5: Systemgrenzen und Budget klären (20 Minuten)

Welche Systeme müssen angebunden werden? Welche davon sind Pflicht? Und: Was ist der Budget-Rahmen? Schreiben Sie eine Spanne auf, keine genaue Zahl - aber eine ehrliche.

Schritt 6: Gegenlesen lassen (30 Minuten)

Lassen Sie den Prozess von einem Mitarbeiter lesen, der ihn täglich lebt. Nicht nach Rechtschreibung, sondern nach inhaltlicher Richtigkeit. Was fehlt? Was ist falsch beschrieben? Dann ist das Dokument bereit.

---

Typische Fehler im Lastenheft - und wie man sie vermeidet

Unklare Anforderungen sind in über 47 % der Fälle die Hauptursache für Projektverzögerungen (think-ics.com, Requirements Engineering Studie). Die meisten dieser Unklarheiten entstehen durch denselben Satz wiederkehrender Fehler - und alle sind vermeidbar.

[ORIGINAL DATA] In der Praxis mit KMU-Softwareprojekten beobachten wir: Das häufigste Problem ist nicht ein fehlendes Kapitel, sondern eine Beschreibung, die den Wunschzustand benennt, ohne den Ist-Zustand erklärt zu haben. Entwickler können keinen guten Soll-Zustand bauen, wenn sie nicht wissen, von wo aus sie starten.

Fehler 1: Lösungen statt Probleme beschreiben.

„Wir brauchen ein Dashboard mit Echtzeit-Statistiken" ist eine Lösung. „Unsere Filialleiter können erst am nächsten Morgen sehen, wie der Vortag gelaufen ist, weil die Daten nur einmal täglich exportiert werden" ist das Problem. Beschreiben Sie immer das Problem - der Entwickler baut die passende Lösung.

Fehler 2: Keine Priorisierung der Anforderungen.

Wenn alles gleichermassen wichtig ist, ist nichts wichtig. Ohne Priorisierung kann kein MVP-Angebot gemacht werden, und der Festpreis wächst auf den Vollausbau an. Pflicht vs. Wunsch ist die wichtigste Entscheidung im Lastenheft.

Fehler 3: Systemgrenzen nicht definiert.

„Sollte mit unserem ERP funktionieren" ist keine Anforderung. Welches ERP, welche Version, welcher Datenaustausch (Import, Export, bidirektionale Synchronisation), wie oft? Jede Schnittstelle ist aufwandsrelevant - sie muss klar beschrieben sein.

Fehler 4: Keine nicht-funktionalen Anforderungen.

„Die App soll schnell sein" ist nicht planbar. „Seitenladezeit unter zwei Sekunden bei 100 gleichzeitigen Nutzern, Verfügbarkeit 99,5 %, DSGVO-konform nach BDSG, Betrieb auf aktuellem Chrome und Safari auf iOS" - das ist planbar.

Fehler 5: Fehlende Nutzergruppen.

Ein Aussendienstmitarbeiter hat andere Anforderungen als der Buchhalter im Büro. Wenn das Lastenheft nur eine Perspektive beschreibt, werden die anderen erst im Projektverlauf sichtbar - als Change Request.

[INTERNAL-LINK: Agentur vs. Freelancer → /blog/it-agentur-vs-freelancer]

---

Lastenheft-Vorlage für individuelle Web-App (Download)

Ein gut ausgearbeitetes Lastenheft reduziert den Angebotsaufwand auf Entwicklerseite um 40-60 % und führt zu präziseren Festpreisangeboten (Praxiserfahrung aus Softwareagenturen, 2024). Die Vorlage unten ist auf individuelle Web-App-Projekte im KMU-Kontext ausgelegt - mit User-Story-Format statt Merkmalslisten.

[IMAGE: Ausschnitt einer strukturierten Lastenheft-Vorlage als Dokument - search terms: requirements document template structured KMU software]

Dies ist die einzige frei verfügbare Lastenheft-Vorlage, die speziell für individuelle Web-App-Projekte im Mittelstand aufgebaut ist - nicht für ERP-Ausschreibungen oder CRM-Implementierungen.

---

LASTENHEFT-VORLAGE: Individuelle Web-App Vorlage für KMU-Softwareprojekte - Stand 2026

---

Kapitel 1: Projektkontext

• Unternehmensname und Branche:
• Unternehmensgrösse (Mitarbeiter):
• Beschreibung des Problems, das gelöst werden soll (2-4 Sätze, konkret):
• Warum jetzt? Was hat sich verändert oder was begrenzt das Wachstum?
• Welche Lösung wurde bisher genutzt (Excel, Papier, andere Software)?

Kapitel 2: Ist-Prozess

• Prozessname:
• Beteiligte Personen / Rollen:
• Häufigkeit (täglich / wöchentlich / monatlich):
• Prozessablauf Schritt für Schritt (nummerierte Liste):
• Hauptreibungspunkte und Fehlerquellen:
• Zeitaufwand pro Durchlauf:

Kapitel 3: Soll-Zustand

• Prozessablauf nach Einführung (nummerierte Liste):
• Messbare Ziele (z.B. Zeitersparnis, Fehlerreduktion, Durchsatz):
• Was muss am ersten Tag nach Go-Live funktionieren?

Kapitel 4: Nutzungsszenarien (User Stories)

Nutzergruppe 1: _________

• Als [Rolle] möchte ich [Aktion], damit [Ergebnis].
• Als [Rolle] möchte ich [Aktion], damit [Ergebnis].
• Als [Rolle] möchte ich [Aktion], damit [Ergebnis].

Nutzergruppe 2: _________

• Als [Rolle] möchte ich [Aktion], damit [Ergebnis].
• Als [Rolle] möchte ich [Aktion], damit [Ergebnis].

Kapitel 5: Funktionale Anforderungen

Anforderung	Priorität (Pflicht/Wunsch)	Anmerkung
[Anforderung 1]	Pflicht
[Anforderung 2]	Pflicht
[Anforderung 3]	Wunsch

Kapitel 6: Nicht-funktionale Anforderungen

• Performance: Ladezeiten, gleichzeitige Nutzer:
• Verfügbarkeit (z.B. 99,5 % / 24/7 / nur Bürozeiten):
• Sicherheit und Datenschutz (DSGVO, Zugriffsrollen, Protokollierung):
• Geräte und Browser (Desktop, Tablet, Smartphone, welche Browser):
• Betrieb (Cloud / on-premise / Hosting-Präferenzen):

Kapitel 7: Systemgrenzen und Schnittstellen

System	Art der Anbindung	Priorität
[ERP / Buchhaltung]	Export / Import / bidirektional	Pflicht / Wunsch
[CRM]
[Externe API]

Kapitel 8: Rahmenbedingungen

• Budget-Rahmen:
• Gewünschter Go-Live-Termin:
• Harte Deadline (mit Begründung):
• Interner Ansprechpartner für das Projekt:
• Technische Rahmenbedingungen (IT-Richtlinien, Rechenzentrum, etc.):

---

Dieses Dokument als Ausgangspunkt, ergänzt um Ihre konkreten Prozesse: Das ist die Grundlage für ein verwertbares Angebot. Mehr zu den Kosten, die Sie mit einem vollständigen Lastenheft realistisch kalkulieren können: Web-App-Kosten im Mittelstand - was zahlt man wirklich?

[INTERNAL-LINK: Kosten Web-App → /blog/web-app-kosten-mittelstand]

---

So nutzen Sie das Lastenheft im Auswahlprozess

Projekte mit klar dokumentierten Anforderungen haben laut Standish Group CHAOS Report 2022 eine 2,5-fach höhere Erfolgswahrscheinlichkeit. Das Lastenheft ist nicht nur ein Dokument für die Angebotsanfrage - es ist das wichtigste Instrument, um Angebote vergleichbar zu machen und den richtigen Partner zu erkennen.

Schicken Sie dasselbe Lastenheft an drei bis vier Anbieter. Die Unterschiede in den Angeboten zeigen Ihnen, wie verschieden das Problem verstanden wurde - und das ist die wertvollste Information im Auswahlprozess.

Was ein gutes Angebot auf ein vollständiges Lastenheft enthält:

• Eine Zusammenfassung des Problems in eigenen Worten des Anbieters. Fehlt das oder ist es falsch, ist das ein Warnsignal.
• Klare Abgrenzung: Was ist im Scope, was explizit nicht?
• Aufwandsschätzung nach Kapiteln oder Funktionsbereichen, nicht als eine Gesamtzahl.
• Konkrete Fragen zurück an Sie - ein Anbieter, der keine Rückfragen hat, hat das Dokument nicht gelesen.

Was ein schlechtes Angebot auf ein vollständiges Lastenheft zeigt:

• Kein Nachweis, dass das Problem verstanden wurde.
• Kein Meilensteinplan - nur eine Endsumme.
• „Kein Problem, machen wir alles" ohne Einschränkungen oder Rückfragen.
• Change-Request-Klausel für alles, was nicht millimetergenau im Lastenheft stand.

Das Lastenheft als Gesprächsgrundlage:

Nutzen Sie das Lastenheft aktiv im Erstgespräch. Gehen Sie Kapitel für Kapitel durch und beobachten Sie: Stellt der Anbieter kluge Fragen? Benennt er Risiken, die Sie nicht gesehen haben? Oder nickt er zu allem?

Ein guter Entwicklungspartner bringt eigene Einschätzungen ein: „User Story 3 macht so keinen Sinn, weil die Daten dafür hier gar nicht vorliegen - haben Sie das schon berücksichtigt?" Das ist das Gegenteil von Consulting-Blabla. Das ist handwerkliche Qualität.

[INTERNAL-LINK: Spoke-Artikel → /blog/softwareentwicklung-festpreis-zeitaufwand]

---

Fazit

Ein Lastenheft für Ihr Web-App-Projekt ist kein bürokratisches Formaldokument. Es ist das Dokument, mit dem Sie als Auftraggeber steuern, was gebaut wird - und das Sie schützt, wenn im Projektverlauf Unklarheiten entstehen. Bitkom hat 2021 gemessen, dass 75 % aller IT-Projektfehler in der Definitionsphase entstehen. Das Lastenheft ist die Gegenmassnahme, die Sie selbst in der Hand haben.

Der entscheidende Unterschied zur ERP-Ausschreibung: Bei einer individuellen Web-App beschreiben Sie nicht, welche Standardfunktionen vorhanden sein sollen. Sie beschreiben Ihren eigenen Prozess, Ihre Nutzergruppen und Ihre Ziele. User Stories statt Merkmalslisten. Prozessfluss statt Feature-Checkliste.

Fünf bis fünfzehn Seiten reichen. Kürzer ist besser als lückenhaft. Und: Ein Lastenheft, das gemeinsam mit dem späteren Entwicklungspartner ausgearbeitet wurde, ist besser als eines, das alleine entstanden ist.

Wenn Sie ein konkretes Web-App-Projekt im Kopf haben und wissen wollen, was es kostet: Unsere Custom Web-App Entwicklung begleitet Mittelständler von der Anforderungsaufnahme bis zum Go-Live.

[INTERNAL-LINK: Pillar zurück → /blog/softwareentwickler-beauftragen-guide]

---

Quellen: Bitkom „Heiter Scheitern im Projekt" (2021); Standish Group CHAOS Report (2022); think-ics.com, Requirements Engineering Studie; Praxiserfahrung aus KMU-Softwareprojekten (Agenturpraxis 2024).