Softwareprojekte scheitern selten am Programmieren, sondern meist an einer unklaren Vereinbarung darüber, was gebaut wird. Ein Lastenheft beschreibt, was die App leisten soll, für wen und woran Sie erkennen, dass sie fertig ist. Technisches Wissen brauchen Sie nicht — nur Klarheit. Unten finden Sie eine Vorlage zum Kopieren.
Kurz gesagt
Beschreiben Sie Problem und Ziel, Nutzer und Rollen, die wichtigsten Abläufe, eine Funktionsliste mit Prioritäten (Muss / Soll / Später), Daten und Schnittstellen, Anforderungen an Geschwindigkeit, Sicherheit und Sprachen, Budget und Termin, was nicht zum Projekt gehört, und wie Sie die Abnahme prüfen.
Lastenheft-Vorlage in 10 Punkten
- Problem und Ziel — was heute nicht funktioniert oder zu viel Zeit kostet und was Sie erreichen wollen. Z. B. „30 % der Termine werden vergessen“ → „Ausfälle durch automatische Erinnerungen senken“.
- Nutzer und Rollen — wer die App nutzt: Kunde, Mitarbeiter, Administrator. Was jede Rolle sehen und tun darf.
- Wichtigste Abläufe — 3–7 Schritte für die zentralen Aktionen. Z. B. „Kunde wählt Leistung → Mitarbeiter → Termin → bestätigt → erhält SMS“.
- Funktionsliste mit Prioritäten — jede Funktion als Muss, Soll oder Später markieren. Das bestimmt den Preis der ersten Version am stärksten.
- Daten — was gespeichert wird (Kunden, Bestellungen, Dokumente), woher bestehende Daten kommen und ob sie aus Excel oder einem Altsystem übernommen werden.
- Schnittstellen — Kartenzahlung, Rechnungs- oder Kassensystem, Buchhaltung, E-Mail/SMS, bestehende Systeme.
- Plattformen und Sprachen — Web, iPhone, Android; welche Sprachen; ob die App offline funktionieren muss.
- Nichtfunktionale Anforderungen — Geschwindigkeit, Nutzerzahl, Sicherheit und Datenschutz (DSGVO), Barrierefreiheit, Backups.
- Budget, Termin und Abgrenzung — Budgetrahmen, Wunschtermin und was ausdrücklich nicht zu dieser Phase gehört.
- Abnahmekriterien — woran Sie erkennen, dass eine Funktion fertig ist. Z. B. „Stornierung bis 12 Std. vorher möglich; danach ist der Button deaktiviert.“
Beispiel einer gut beschriebenen Funktion
| Unklar | Klar |
|---|---|
| „Die App soll Erinnerungen haben.“ | „Kunden erhalten 24 Std. und 2 Std. vor dem Termin eine Push-Mitteilung. Sind Mitteilungen deaktiviert, wird eine SMS gesendet. Der Admin kann den Text ändern.“ |
| „Berichte für die Geschäftsführung.“ | „Jeden Montag um 8 Uhr erhält die Geschäftsführung eine E-Mail mit Buchungen, Stornierungen und Umsatz pro Mitarbeiter der Vorwoche.“ |
Typische Fehler, die den Preis erhöhen
- „Wie App X, nur für uns“ — ohne Funktionsliste muss der Anbieter raten, Angebote sind nicht vergleichbar.
- Alles ist Muss — die erste Version wird groß, teuer und spät. Trennen Sie, was unverzichtbar ist.
- Admin-Bereich vergessen — wer pflegt Preise, Termine und Nutzer? Das ist oft die Hälfte der Arbeit.
- Keine Abnahmekriterien — am Ende wird darüber gestritten, was „fertig“ heißt.
- Unklare Rechte — halten Sie fest, dass Quellcode, Daten und Zugänge Ihnen gehören.
Für öffentliche Ausschreibungen lesen Sie auch technische Spezifikation für eine Website-Ausschreibung. Richtpreise finden Sie unter Was kostet eine App? und Individualsoftware oder Standardsoftware.
Eine Idee, aber noch kein Lastenheft?
Schicken Sie ein paar Sätze dazu, was Sie vorhaben. Ich helfe, daraus ein klares Lastenheft mit Prioritäten zu machen — und Sie erhalten einen Richtpreis für die erste Version.
Engimotive · Veröffentlicht 5. November 2026