Lastenheft für Software: Aufbau, Beispiel und Vorlage

Ein Lastenheft beschreibt, was eine Software leisten soll — aus Sicht dessen, der sie bestellt. Wer eine Lastenheft-Vorlage für Software sucht, will meist zwei Dinge: eine Gliederung, an der man sich entlanghangeln kann, und ein Gefühl dafür, wie konkret die einzelnen Punkte sein müssen. Beides finden Sie hier: acht Abschnitte, ein durchgehendes Beispiel für ein Kundenportal, eine Vorlage zum Kopieren und eine Liste der Dinge, die im Lastenheft nichts verloren haben.

Was ein Lastenheft ist — und was es nicht ist

Das Lastenheft ist das Dokument des Auftraggebers. Es hält fest, welches Problem gelöst werden soll, wer mit der Software arbeitet, welche Aufgaben sie übernimmt und woran Sie am Ende erkennen, dass das Ergebnis passt. Es sagt bewusst nicht, mit welcher Technik das geschieht. Das ist Sache des Auftragnehmers, der auf Basis Ihres Lastenhefts ein Pflichtenheft schreibt: Dort steht, wie er Ihre Anforderungen umsetzen will. Beide Begriffe sind in der DIN 69901-5 zum Projektmanagement festgelegt.

Die Faustregel lautet deshalb: Lastenheft = was und wofür, Pflichtenheft = wie und womit. Wer beides in ein Dokument mischt, legt sich zu früh auf Lösungen fest und nimmt dem Dienstleister die Möglichkeit, einen einfacheren Weg vorzuschlagen.

Ein gutes Lastenheft ist auch kein Roman. Für eine überschaubare Web-Anwendung reichen oft zehn bis zwanzig Seiten. Entscheidend ist nicht der Umfang, sondern ob ein Außenstehender nach dem Lesen versteht, was Ihr Betrieb heute tut, wo es hakt und was sich ändern soll.

Lastenheft für Software: die acht Abschnitte im Überblick

Die folgende Gliederung hat sich für Individualsoftware und Web-Anwendungen im Mittelstand bewährt. Sie können Abschnitte zusammenlegen, sollten aber keinen ersatzlos streichen.

Beim Ausfüllen helfen die klassischen W-Fragen: Wer macht was, wann, womit und warum? Wenn Sie für einen Abschnitt keine Antwort haben, ist das kein Fehler — schreiben Sie „offen“ hinein. Eine ehrliche Lücke ist wertvoller als eine geratene Angabe, auf die später ein ganzes Angebot aufbaut.

Lastenheft-Beispiel: ein Kundenportal, Abschnitt für Abschnitt

Hinweis: Das folgende Beispiel ist ausgedacht. Es zeigt einen Großhändler für Sanitärbedarf, der ein Kundenportal für seine Handwerksbetriebe möchte. Firma, Abläufe und Zahlen dienen nur der Veranschaulichung.

1. Ausgangslage und Ziel

Beispiel: Unsere Kunden bestellen per Telefon, Fax und E-Mail. Der Innendienst tippt jede Bestellung von Hand ins Warenwirtschaftssystem und beantwortet täglich viele Rückfragen zu Lieferstatus und Rechnungen. Ziel: Stammkunden bestellen selbst, sehen ihre Lieferungen und laden Rechnungen herunter. Der Innendienst soll sich um Beratung und Sonderfälle kümmern, nicht um Abtippen.

2. Ist-Zustand

Beispiel: Bestellung kommt rein → Innendienst prüft Kundennummer und Preise → Erfassung im Warenwirtschaftssystem → Lager bekommt Kommissionierliste → Versand → Rechnung per Post oder PDF. Medienbrüche: Fax und Telefon, Rückfragen zum Lieferstatus laufen komplett über Anrufe.

