Lastenheft: Ein Shop-Projekt sauber ausschreiben

Ein Shop-Projekt scheitert selten an der Technik. Es scheitert daran, dass vor der Vergabe niemand aufgeschrieben hat, was am Ende herauskommen soll. Genau dafür gibt es das Lastenheft: die Beschreibung dessen, was Sie brauchen, in Ihren Worten, vor dem ersten Angebot. Wer es sorgfältig schreibt, bekommt vergleichbare Angebote statt grober Hausnummern und findet Lücken, solange sie noch nichts kosten. Eine Untersuchung von 2002 (NIST) zeigt, warum das so viel ausmacht: Ein Fehler, der erst in der Integrationsphase auffällt, kostet zehnmal so viel wie derselbe Fehler in der Anforderungsphase. Dieser Leitfaden zeigt, wie ein Lastenheft für einen Online-Shop aufgebaut ist, wie sich Muss- von Kann-Anforderungen trennen lassen und woran Sie erkennen, dass eine Anforderung prüfbar formuliert ist.

Lastenheft und Pflichtenheft: zwei Dokumente, zwei Verfasser

Die beiden Begriffe werden im Alltag durcheinandergeworfen, obwohl sie zwei verschiedene Rollen abbilden. Das Lastenheft schreibt der Auftraggeber. Es beschreibt die Aufgabe: welches Problem gelöst werden soll, unter welchen Bedingungen, mit welchen Daten, für welche Nutzer. Es enthält bewusst keine Lösung. Das Pflichtenheft schreibt der Auftragnehmer, nachdem er den Zuschlag bekommen hat. Es beschreibt, wie die Aufgabe gelöst wird: Systemarchitektur, Datenmodell, Abläufe, Verantwortlichkeiten, Zeitplan. Das Lastenheft fragt, das Pflichtenheft antwortet. Wer beides in ein Dokument presst, verliert die Vergleichbarkeit: Sobald eine technische Lösung vorgegeben ist, können die Anbieter nur noch den Preis für diese eine Lösung nennen, nicht mehr ihren eigenen Weg vorschlagen.

Wie stark eine gute Aufgabenbeschreibung wiegt, zeigt das Vergaberecht. Für öffentliche Auftraggeber heißt das Lastenheft Leistungsbeschreibung, und der Gesetzgeber sagt genau, wozu sie da ist: In der Leistungsbeschreibung ist der Auftragsgegenstand so eindeutig wie möglich zu beschreiben, sodass die Beschreibung für alle Unternehmen im gleichen Sinne verständlich ist und die Angebote miteinander verglichen werden können (GWB). Dieser Satz ist auch für private Auftraggeber die beste Kurzfassung dessen, was ein Lastenheft leisten muss. Wenn zwei Anbieter Ihr Dokument unterschiedlich verstehen, sind ihre Angebote nicht vergleichbar, und der Preisunterschied sagt nichts über die Leistung aus.

In der Praxis entsteht daraus eine saubere Kette: Lastenheft ausschreiben, Angebote vergleichen, Zuschlag erteilen, Pflichtenheft erstellen lassen, Pflichtenheft freigeben, umsetzen, abnehmen. Jede Stufe hat ein Ergebnis, das die nächste braucht. Wer die erste Stufe überspringt und direkt nach einem Angebot fragt, bekommt ein Angebot auf eine Aufgabe, die der Anbieter sich selbst zusammengereimt hat. Unsere Beratung und Konzeption setzt genau hier an: Das Lastenheft entsteht mit dem Fachbereich, nicht im Anschluss an eine bereits gewählte Technik.

Was in ein Lastenheft gehört

Ein Lastenheft ist kein Roman und keine Stichwortliste. Es ist ein durchnummeriertes Dokument, in dem jede Anforderung eine eigene Kennung trägt, damit man in Rückfragen, Angeboten und später in der Abnahme auf sie zeigen kann. Der Gesetzgeber beschreibt den inhaltlichen Kern knapp: Die Leistungsbeschreibung enthält die Funktions- oder Leistungsanforderungen oder eine Beschreibung der zu lösenden Aufgabe, deren Kenntnis für die Erstellung des Angebots erforderlich ist, sowie die Umstände und Bedingungen der Leistungserbringung (GWB). Übersetzt heißt das: Aufgabe, Anforderungen und Rahmenbedingungen, sonst nichts.

