Lastenheft erstellen: Aufbau, Beispiele & kostenlose Vorlage (IT/Software)

Ein Lastenheft ist die Grundlage dafür, dass Angebote vergleichbar, Entscheidungen nachvollziehbar und Projekte abnahmefähig werden. Es beschreibt aus Auftraggeber-Sicht, was erreicht werden soll – nicht, wie der Anbieter es technisch löst. Genau diese Trennung sorgt später für weniger Reibung, weniger Change Requests und deutlich bessere Planbarkeit.

Lastenheft – Definition, Zweck und Nutzen

Ein Lastenheft bündelt Ziele, Anforderungen und Rahmenbedingungen eines Projekts aus Sicht des Auftraggebers. Es dient als gemeinsame Referenz für alle Beteiligten: Fachbereich, IT, Einkauf, Security und externe Anbieter.
Der Nutzen ist praktisch: Wer ein sauberes Lastenheft hat, bekommt schneller belastbare Angebote, reduziert Projektrisiken und kann die Abnahme anhand klarer Kriterien durchführen.

Typische Einsatzfälle in IT/Tech-Projekten

• Software- oder App-Entwicklung (neu / Erweiterung)
• Einführung von SaaS/ERP/CRM
• Website-/Portal-Relaunch
• Managed Services / Betrieb / Support-Outsourcing
• Data-/BI-Projekte, Schnittstellen- und Integrationsvorhaben
• Security- und Compliance-Projekte

Lastenheft vs. Pflichtenheft

Merksatz: Im Lastenheft steht das Problem, im Pflichtenheft die Lösung.

Lastenheft-Aufbau: bewährte Gliederung für IT/Software

Du musst nicht „perfekt“ starten – aber du solltest vollständig und testbar sein. Diese Struktur ist in der Praxis bewährt und deckt die häufigsten Anforderungen in IT-Projekten ab.

1) Projektüberblick und Ausgangslage

• Hintergrund, Motivation, Ist-Zustand
• betroffene Teams/Standorte/Prozesse
• aktuelle Systeme (Tools, Plattformen, Datenquellen)

Praxis-Tipp: Ein kurzer „Ist-Zustand“-Abschnitt verhindert später, dass Anbieter Annahmen treffen, die nicht stimmen.

2) Ziele und Erfolgskriterien

• Business-Ziele (z. B. Time-to-Quote senken, Support entlasten)
• messbare KPIs (z. B. Durchlaufzeit, Conversion, SLA-Erfüllung)
• Erfolgskriterien für Go-Live

Beispiel (messbar):

• „Die Bearbeitungszeit für Angebotsanfragen sinkt von Ø 48h auf Ø 12h innerhalb von 3 Monaten nach Go-Live.“

3) Scope und Abgrenzung

• In Scope (was gehört sicher dazu?)
• Out of Scope (was ausdrücklich nicht?)
• MVP vs. spätere Releases

Warum das wichtig ist: Der schnellste Weg zu Budget- und Terminproblemen ist ein unklarer Scope.

4) Stakeholder, Rollen und Nutzergruppen

• Nutzerrollen (z. B. Admin, Editor, Sales, Support)
• Verantwortlichkeiten (Product Owner, IT, Security, Einkauf)
• grobe Nutzerzahlen/Lastannahmen

5) Funktionale Anforderungen (MUSS/SOLL/KANN)

• Anforderungen als Liste oder nach Use Cases strukturiert
• Priorität + Akzeptanzkriterium je Anforderung

Beispiel (funktional):

• F-01 (MUSS): Nutzer können sich per SSO (SAML/OIDC) anmelden.
  Akzeptanzkriterium: Login über Unternehmens-IdP funktioniert für Rollen A/B, inkl. automatischer Rollen-Zuordnung.

6) Nicht-funktionale Anforderungen (NFR) – IT-praxisnah

Hier entscheidet sich oft, ob ein Projekt später „läuft“ oder „brennt“. NFRs sollten messbar sein.

Typische NFR-Kategorien mit Beispiel-Formulierungen

• Performance: „95% der Requests beantworten sich innerhalb von 2 Sekunden bei 500 gleichzeitigen Nutzern.“
• Verfügbarkeit: „Monatsverfügbarkeit ≥ 99,9% (ausgenommen geplante Wartung).“
• Security: „MFA für Admins verpflichtend; Rollen-/Rechtekonzept nach Least Privilege.“
• Datenschutz (DSGVO): „Auftragsverarbeitung möglich; Löschkonzept inkl. Fristen; Datenminimierung.“
• Betrieb/Monitoring: „Zentrales Logging, Alerting bei Fehlerquote > X; definierte On-Call-Regelung.“

• Backup/Recovery: „RPO 24h, RTO 4h für Kernfunktionen.“

7) Schnittstellen und Daten

• Drittsysteme (ERP, CRM, IAM, DWH, Ticketing)
• Datenobjekte (Kunden, Verträge, Tickets, Produkte)
• API-/Import-/Export-Anforderungen
• Datenmigration (Umfang, Qualität, Mapping)

8) Rahmenbedingungen und Constraints

• Cloud/On-Prem, Region (DACH/EU), Compliance-Vorgaben
• unterstützte Browser/Devices
• technologische Vorgaben (falls zwingend) – aber nicht übersteuern

9) Lieferumfang, Meilensteine und Abnahme

• Deliverables (z. B. Doku, Schulung, Betriebshandbuch)
• grober Terminplan (Discovery → Umsetzung → Go-Live)
• Abnahmeprozess + Kriterien

Beispiel (Abnahme):

• „Abnahme erfolgt nach erfolgreich bestandenem UAT anhand definierter Testfälle; kritische Bugs = 0, hohe Bugs ≤ 3.“