Wer diesen Abschnitt sauber haben will, macht vorher eine kurze Prozessanalyse. Oft zeigt sich dabei, dass das eigentliche Problem woanders liegt, als alle gedacht hatten.

3. Nutzer und Rollen

Beispiel: Inhaber eines Kundenbetriebs (sieht alles, verwaltet Mitarbeiterzugänge) · Monteur (bestellt, sieht keine Preise) · Buchhaltung des Kunden (sieht nur Rechnungen) · Innendienst beim Großhändler (sieht alle Kunden, kann Bestellungen korrigieren) · Administrator.

4. Funktionale Anforderungen

Beispiel:

• F-01: Ein Kunde kann Artikel über Suche und Artikelnummer finden und in einen Warenkorb legen.
• F-02: Der Kunde sieht seine individuellen Preise, sofern seine Rolle das erlaubt.
• F-03: Nach dem Absenden landet die Bestellung ohne manuelle Erfassung im Warenwirtschaftssystem.
• F-04: Der Kunde sieht den Status jeder Bestellung: eingegangen, kommissioniert, versendet.
• F-05: Rechnungen der letzten drei Jahre stehen als PDF zum Download bereit.

5. Daten und Schnittstellen

Beispiel: Artikelstamm, Kundenpreise und Rechnungen liegen im Warenwirtschaftssystem und bleiben dort führend. Das Portal liest sie über eine API und schreibt nur Bestellungen zurück. Der Versanddienstleister liefert Sendungsnummern per Datei oder Schnittstelle.

6. Nicht-funktionale Anforderungen

Beispiel: Nutzbar auf dem Smartphone auf der Baustelle · Server in Deutschland · Anmeldung mit persönlichem Zugang, keine Sammel-Passwörter · Die Artikelsuche liefert auch bei schwachem Mobilfunk in höchstens drei Sekunden Ergebnisse.

7. Rahmenbedingungen

Beispiel: Start mit zwanzig Pilotkunden vor der Hauptsaison · Das bestehende Warenwirtschaftssystem wird nicht ersetzt · Ansprechpartnerin im Haus: Leitung Innendienst.

8. Abnahmekriterien

Beispiel: Ein Pilotkunde kann ohne Hilfe eine Bestellung aufgeben, die im Warenwirtschaftssystem korrekt ankommt. Ein Monteur-Zugang zeigt keine Preise. Eine Rechnung aus dem Vorjahr lässt sich herunterladen.

User Stories oder klassische Anforderungen?

Viele Teams arbeiten heute agil, etwa nach Scrum, und formulieren Anforderungen als User Stories: „Als Monteur möchte ich eine Bestellung vom Handy aus aufgeben, damit ich nicht ins Büro fahren muss.“ Das klassische Lastenheft nummeriert dagegen Anforderungen wie F-01 bis F-05 oben. Beides hat seinen Platz.

In der Praxis funktioniert eine Mischung am besten: Die Oberfläche und die Abläufe beschreiben Sie als User Stories, jeweils mit zwei bis drei Akzeptanzkriterien. Schnittstellen, Rechte und rechtliche Vorgaben halten Sie als nummerierte Anforderungen fest. So bekommt der Dienstleister beides — das Warum und die prüfbare Grenze.

Anforderungen an Software formulieren: sechs Regeln

1. Eine Anforderung, ein Satz. „Der Kunde kann bestellen und Rechnungen sehen und Nutzer verwalten“ sind drei Anforderungen. Getrennt lassen sie sich schätzen, priorisieren und abnehmen.
2. Prüfbar schreiben. „Das Portal soll schnell sein“ kann niemand abnehmen. „Die Artikelsuche zeigt Ergebnisse, während der Nutzer tippt“ schon.
3. Muss, soll, kann unterscheiden. Markieren Sie jede Anforderung. So sieht der Dienstleister sofort, was in die erste Version gehört und was warten kann.
4. Die Rolle nennen. Nicht „man kann Preise sehen“, sondern „der Inhaber sieht Preise, der Monteur nicht“.
5. Ausnahmen aufschreiben. Was passiert, wenn ein Artikel ausverkauft ist? Wenn ein Kunde gesperrt ist? Die Sonderfälle kosten in der Entwicklung oft mehr als der Normalfall.
6. Begriffe einmal festlegen. Wenn „Auftrag“, „Bestellung“ und „Order“ im Dokument dasselbe meinen, legen Sie ein kleines Glossar an und bleiben bei einem Wort.

