Lastenheft für Shopify-Apps: Anforderungen vergleichbar machen
Kurzantwort: Ein Lastenheft beschreibt, was die App leisten soll – aus Sicht des Händlers. Es enthält Ziel, Nutzer, heutigen Prozess, Muss- und Kann-Anforderungen, Daten, Integrationen, Mengen, Sicherheitsanforderungen, Abnahmekriterien und ausdrücklich den Nicht-Umfang. Ein Pflichtenheft beschreibt dagegen, wie der Entwickler die Anforderungen umsetzen will. Ohne Lastenheft vergleichen Sie Angebote, die unterschiedliche Dinge meinen.
Für eine App im fünfstelligen Bereich ist das Lastenheft keine Bürokratie, sondern die günstigste Möglichkeit, teure Missverständnisse zu vermeiden. Es zwingt beide Seiten, dieselben Begriffe zu benutzen: Was ist eine „Bestellung“, was ein „Status“, wann gilt ein Fall als „erledigt“?
Lastenheft und Pflichtenheft unterscheiden
| Dokument | Perspektive | Inhalt |
|---|---|---|
| Lastenheft | Händler/Auftraggeber | Was wird gebraucht und warum? |
| Pflichtenheft | Entwickler/Auftragnehmer | Wie wird es technisch umgesetzt? |
In kleinen Projekten können beide Dokumente zusammenfallen. Für eine individuelle App mit mehreren Systemen ist die Trennung hilfreich: Der Händler beschreibt das Problem, der Entwickler die Lösung. So bleibt sichtbar, ob eine Anforderung wirklich erfüllt ist oder nur technisch erklärt wurde.
Die Struktur eines brauchbaren Lastenhefts
1. Ziel und Erfolgskriterium
Beschreiben Sie in drei bis fünf Sätzen:
- Welches Problem wird gelöst?
- Wer profitiert?
- Woran wird der Erfolg gemessen?
Beispiel: „Die manuelle Übertragung von Bestellungen ins ERP entfällt. Erfolg bedeutet: Jede bezahlte Bestellung wird innerhalb von fünf Minuten mit den richtigen Daten übertragen, und Fehler werden sichtbar gemeldet.“
2. Nutzer und Rollen
Wer arbeitet mit der App?
- Lager,
- Kundenservice,
- Buchhaltung,
- Geschäftsführung,
- externe Dienstleister.
Für jede Rolle: Welche Aufgaben, welche Daten, welche Berechtigungen? Eine App, die alle alles sehen lässt, ist selten sinnvoll.
3. Heutiger Prozess
Beschreiben Sie den Ablauf von Anfang bis Ende – auch die unangenehmen Teile:
- Wo werden Daten heute eingegeben?
- Welche Dateien oder Systeme sind beteiligt?
- Wo entstehen Fehler?
- Was passiert bei Sonderfällen?
- Wie oft kommt der Prozess vor?
Ein Flussdiagramm oder eine nummerierte Liste reicht. Wichtig ist die Realität, nicht der Wunschzustand.
4. Umfang: Muss, Soll, Kann
Priorisieren Sie:
- Muss: Ohne diese Funktion ist die App nutzlos.
- Soll: Wichtig, aber nicht launchkritisch.
- Kann: Nice-to-have, später.
Diese Priorisierung ermöglicht einen schmalen ersten Launch. Ein großer Muss-Umfang ist ein Warnsignal für Budget und Zeitplan.
5. Daten und Datenmodell
Beschreiben Sie die zentralen Objekte:
| Objekt | Beispiele für Felder |
|---|---|
| Produkt | SKU, Variante, Preis, Steuer, Lager |
| Bestellung | Nummer, Status, Positionen, Lieferung |
| Kunde | Kundennummer, Land, Preisgruppe |
| Verpackung | Material, Gewicht, Zuordnung |
| Ereignis | Zeitstempel, Quelle, Status |
Klären Sie auch:
- Woher kommen die Daten?
- Welche Daten fehlen heute?
- Wie werden sie bereinigt?
- Was passiert bei Änderungen?
- Wie lange werden sie gespeichert?
6. Integrationen
Für jede Schnittstelle:
- System und Version,
- Richtung (lesen, schreiben, beides),
- Datenformat,
- Häufigkeit,
- Fehlerverhalten,
- Verantwortliche,
- Testmöglichkeiten,
- Kosten und Limits beim Drittsystem.
Eine Integration ist selten „nur eine API“. Sie braucht Mapping, Fehlerbehandlung, Wiederholungen und Monitoring.
7. Mengen und Performance
Nennen Sie realistische Zahlen:
- Bestellungen pro Tag/Monat,
- Produkte und Varianten,
- gleichzeitige Nutzer,
- Datenwachstum,
- Spitzenlast (Sale, Black Friday),
- akzeptable Antwortzeit.
Ohne Mengen lässt sich die Architektur nicht angemessen dimensionieren.
8. Sicherheit, Datenschutz und Compliance
Klären Sie:
- Welche personenbezogenen Daten werden verarbeitet?
- Welche Shopify-Berechtigungen sind nötig?
- Wer darf Daten sehen?
- Wie lange werden Daten aufbewahrt?
- Gibt es Auftragsverarbeitung?
- Welche rechtlichen Anforderungen gelten?
Mehr dazu: Sicherheit und Datenschutz bei eigenen Shopify-Apps.
9. Oberfläche und Bedienung
Beschreiben Sie die wichtigsten Ansichten und Aufgaben:
- Wo startet die App?
- Welche Informationen braucht der Nutzer zuerst?
- Welche Aktionen sind häufig?
- Welche Fehlermeldungen sind nötig?
- Muss sie mobil funktionieren?
Ein Klickprototyp ist oft hilfreicher als eine lange Textbeschreibung.
10. Abnahmekriterien
Definieren Sie, wann die App als abgenommen gilt:
- Welche Testfälle müssen bestehen?
- Welche Fehlerfälle werden geprüft?
- Welche Datenmengen werden getestet?
- Wer nimmt ab?
- Wie lange dauert die Testphase?
Ohne Abnahmekriterien wird „fertig“ zur Verhandlungssache.
11. Nicht-Umfang
Schreiben Sie ausdrücklich, was nicht enthalten ist:
- keine neue Warenwirtschaft,
- keine Migration historischer Daten,
- kein Design-Relaunch,
- keine Support-Hotline,
- keine öffentliche App-Store-Veröffentlichung.
Der Nicht-Umfang schützt beide Seiten vor stillen Erwartungen.
12. Rahmenbedingungen
- Budgetrahmen,
- gewünschter Start,
- Meilensteine,
- Ansprechpartner,
- Entscheidungswege,
- Sprache und Dokumentation,
- Betriebsmodell.
Ein kurzes Beispiel
Ziel: Bestellungen aus Shopify automatisch ins ERP übertragen und Fehler sichtbar machen.
Muss:
- Jede bezahlte Bestellung wird übertragen.
- Fehlgeschlagene Übertragungen erscheinen in einer Liste.
- Eine erneute Übertragung ist möglich.
- Bestellstatus und Fehlermeldung werden protokolliert.
Soll:
- Storno und Retoure werden berücksichtigt.
- Eine tägliche Zusammenfassung wird per E-Mail versendet.
Nicht-Umfang:
- Keine Änderung am ERP,
- keine Migration alter Bestellungen,
- keine Kundenoberfläche.
Abnahme:
- 50 Testbestellungen mit Normalfall, Storno, Retoure und Fehlerfall,
- keine doppelten Übertragungen,
- nachvollziehbares Log.
Häufige Fehler
- Lösung statt Problem: „Wir brauchen eine React-App“ beschreibt keine Anforderung.
- Fehlende Mengen: Architektur ohne Volumen ist Raterei.
- Kein Nicht-Umfang: Alles ist irgendwie enthalten – und am Ende nichts.
- Keine Abnahme: „Passt schon“ ist kein Kriterium.
- Sonderfälle vergessen: Genau sie kosten später Zeit.
- Datenschutz am Ende: Sicherheit lässt sich nicht ans Projektende anhängen.
- Ein Anbieter, ein Angebot: Vergleichen Sie mindestens zwei Ansätze.
Häufige Fragen
Wie lang sollte ein Lastenheft sein?
So lang wie nötig, so kurz wie möglich. Für eine fokussierte App reichen oft fünf bis zehn Seiten. Wichtiger als Länge sind Klarheit, Mengen und Abnahmekriterien.
Wer schreibt das Lastenheft?
Der Händler mit Unterstützung des Entwicklers. Der Händler kennt den Prozess, der Entwickler die technischen Grenzen. Ein gemeinsamer Discovery-Workshop ist oft der beste Start.
Kann der Entwickler das Lastenheft schreiben?
Ja, aber dann ist es eher ein Pflichtenheft. Lassen Sie die Anforderungen trotzdem vom Händler freigeben. Sonst prüft der Entwickler seine eigene Interpretation.
Was gehört nicht hinein?
Technische Detailentscheidungen, die der Entwickler treffen sollte, und unrealistische Pauschalziele wie „alles automatisch“. Beschreiben Sie das gewünschte Ergebnis, nicht jede Codezeile.
Nächster Schritt
Wenn Sie Ihre App-Idee in ein belastbares Lastenheft überführen möchten, beginnen Sie mit Prozess, Daten, Mengen und Abnahmekriterien. Daraus lässt sich ein realistischer Projektzuschnitt ableiten. Projekt besprechen oder SaaS-Lösungen ansehen.