1. Ausgangslage: Was gibt es heute, welche Systeme laufen, welche Zahlen beschreiben den Betrieb (Bestellungen pro Tag, Artikel, Kundengruppen, Sprachen, Länder).
2. Ziel des Vorhabens: Was soll nach der Umsetzung anders sein, gemessen woran. Ein Ziel ohne Messgröße ist ein Wunsch.
3. Abgrenzung: Was ausdrücklich nicht Teil des Projekts ist. Dieser Abschnitt spart später die meisten Diskussionen.
4. Rollen und Nutzer: Wer arbeitet mit dem System, mit welchen Rechten, in welchem Umfang.
5. Fachliche Anforderungen: nummeriert, priorisiert, einzeln prüfbar.
6. Daten und Schnittstellen: welche Systeme Daten liefern, welche sie empfangen, in welcher Richtung, in welchem Takt.
7. Datenübernahme: welche Bestände aus dem Altsystem mitkommen und in welcher Qualität sie heute vorliegen.
8. Nichtfunktionale Anforderungen: Tempo, Verfügbarkeit, Barrierefreiheit, Sicherheit, Datenschutz, Betrieb.
9. Rahmenbedingungen: Termine, Budgetrahmen, Freigabewege, Ansprechpartner, Mitwirkungspflichten des Auftraggebers.
10. Abnahme: wie geprüft wird, wer prüft, was als erfüllt gilt und was passiert, wenn eine Anforderung nicht erfüllt ist.

Der Umfang hängt am Vorhaben. Ein Relaunch mit unveränderten Prozessen kommt mit 15 bis 25 Seiten aus, ein Shop mit ERP-Anbindung, Kundengruppen und Marktplatzanschluss braucht eher das Doppelte. Wichtiger als die Seitenzahl ist die Trennschärfe: Jede Anforderung steht einmal, an einer Stelle, mit einer Kennung. Wenn dieselbe Forderung an drei Stellen in leicht verschiedenen Worten steht, entstehen drei Auslegungen. Wie ein solches Dokument in die Projektplanung eingebettet wird, beschreibt unser Beitrag zur Planung eines Website-Relaunches.

Muss, Soll und Kann: Prioritäten, die tragen

Ohne Priorisierung ist jedes Lastenheft eine Wunschliste, und jede Wunschliste wird im Angebot zum Höchstpreis. Drei Stufen genügen, und sie müssen scharf definiert sein, bevor die erste Anforderung eingeordnet wird. Entscheidend ist nicht die Zahl der Stufen, sondern dass jede Stufe eine Konsequenz hat: Eine Muss-Anforderung entscheidet über die Abnahme, eine Kann-Anforderung nicht.

Der häufigste Fehler ist die Inflation der obersten Stufe. Wenn 90 Prozent aller Anforderungen als Muss markiert sind, hat die Markierung keine Aussage mehr, und der Anbieter kalkuliert einen Risikoaufschlag auf alles. Eine brauchbare Faustregel aus der Projektpraxis: Höchstens die Hälfte der Anforderungen trägt die Stufe Muss, und jede davon lässt sich in einem Satz begründen. Wer diese Begründung nicht formulieren kann, hat eine Soll-Anforderung vor sich.

• Begründen Sie jede Muss-Anforderung mit dem Schaden, der ohne sie entsteht: Umsatzausfall, Rechtsverstoß, Handarbeit im Tagesgeschäft.
• Bepreisen Sie Kann-Anforderungen getrennt. Ein Angebot mit einer Optionsliste lässt sich vergleichen, ein Pauschalpreis mit Wunschliste nicht.
• Halten Sie fest, wer die Stufe ändern darf. Ohne diese Regel wandert im Projektverlauf jede Soll-Anforderung nach oben.
• Prüfen Sie die Verteilung, bevor Sie versenden: Wie viele Muss-, Soll- und Kann-Anforderungen enthält das Dokument tatsächlich?
• Markieren Sie Anforderungen, die von einer anderen abhängen. Eine Muss-Anforderung, die auf einer Kann-Anforderung aufsetzt, ist ein Widerspruch.