Was nicht ins Lastenheft gehört

• Technische Vorgaben ohne Grund. „Muss mit Framework X gebaut werden“ gehört nur hinein, wenn Ihre eigene IT es später selbst betreuen will. Sonst schreiben Sie das Ziel dahinter auf.
• Bildschirmentwürfe als Pflicht. Skizzen helfen, aber als verbindliche Vorgabe blockieren sie bessere Bedienkonzepte.
• Wunschlisten ohne Priorität. Zwanzig gleichrangige „Muss“-Punkte machen jedes Angebot teuer und jeden Zeitplan unrealistisch.
• Interne Befindlichkeiten. Welche Abteilung sich mit welcher streitet, gehört ins Gespräch, nicht ins Dokument.
• Kopierte Floskeln. „Benutzerfreundlich, modern und skalierbar“ steht in jedem Lastenheft und hilft keinem.

Lastenheft-Vorlage zum Kopieren

Die folgende Vorlage können Sie direkt in Ihr Textprogramm übernehmen. Die Fragen in Klammern ersetzen Sie durch Ihre Antworten.

LASTENHEFT – [Projektname]
Version: [Nr.] · Stand: [Datum] · Verantwortlich: [Name, Funktion]

1. AUSGANGSLAGE UND ZIEL
   1.1 Anlass: [Welches Problem besteht heute?]
   1.2 Ziel: [Was soll nach der Einführung anders sein?]
   1.3 Erfolgskennzahl: [Woran messen wir das? Falls unbekannt: offen]

2. IST-ZUSTAND
   2.1 Heutiger Ablauf: [Schritt für Schritt, wer macht was]
   2.2 Eingesetzte Werkzeuge: [Programme, Listen, Papier]
   2.3 Schwachstellen: [Doppelerfassung, Wartezeiten, Fehlerquellen]

3. NUTZER UND ROLLEN
   [Rolle] – [Aufgaben] – [darf sehen] – [darf ändern]

4. FUNKTIONALE ANFORDERUNGEN
   F-01 [Anforderung] – Priorität: Muss / Soll / Kann
        Akzeptanzkriterium: [Woran erkennen wir, dass es erfüllt ist?]
   F-02 ...

5. DATEN UND SCHNITTSTELLEN
   5.1 Führende Systeme: [Wo liegen welche Daten?]
   5.2 Schnittstellen: [System – Richtung – Häufigkeit]
   5.3 Datenübernahme: [Welche Altdaten müssen übernommen werden?]

6. NICHT-FUNKTIONALE ANFORDERUNGEN
   6.1 Geräte und Nutzungsort
   6.2 Datenschutz und Serverstandort
   6.3 Verfügbarkeit und Reaktionszeiten
   6.4 Barrierefreiheit
   6.5 Sprachen

7. RAHMENBEDINGUNGEN
   7.1 Zeitplan und feste Termine
   7.2 Budgetrahmen
   7.3 Vorhandene Systeme, die bleiben
   7.4 Ansprechpartner und Entscheider

8. ABNAHMEKRITERIEN
   [Testfall] – [erwartetes Ergebnis] – [wer nimmt ab]

ANHANG
   Glossar · Beispieldokumente · Skizzen (unverbindlich)

Checkliste, bevor Sie das Lastenheft verschicken