10) Anforderungen an den Anbieter

Damit Angebote vergleichbar werden:

• Referenzen (ähnliche Projekte, Branche, Größe)
• Projektvorgehen (Discovery, Iterationen, QA)
• Teamsetup (Rollen, Seniorität, Verfügbarkeit)
• Support-/Wartungsmodell (SLAs, Reaktionszeiten)

Die richtige Detailtiefe: Faustregeln + typische Fehler

Zu vage ist teurer als du denkst – Anbieter kalkulieren Risikoaufschläge oder liefern „irgendwas“.
Zu detailliert wird schnell zum Pflichtenheft und blockiert Lösungsinnovation.

Faustregeln

• Beschreibe Ergebnisse, nicht Implementierungen.
• Standard-Funktionen kurz, Differenzierer detailliert.
• Für jede Muss-Anforderung: Akzeptanzkriterium ergänzen.
• NFRs immer mit Zahlen/Schwellen formulieren.

Anti-Patterns

• „Das System soll modern und schnell sein.“ (nicht testbar)
• „Wir nutzen Tool X und Framework Y.“ (Lösung vorweggenommen)
• „Kann später ergänzt werden.“ (Scope creep in 1 Satz)

Lösungsneutral formulieren: „Was/Wofür“ statt „Wie/Womit“

Schlecht (vorgreifend):

• „Die Lösung muss mit Kubernetes betrieben werden.“

Besser (zielorientiert):

• „Die Lösung muss in einer Container-Umgebung betrieben werden können und skalierbar sein; Betriebskonzept inkl. Monitoring ist zu liefern.“

So bekommen Anbieter Spielraum, aber du behältst die Kontrolle über Anforderungen und Abnahme.

Schritt-für-Schritt: So erstellst du ein Lastenheft (7 Schritte)

1. Kickoff & Zielbild (Warum? Was ist Erfolg?)
2. Stakeholder-Interviews (Fachbereich, IT, Security, Einkauf)
3. Use Cases sammeln (Top 10–20 Prozesse/User Journeys)
4. Anforderungen strukturieren (MUSS/SOLL/KANN)
5. NFR-Workshop (Performance, Security, Betrieb, DSGVO)
6. Review & Konsens (Widersprüche raus, Glossar klären)
7. Freigabe + Versionierung (Change-Prozess festlegen)

Lastenheft-Checkliste

Damit du sofort starten kannst, sollte eine gute Vorlage drei Dinge leisten:

1. klare Struktur (damit nichts fehlt)
2. Felder für Priorität & Akzeptanzkriterien
3. Platz für NFRs, Schnittstellen und Abnahme

Checkliste „Ready for Anbieterbriefing“

• Ziele messbar definiert
• Scope klar (In/Out) + MVP
• Muss-Anforderungen priorisiert
• NFRs messbar (nicht nur Kategorien)
• Schnittstellen & Datenquellen benannt
• Abnahmeprozess & Kriterien definiert
• Ansprechpartner + Entscheidungsweg klar

Lastenheft Beispiel (IT/Software):

Beispiel-Use-Case

UC-03: Ticket-Erstellung durch Fachbereich

• Nutzer erstellt Ticket mit Kategorie, Priorität, Anhängen
• Ticket wird automatisch geroutet (Team/Queue) und bestätigt
• Status-Updates sind für Nutzer sichtbar

Beispiel-Anforderungen (funktional)

• F-07 (MUSS): Tickets müssen Kategorien und Prioritäten enthalten.
  Akzeptanzkriterium: Ohne Kategorie/Priorität ist Speichern nicht möglich.
• F-08 (SOLL): Automatisches Routing nach Kategorie.
  Akzeptanzkriterium: Kategorie „IT-Access“ landet standardmäßig in Queue „IAM“.

Beispiel-NFRs (messbar)

• NFR-02: 95% der Ticket-Anlagen < 2 Sekunden bei 300 gleichzeitigen Nutzern.
• NFR-05: Audit-Log für Admin-Aktionen, Aufbewahrung 180 Tage.

Beispiel-Akzeptanzkriterien (Given/When/Then)

• Given ein Nutzer ist eingeloggt, When er ein Ticket mit Pflichtfeldern speichert, Then erhält er eine Bestätigung inkl. Ticket-ID innerhalb von 2 Sekunden.

Von Lastenheft zur passenden Anbieter-Shortlist

Ein Lastenheft ist nicht nur ein Dokument – es ist dein Werkzeug, um Anbieter vergleichbar zu machen.

Pragmatischer Ablauf

• Lastenheft finalisieren (Version 1.0)
• an Anbieter senden + Rückfragen bündeln
• Angebote anhand fester Kriterien vergleichen
• Workshop/Demo mit Shortlist (2–4 Anbieter)
• Pflichtenheft + finaler Scope + Vertragsabschluss

Scoring-Kriterien (Auszug)

• Fachliche Passung (Use Cases, Branchenwissen)
• NFR-Fähigkeit (Security, Betrieb, SLA)
• Integrationskompetenz (APIs, Migration)
• Vorgehen & Projektsetup (Discovery, QA, PM)
• Total Cost of Ownership (nicht nur Tagessätze)
• Referenzen & Team-Seniorität

IT-Concierge-Service

Falls ihr den Auswahlprozess nicht allein stemmen wollt, kann ein Concierge-Service sinnvoll sein: Aus eurem Lastenheft (oder einem Entwurf) lassen sich Kriterien ableiten, Anbieter vorqualifizieren und Angebote besser vergleichen. Damit reduziert ihr den Aufwand im Screening deutlich und fokussiert euch früh auf eine kleine, passende Shortlist.