Anforderungen prüfbar formulieren

Eine Anforderung ist prüfbar, wenn zwei Menschen unabhängig voneinander zum selben Ergebnis kommen, wenn sie sie testen. Das klingt banal, fällt aber bei der Hälfte aller Sätze in typischen Lastenheften durch. Sätze wie benutzerfreundlich, performant, modern oder intuitiv sind keine Anforderungen, sondern Stimmungen. Sie lassen sich nicht abnehmen, und sie lassen sich auch nicht bepreisen: Der Anbieter kalkuliert entweder zu knapp und streitet später, oder er kalkuliert den schlimmsten Fall und ist zu teuer.

• Ein Akteur: Wer löst die Funktion aus, ein Kunde, ein Mitarbeiter, ein System?
• Ein Auslöser: Was passiert vorher, damit die Funktion greift?
• Ein Ergebnis: Was liegt danach vor, und wo kann man es sehen?
• Eine Messgröße: Menge, Dauer, Format, Anzahl, Schwellwert.
• Eine Randbedingung: Was gilt, wenn der Normalfall nicht eintritt?
• Eine Quelle: Welche Vorschrift, welcher Prozess, welche Rolle fordert das?

Die rechte Spalte ist länger, und das ist der Punkt. Jede zusätzliche Zeile im Lastenheft spart Klärungsaufwand in der Umsetzung. Der Zusammenhang ist gut belegt: Ein Fehler, der in der Anforderungsphase entsteht und dort gefunden wird, kostet eine Einheit; wird derselbe Fehler erst in der Integration entdeckt, kostet die Korrektur das Zehnfache (NIST). Auf nationaler Ebene beziffert dieselbe Untersuchung von 2002 die jährlichen Kosten einer unzureichenden Infrastruktur für Softwaretests in den Vereinigten Staaten auf 22,2 bis 59,5 Milliarden US-Dollar (NIST).

id: A-014
titel: Bestellimport in das ERP
stufe: muss
akteur: Shopsystem
ereignis: Zahlung ist bestätigt
ergebnis: Auftrag liegt im ERP mit Positionen, Preisen und Lieferadresse
messwert:
  frist_minuten: 15
  grundlage: Zeitstempel der Zahlungsbestätigung
randbedingung:
  - ERP nicht erreichbar: Wiederholung nach 1, 5 und 15 Minuten
  - nach drei Fehlversuchen: Eintrag im Protokoll und E-Mail an den Betrieb
abnahme:
  - 20 Testbestellungen, davon 3 mit abweichender Lieferadresse
  - Nachweis über Protokollauszug mit Bestell- und Auftragsnummer
quelle: Prozess Auftragsabwicklung, Abschnitt 3.2

Ob Sie strukturierte Dateien, eine Tabelle oder durchnummerierte Absätze verwenden, ist zweitrangig. Entscheidend ist, dass jede Anforderung dieselben Felder hat, damit beim Vergleich der Angebote nichts stillschweigend fehlt. Anforderungen, die so geschrieben sind, lassen sich später direkt in Testfälle übersetzen; wie das automatisiert aussieht, zeigt unser Beitrag zur E2E-Testautomatisierung für Online-Shops.

Schnittstellen und Datenübernahme vorab klären

Der größte Kostenblock in Shop-Projekten steckt selten im Shop. Er steckt an den Rändern: im Warenwirtschaftssystem, in der Buchhaltung, im Versand, im Produktdatenmanagement. Wer Schnittstellen im Lastenheft mit einem Satz abhandelt, verlagert die teuerste Unbekannte in die Umsetzung. Jede Schnittstelle braucht eine eigene Beschreibung mit Richtung, Takt, Datenumfang, Schlüsselfeld und Fehlerverhalten. Für die Anbindung an DATEV gilt das genauso wie für den Bestandsabgleich mit einem Marktplatz.