• Hat jemand außerhalb des Projektteams den Text gelesen und verstanden?
• Ist jede funktionale Anforderung nummeriert und mit Muss, Soll oder Kann markiert?
• Hat jede Muss-Anforderung ein Akzeptanzkriterium?
• Sind alle Rollen und ihre Rechte beschrieben?
• Steht bei jeder Schnittstelle, welches System führend ist?
• Sind offene Punkte als „offen“ markiert statt geraten?
• Gibt es eine Versionsnummer und einen Verantwortlichen?

Wie es nach dem Lastenheft weitergeht

Mit dem Lastenheft holen Sie Angebote ein oder gehen ins Erstgespräch mit einem Dienstleister. Ein seriöser Anbieter stellt danach Rückfragen — viele davon zu den Sonderfällen und Schnittstellen. Das ist ein gutes Zeichen: Wer ohne eine einzige Frage einen Festpreis nennt, hat das Dokument vermutlich nicht gründlich gelesen.

Aus den Muss-Anforderungen entsteht oft zuerst ein MVP, also eine erste nutzbare Version. Die Soll- und Kann-Punkte folgen in weiteren Ausbaustufen. Steht eine alte Anwendung im Weg, lohnt ein eigener Abschnitt dazu, was vom Altsystem bleiben muss. Und falls Sie noch überlegen, ob überhaupt eine Eigenentwicklung nötig ist, hilft unser Vergleich Individualsoftware oder Standardsoftware.

Wie wir Aufwände abrechnen, sehen Sie auf der Seite Preise. Was wir aus einem Lastenheft bauen, zeigt die Seite Web-Anwendungen.

Häufige Fragen

Wer schreibt das Lastenheft?

Der Auftraggeber, also Ihr Unternehmen. Sie können sich dabei helfen lassen, etwa durch einen Workshop mit dem späteren Dienstleister. Die fachlichen Inhalte müssen aber von den Menschen kommen, die den Ablauf heute kennen.

Wie lang sollte ein Lastenheft sein?

So kurz wie möglich, so lang wie nötig. Für eine überschaubare Anwendung genügen oft zehn bis zwanzig Seiten. Wichtiger als die Länge: Jede Muss-Anforderung ist prüfbar.

Brauche ich bei agiler Entwicklung überhaupt ein Lastenheft?

Ja, aber ein schlankeres. Ziel, Rollen, Schnittstellen und Rahmenbedingungen ändern sich im Sprint selten. Die Details der Bedienung dürfen sich dagegen im Projekt entwickeln — dafür eignen sich User Stories im Backlog.

Was ist der Unterschied zwischen Lastenheft und Pflichtenheft?

Das Lastenheft beschreibt, was Sie brauchen. Das Pflichtenheft beschreibt, wie der Auftragnehmer es umsetzt. Die ausführliche Erklärung finden Sie im Lexikonartikel zum Pflichtenheft.

Darf ich eine Lastenheft-Vorlage aus dem Internet einfach übernehmen?

Als Gliederung ja. Die Inhalte müssen aber Ihre sein. Ein Lastenheft, das sich wie ein Muster liest, führt zu Angeboten, die ebenfalls nur ein Muster sind.

Was, wenn sich Anforderungen während des Projekts ändern?

Das ist normal. Halten Sie Änderungen mit Versionsnummer fest und klären Sie mit dem Dienstleister, wie Mehraufwand abgestimmt wird, bevor die Arbeit daran beginnt.

Sie haben ein Lastenheft — oder erst eine Idee?

Schicken Sie uns, was Sie haben: ein fertiges Dokument, eine Stichpunktliste oder eine Beschreibung Ihres heutigen Ablaufs. Wir lesen es, stellen die Rückfragen, die für ein belastbares Angebot nötig sind, und sagen Ihnen offen, was wir für die erste Version empfehlen. Mehr zu unserer Arbeitsweise finden Sie unter Individualsoftware, oder Sie vereinbaren direkt ein kostenfreies Erstgespräch.