Lastenheft für Software erstellen: Aufbau, Beispiele und Checkliste
Ein Lastenheft für Software erstellen: mit Aufbau, Beispielen, Muss-Anforderungen und prüfbaren Nachweisen. Eine praktische Vorlage für Ihre Auswahl.

Ein Lastenheft für Software beschreibt, welche Ergebnisse und Rahmenbedingungen Ihr Unternehmen benötigt. Es ordnet Anforderungen nach Prozess, Rolle, Priorität und prüfbarem Nachweis. Für den Vergleich sollten Anbieter dieselbe Fassung erhalten und ihre konkrete Edition sowie Standardfunktion, Konfiguration, Zusatzmodul oder Entwicklung nennen.
Inhalt dieses Beitrags
Wozu dient ein Software-Lastenheft?
Ein Lastenheft macht unterschiedliche Erwartungen im Unternehmen sichtbar. Vertrieb, Service, Finanzabteilung und IT meinen mit „einem gemeinsamen System“ häufig verschiedene Dinge. Beschreiben Sie deshalb zuerst die benötigten Abläufe und Ergebnisse. Die konkrete Umsetzung wird anschließend mit dem Anbieter geklärt.
Die Bezeichnungen in Projekten unterscheiden sich. Für diese Auswahlhilfe beschreibt das Lastenheft den Bedarf des Auftraggebers; die angebotene Umsetzung muss dazu nachvollziehbar Stellung nehmen. Entscheidend ist nicht der Dokumenttitel, sondern die Verbindung zwischen Anforderung, Angebot und späterem Nachweis.
„Das CRM soll benutzerfreundlich sein“ ist kaum vergleichbar. „Ein Vertriebsmitarbeiter legt eine Anfrage an, weist sie einer Vertretung zu und findet die nächste Aktion in seiner Aufgabenliste“ beschreibt dagegen Rolle, Ablauf und erwartetes Ergebnis.
Welche Inhalte gehören in das Lastenheft?
- Ausgangslage und Ziel: Problem, gewünschte Verbesserung und bewusste Abgrenzung.
- Prozesse und Rollen: normale Aufgaben, Übergaben und wichtige Ausnahmen.
- Daten: führende Systeme, Datenqualität, Migration und Export.
- Schnittstellen: Richtung, Datenumfang, Häufigkeit und Fehlerbehandlung.
- Betrieb und Betreuung: Zugänge, Verantwortlichkeiten, Support und Änderungen.
- Einführung: Test, Schulung, Abnahme und verfügbare interne Zeit.
Beginnen Sie mit Anforderungen, die die Entscheidung tatsächlich beeinflussen. Eine umfangreiche Sammlung allgemeiner Funktionen kann die kritischen Punkte verdecken. Ergänzen Sie Details dort, wo Daten, Schnittstellen oder betriebliche Abhängigkeiten dies erfordern.
Lassen Sie die Anforderungen von den späteren Prozessverantwortlichen prüfen. Die IT kann technische Voraussetzungen beurteilen; ob ein Geschäftsprozess brauchbar ist, entscheidet sie nicht allein.
So formulieren Sie eine überprüfbare Anforderung
Eine gute Anforderung enthält eine Rolle, eine Aufgabe und eine erkennbare Auswirkung. Ergänzen Sie Priorität und Nachweis. Vermeiden Sie mehrere voneinander unabhängige Forderungen in einer Zeile, denn sonst lässt sich ein teilweise erfüllter Punkt kaum auswerten.
| Allgemeiner Wunsch | Präzisere Anforderung | Nachweis |
|---|---|---|
| Gute Integration | Freigegebene Kundenstammdaten werden an das Zielsystem übertragen; Fehler werden einem Verantwortlichen angezeigt. | Testdatensatz übertragen und einen Fehler auslösen. |
| Passende Rechte | Eine Vertriebsrolle sieht die zugewiesenen Vorgänge, darf aber keine Systemeinstellungen ändern. | Mit der betreffenden Rolle anmelden und erlaubte sowie gesperrte Aktionen prüfen. |
| Schnelle Suche | Ein Servicemitarbeiter findet anhand einer bekannten Kennung den richtigen Vorgang im vereinbarten Datenbestand. | Suche mit repräsentativer Datenmenge und vereinbartem Akzeptanzmaß durchführen. |
Legen Sie konkrete Mengen und Zeiten gemeinsam fest, wenn sie für Ihr Vorhaben wichtig sind. Erfinden Sie keine beliebigen Grenzwerte nur, damit das Lastenheft messbar aussieht. Der Wert muss zur Aufgabe und zur geplanten Belastung passen.
Eine kompakte Vorlage für Ihre Anforderungsliste
| ID und Verantwortung | Anforderung und Priorität | Nachweis und Status |
|---|---|---|
| CRM-01 · Vertrieb | Jede offene Chance hat einen Eigentümer und eine Folgeaktion. Muss. | Demo mit Übergabe; Edition, Datum und Ergebnis notieren. |
| INT-02 · Finance und IT | Freigegebene Rechnungsdaten werden kontrolliert übertragen. Muss. | Test mit dem angebotenen Connector; offene Voraussetzung festhalten. |
| ADM-03 · Fachadministration | Eine Teamleitung kann einem neuen Mitglied die vereinbarte Rolle zuweisen. Wunsch. | Eigener Nutzertest; benötigte Anleitung dokumentieren. |
Ergänzen Sie Spalten für Edition, Umsetzung, einmalige und laufende Kosten sowie den Bezug zur Angebotsposition. Halten Sie die Hauptfrage lesbar: Was muss funktionieren, warum und welcher Nachweis fehlt?
Nummerieren und versionieren Sie Anforderungen. So lässt sich später erkennen, ob eine Aussage in der Demo tatsächlich zur Fassung im Angebot gehört. Änderungen am Umfang brauchen eine bewusste Entscheidung und eine neue Zuordnung.
Muss-Anforderungen und Wünsche unterschiedlich bewerten
Eine unverzichtbare Anforderung kann nicht durch viele angenehme Zusatzfunktionen ersetzt werden. Prüfen Sie diese Punkte zuerst. Für Wünsche reicht häufig eine einfache Skala, wenn die Bewertung begründet und vor der Demo vereinbart wird.
Bitten Sie Anbieter je Zeile um eine eindeutige Antwort: Standard, Konfiguration, Zusatzmodul, Entwicklung oder nicht vorgesehen. Ein „ja“ ohne Edition und Bedingungen ist noch nicht ausreichend. Prüfen Sie insbesondere, wer eine zusätzliche Lösung betreibt und bei Updates betreut.
Ein Anbieter zeigt eine umfassende Suite, ein anderer nur einen Basistarif. Beide markieren dieselben Anforderungen als erfüllbar. Erst wenn Module, Einrichtung und Kosten zugeordnet sind, lässt sich beurteilen, ob die Angebote denselben Bedarf abdecken.
Vom Lastenheft zum Test und zur Abnahme
Bündeln Sie zusammengehörige Anforderungen in wenigen Praxisfällen. Verwenden Sie fiktive Daten und mindestens eine Ausnahme. Speichern Sie die Ergebnisse bei den betreffenden Anforderungen und lassen Sie offene Fragen durch die zuständigen Personen bearbeiten.
Für Cloud-Anforderungen bietet die BSI-Checkliste zur Dienstwahl ergänzende Prüffragen. Sie ersetzt nicht die eigene Prozess- und Risikoanalyse. Verbinden Sie die relevanten Punkte mit dem angebotenen Betrieb und den Zuständigkeiten.
Der Auswahlprozess in sieben Schritten zeigt, wie diese Liste mit Demo, Angebot und Einführung zusammengeführt wird.
Häufige Fragen
Wie umfangreich muss ein Lastenheft für Software sein?
Es muss die Unterschiede und Risiken Ihrer Auswahl überprüfbar machen. Beginnen Sie mit den wichtigsten Prozessen und Muss-Anforderungen. Ergänzen Sie Details bei Schnittstellen, Datenübernahme, Rechten und betrieblichen Abhängigkeiten.
Was unterscheidet Lastenheft und Pflichtenheft?
In dieser Auswahlhilfe beschreibt das Lastenheft den Bedarf des Auftraggebers. Die angebotene Umsetzung muss dazu konkret Stellung nehmen; sie wird häufig in einem Pflichtenheft beschrieben. Stimmen Sie im Projekt ab, welche Dokumente verbindlich gelten und wie Anforderungen zugeordnet werden.
Reicht ein ausgefüllter Anbieterfragebogen?
Ein Fragebogen sammelt Aussagen. Ergänzen Sie Demos, Dokumentation und bei Bedarf eigene Tests. Halten Sie fest, welche Aussage nachgewiesen ist und welche Edition, Konfiguration oder Zusatzleistung dafür erforderlich ist.
Quellen und Einordnung
Redaktion: Softwarematch. Inhalt und Quellen geprüft am . Die Praxisbeispiele sind fiktiv. Produktinformationen und Tarife können sich ändern; prüfen Sie die angebotene Edition und Bedingungen beim Anbieter.