• Richtung und Führung: Welches System führt welches Feld? Der Preis kommt aus dem ERP, die Beschreibung aus dem Produktdatensystem, der Bestand aus dem Lager. Konflikte werden vorab entschieden, nicht im Betrieb.
• Takt und Menge: Alle fünf Minuten, stündlich, täglich? Wie viele Datensätze je Lauf, wie groß ist der Erstabgleich?
• Schlüsselfeld: Woran erkennen beide Systeme denselben Datensatz? Ohne stabilen Schlüssel entstehen Doubletten, und der Abgleich lässt sich nicht wiederholen.
• Fehlerverhalten: Was passiert bei Zeitüberschreitung, bei ungültigen Daten, bei doppelter Übergabe? Wer wird benachrichtigt und wie oft?
• Zugang und Umgebung: Gibt es ein Testsystem, wer stellt Zugänge, ab wann? Ein Testsystem, das erst nach Projektstart entsteht, verschiebt jeden Termin.
• Datenqualität heute: Wie viele Artikel haben eine gepflegte EAN, wie viele Kunden eine gültige Rechnungsadresse? Diese Zahlen gehören in das Lastenheft, nicht in die erste Projektwoche. Der Beitrag zur ERP-Integration von Shopware und SAP zeigt, woran solche Anbindungen typischerweise hängen.

Bei der Datenübernahme lohnt sich derselbe Blick. Nennen Sie Mengen statt Adjektive: Anzahl der Artikel, Varianten, Bilder, Kunden, Bestellungen, Bewertungen, Umleitungen. Legen Sie fest, welche Historie mitkommt und welche im Altsystem verbleibt. Und schreiben Sie auf, was mit Daten geschieht, die die Prüfung nicht bestehen: Werden sie abgewiesen, korrigiert oder in eine Nachbearbeitungsliste geschrieben? Für Projekte mit Kundengruppen und Preislisten hält unsere Seite zum B2B-E-Commerce die typischen Sonderfälle fest.

Nichtfunktionale Anforderungen: Tempo, Barrierefreiheit, Betrieb

Nichtfunktionale Anforderungen beschreiben, wie gut etwas funktioniert, nicht was es tut. Sie fallen im Lastenheft am häufigsten unter den Tisch und verursachen später die unangenehmsten Nachverhandlungen. Beim Tempo hilft ein Blick auf den Bestand: Im Jahr 2025 erreichten 48 Prozent der mobilen Websites und 56 Prozent der Desktop-Auftritte gute Werte in den Core Web Vitals (HTTP Archive Web Almanac). Bei der Serverantwortzeit liegt der Anteil mit guten Werten auf Mobilgeräten bei 44 Prozent (HTTP Archive Web Almanac). Wer im Lastenheft Zielwerte nennt, verschiebt diese Diskussion vor die Vergabe, wo sie hingehört.

• Tempo: Zielwerte je Seitentyp, gemessen mit einem definierten Geräteprofil und einer definierten Anzahl Wiederholungen. Unsere Seite zur PageSpeed-Optimierung nennt die üblichen Messpunkte.
• Verfügbarkeit: Zielwert im Monat, Wartungsfenster, Reaktionszeiten nach Schwere der Störung.
• Barrierefreiheit: Konformitätsstufe, geprüft an einer benannten Liste von Seitentypen, mit Nachweis.
• Sicherheit: Rollen- und Rechtekonzept, Umgang mit Zugangsdaten, Protokollierung, Aufbewahrungsfristen.
• Datenschutz: Verzeichnis der Verarbeitungstätigkeiten, Auftragsverarbeitung, Löschkonzept, Einwilligungen.
• Betrieb: Wer aktualisiert, wer sichert, wie lange werden Sicherungen aufbewahrt, wie wird eine Wiederherstellung geprobt?

Barrierefreiheit ist seit dem Barrierefreiheitsstärkungsgesetz keine Kür mehr. Das Gesetz gilt für Dienstleistungen im elektronischen Geschäftsverkehr, die für Verbraucher nach dem 28. Juni 2025 erbracht werden (BFSG), und es formuliert die Pflicht knapp: Produkte, die ein Wirtschaftsakteur auf dem Markt bereitstellt und Dienstleistungen, die er anbietet oder erbringt, müssen barrierefrei sein (BFSG). Auch das Vergaberecht kennt diesen Gedanken seit Langem: Bei Leistungen zur Nutzung durch natürliche Personen sind bei der Erstellung der Leistungsbeschreibung außer in begründeten Fällen die Zugänglichkeitskriterien für Menschen mit Behinderungen zu berücksichtigen (GWB). Unsere Seite zur BFSG-Optimierung ordnet die Anforderungen ein, und der Beitrag zu barrierefreien Rechnungen und Datenblättern zeigt, dass die Pflicht nicht an der Seitenkante endet.

Wie groß der Abstand zwischen Anspruch und Bestand ist, zeigt die jährliche Auswertung der eine Million meistbesuchten Startseiten: Auf 95,9 Prozent von ihnen wurden Verstöße gegen die WCAG 2 erkannt (WebAIM Million 2026). Im Mittel entfielen dabei 56,1 erkannte Fehler auf jede Startseite (WebAIM Million 2026). Das sind automatisiert erkennbare Befunde, also die untere Grenze; alles, was nur im Test mit Menschen auffällt, kommt hinzu. Für das Lastenheft heißt das: Eine Zeile über Barrierefreiheit reicht nicht. Es braucht die Konformitätsstufe, die Liste der zu prüfenden Seitentypen und die Frage, wer den Nachweis erbringt.

Was ein Angebot vergleichbar macht

Vergleichbarkeit entsteht nicht im Angebot, sondern in der Ausschreibung. Wenn Sie allen Anbietern dieselbe Struktur vorgeben, können Sie am Ende Zeile für Zeile nebeneinanderlegen. Das Vergaberecht bringt den Maßstab auf den Punkt: Der Zuschlag wird auf das wirtschaftlichste Angebot erteilt, und das wirtschaftlichste Angebot bestimmt sich nach dem besten Preis-Leistungs-Verhältnis (GWB). Damit dieses Verhältnis überhaupt berechenbar ist, muss die Leistungsseite ebenso klar beschrieben sein wie die Preisseite.

1. Angebotsstruktur vorgeben: Ein Preisblatt mit denselben Positionen für alle. Freie Textangebote lassen sich nicht addieren.
2. Optionen trennen: Kann-Anforderungen als eigene Positionen mit eigenem Preis, damit der Hauptpreis vergleichbar bleibt.
3. Aufwandstreiber benennen: Datenmengen, Sprachen, Kundengruppen, Marktplätze. Wer diese Zahlen nicht liefert, bekommt Schätzungen mit Aufschlag.
4. Mitwirkung festhalten: Welche Zuarbeit leisten Sie selbst, mit welchem Personaleinsatz und bis wann? Das ist ein Preisbestandteil.
5. Zuschlagskriterien vorher nennen: Die Zuschlagskriterien und deren Gewichtung müssen in der Auftragsbekanntmachung oder den Vergabeunterlagen aufgeführt werden (GWB). Diese Regel lohnt sich auch privat.
6. Rückfragen bündeln: Alle Fragen und Antworten gehen an alle Anbieter. Ein Wissensvorsprung eines Anbieters macht die Angebote unvergleichbar.

Die Gewichte sind ein Beispiel, kein Gesetz. Wichtig ist, dass Sie sie vor dem Versand festlegen und im Ausschreibungsunterlagen nennen. Wer die Gewichtung erst nach Eingang der Angebote bestimmt, wählt in Wahrheit den Anbieter und begründet ihn hinterher. Für die Umsetzung mit Shopware halten wir das Vorgehen auf der Seite zur Shopware-Agentur fest, samt der Fragen, die vor der Vergabe geklärt sein sollten.

Vom Lastenheft zum Vertrag

Ein Lastenheft entfaltet seine Wirkung erst, wenn es Vertragsbestandteil wird. Softwareprojekte mit einem definierten Ergebnis sind in aller Regel Werkverträge: Durch den Werkvertrag wird der Unternehmer zur Herstellung des versprochenen Werkes, der Besteller zur Entrichtung der vereinbarten Vergütung verpflichtet (BGB). Das versprochene Werk ist genau das, was im Lastenheft und im darauf aufbauenden Pflichtenheft steht. Fehlt dort eine Anforderung, ist sie nicht geschuldet, egal wie selbstverständlich sie im Gespräch wirkte.

• Anlagenverzeichnis: Lastenheft, Pflichtenheft und Angebot als nummerierte Anlagen mit Fassungsstand und Datum.
• Rangfolge: Was gilt, wenn Anlagen sich widersprechen? Ohne Rangfolge streiten zwei Dokumente gegeneinander.
• Änderungsverfahren: Wer beantragt eine Änderung, wer bewertet den Aufwand, wer gibt frei, in welcher Frist?
• Abnahme: Teilabnahmen je Meilenstein, Frist für die Prüfung, Umgang mit Restpunkten, Beginn der Gewährleistung.
• Mitwirkung: Welche Zuarbeit ist Voraussetzung für welchen Termin, und was passiert bei Verzug auf Auftraggeberseite?
• Betriebsübergang: Wer betreibt nach dem Livegang, mit welchen Zugängen, welchen Sicherungen und welchen Reaktionszeiten? Unsere Leistungen zu Hosting und Wartung beschreiben die übliche Aufteilung.

Ein Punkt, der oft überrascht: Der Aufwand für die Erstellung eines detaillierten Angebots ist nicht automatisch kostenlos. Das Gesetz sagt dazu nur, dass ein Kostenanschlag im Zweifel nicht zu vergüten ist (BGB). Wenn Sie von mehreren Anbietern eine tiefe Vorprüfung erwarten, etwa eine Analyse Ihrer Altdaten, ist ein bezahlter Vorprojektauftrag der ehrlichere Weg. Er kostet einen kleinen Betrag und liefert Zahlen statt Annahmen. Wie ein technisch fundierter Vorlauf aussieht, zeigt unser Bereich Programmierung und Entwicklung.

Typische Fehler beim Ausschreiben

Die meisten misslungenen Ausschreibungen scheitern nicht an fehlendem Fachwissen, sondern an sechs wiederkehrenden Mustern. Sie lassen sich alle vor dem Versand abstellen. Ein Beispiel für die Folgen ungeklärter Anforderungen liefert der Kaufabbruch: Über 50 zusammengetragene Untersuchungen hinweg liegt die mittlere Abbruchquote im Warenkorb bei 70,22 Prozent (Baymard Institute). Ein Teil davon geht auf Abläufe zurück, die im Lastenheft nicht beschrieben wurden, etwa fehlende Zahlungsarten, unklare Versandkosten oder ein Gastkauf, der niemandem aufgefallen ist.

1. Lösung statt Aufgabe: Das Dokument nennt Technik, bevor die Aufgabe steht. Die Angebote beschreiben dann dieselbe Technik zu verschiedenen Preisen, ohne dass jemand die bessere Idee vorschlagen darf.
2. Adjektive statt Messgrößen: schnell, modern, intuitiv. Jedes dieser Wörter wird im Angebot zu einem Risikoaufschlag.
3. Fehlende Abgrenzung: Ohne Kapitel zum Nichtumfang wandert alles Unklare in die Erwartung des Auftraggebers und nicht in das Angebot.
4. Schnittstellen als Fußnote: Ein Satz zur Warenwirtschaft, drei Seiten zur Startseite. Der Aufwand verteilt sich in der Regel genau umgekehrt.
5. Keine Mengen: Ohne Artikel-, Kunden- und Bestellzahlen kalkuliert jeder Anbieter eine andere Größenordnung.
6. Abnahme erst am Ende gedacht: Wenn die Prüfkriterien erst nach dem Livegang entstehen, verhandelt man sie gegen einen fertigen Stand statt gegen ein Dokument.

Gegen alle sechs Muster hilft dieselbe Übung: Geben Sie das fertige Lastenheft einer Person, die das Projekt nicht kennt, und bitten Sie sie, drei Anforderungen als Testfall aufzuschreiben. Was sie nicht in einen Testfall übersetzen kann, ist noch keine Anforderung. Wenn im Anschluss eine Migration ansteht, lohnt zusätzlich der Blick in unseren Leitfaden zur Shopware-6-Migration, weil viele Anforderungen dort bereits in prüfbarer Form vorliegen.