Wissen
Lastenheft-Vorlage mit ausgefülltem Beispiel
Neun Abschnitte, zu jedem eine Anleitung und ein ausgefülltes Beispiel. Die Anforderungen stehen als Tabelle mit ID, Priorität und Abnahmekriterium, so wie ein Anbieter sie zum Rechnen braucht. Wir bekommen solche Lastenhefte als Anbieter auf den Tisch. Die Vorlage ist so gebaut, dass wir danach ohne Rückfrage ein Angebot schreiben könnten.
Kurz gesagt
Ein Lastenheft beschreibt aus Sicht des Auftraggebers, was ein System leisten soll und warum. Eine brauchbare Vorlage hat neun Abschnitte, vom Ziel bis zur Abnahme. Fertig ist sie, wenn jede Anforderung eine ID, eine Priorität und ein prüfbares Abnahmekriterium hat und klar ist, was nicht dazugehört.
Für wen diese Seite ist: Geschäftsführer und Projektverantwortliche, die ein Software- oder Webprojekt ausschreiben und Angebote bekommen wollen, die sich vergleichen lassen.
Die Vorlage, Abschnitt für Abschnitt
Das Beispiel ist erfunden: eine Physiotherapie-Praxis mit vier Therapeuten, die Online-Terminbuchung einführt. Ersetze es durch dein Projekt. Wie ein Umsetzer auf genau dieses Lastenheft antwortet, zeigt die Pflichtenheft-Vorlage mit denselben IDs.
1. Ausgangslage und Ziel
Warum das Projekt jetzt kommt und woran du in einem Jahr Erfolg misst. Ein bis zwei Sätze und eine Messgröße.
Beispiel
Die Praxis vergibt Termine nur per Telefon. Während der Behandlung klingelt es ins Leere, und abgesagte Termine bleiben oft unbesetzt. Ziel: Patienten buchen, verschieben und sagen selbst online ab. Messgröße: Anteil der Termine, die online gebucht werden.
2. Ist-Zustand
Wie der Ablauf heute läuft, mit welchen Programmen und wo es hakt. Programme mit Namen und Version, nicht "unsere Software".
Beispiel
Termine stehen in einem Papierkalender an der Rezeption, die vormittags besetzt ist. Die Website hat keine Buchungsfunktion. Patientenakten liegen in der Praxissoftware (hier Name und Version eintragen).
3. Soll-Zustand
Wie der Ablauf nach dem Projekt aussieht, aus Sicht der Menschen, die damit arbeiten. Noch keine Funktionsliste, sondern ein Tag im neuen Ablauf.
Beispiel
Ein Patient sieht abends auf dem Handy die freien Termine, bucht in einer Minute und bekommt sofort eine Bestätigung. Am Morgen findet die Rezeption alle neuen Buchungen in einer Liste. Wer absagt, gibt den Termin selbst frei, und ein anderer Patient kann ihn buchen.
4. Funktionale Anforderungen
Was das System können muss, in der Sprache deines Ablaufs. Jede Anforderung bekommt eine ID, eine Priorität (MUSS, SOLL, KANN) und ein Abnahmekriterium. Mit der ID kann der Anbieter im Pflichtenheft Punkt für Punkt antworten.
| ID | Anforderung | Priorität | Abnahmekriterium |
|---|---|---|---|
| A-01 | Patienten sehen freie Termine je Behandlungsart und Therapeut. | MUSS | Ein Testpatient wählt Krankengymnastik und sieht nur Termine der Therapeuten, die sie anbieten. |
| A-02 | Patienten buchen mit Name, Telefonnummer und E-Mail, ohne Konto. | MUSS | Die Buchung steht danach in der Übersicht der Rezeption, und der Termin ist für andere belegt. |
| A-03 | Nach der Buchung kommt eine Bestätigung per E-Mail. | MUSS | Die Mail ist innerhalb von fünf Minuten im Testpostfach, mit Datum, Uhrzeit, Therapeut und Absage-Link. |
| A-04 | 24 Stunden vor dem Termin kommt eine Erinnerung per E-Mail. | SOLL | Für einen Testtermin morgen um 10 Uhr kommt die Erinnerung heute bis 10 Uhr. |
| A-05 | Patienten sagen bis 24 Stunden vorher selbst ab, der Termin wird wieder frei. | MUSS | Eine Absage 25 Stunden vorher klappt. Bei 23 Stunden erscheint der Hinweis, telefonisch abzusagen. |
| A-06 | Warteliste für ausgebuchte Tage. | KANN | Wird ein Termin frei, bekommt der Erste auf der Liste eine Mail. |
5. Qualitätsanforderungen
Wie gut, wie schnell, wie sicher: Bedienung auf dem Handy, Datenschutz, Barrierefreiheit, Verfügbarkeit, Rechte und Rollen. Auch hier mit ID und Prüfweg. Diese Punkte vergisst man leicht, weil man sie im Alltag nicht sieht.
| ID | Anforderung | Priorität | Abnahmekriterium |
|---|---|---|---|
| Q-01 | Auf dem Handy bedienbar, eine Buchung dauert unter einer Minute. | MUSS | Drei Testpersonen buchen auf ihrem eigenen Handy, die Zeit wird gestoppt. |
| Q-02 | Daten werden in der EU gespeichert, ein Auftragsverarbeitungsvertrag liegt vor. | MUSS | Serverstandort und Vertrag sind schriftlich belegt. |
| Q-03 | Die Buchung ist mit Tastatur und Screenreader bedienbar. | SOLL | Eine Buchung gelingt komplett ohne Maus und mit eingeschaltetem Screenreader. |
6. Schnittstellen
Welche bestehenden Systeme mitspielen müssen, in welche Richtung die Daten fließen und was der Plan B ist. Hier entscheidet sich oft der Aufwand.
Beispiel
Gebuchte Termine sollen in die Praxissoftware. Bietet der Hersteller keine Schnittstelle an, reicht zunächst ein täglicher Export als Datei, den die Rezeption einliest.
7. Abgrenzung
Was ausdrücklich nicht zum Projekt gehört. Der kürzeste Abschnitt, aber er beendet Diskussionen, bevor sie anfangen.
Beispiel
Nicht enthalten: Online-Zahlung, Videosprechstunde, Patientenakte im Web und eine eigene App für iOS oder Android. Die Buchung läuft im Browser.
8. Rahmen
Budgetkorridor, Termin mit Begründung, rechtliche Vorgaben und eine Person, die entscheiden darf. Ohne Budgetkorridor rechnet jeder Anbieter ein anderes Projekt.
Beispiel
Live bis Ende September, vor der Grippesaison. Budget im mittleren vierstelligen bis unteren fünfstelligen Bereich. Alle Daten bleiben in der EU. Ansprechpartnerin ist die Praxisinhaberin, sie entscheidet innerhalb von drei Werktagen.
9. Lieferumfang und Abnahme
Was am Ende übergeben wird und wie abgenommen wird: wer testet, mit welchen Daten, und ab wann etwas als fertig gilt.
Beispiel
Geliefert werden die Buchungsstrecke in der bestehenden Website, eine Übersicht für die Rezeption, eine Einweisung für zwei Personen und eine kurze Anleitung. Zur Abnahme spielt die Rezeption alle MUSS-Anforderungen mit drei Testpatienten durch. Erst wenn jede MUSS-Anforderung besteht, ist das Projekt abgenommen.
Anforderungen prüfbar formulieren
Eine Anforderung ist erst dann gut, wenn jemand anderes sie testen kann, ohne dich zu fragen. Die Formel dafür: Wer will was, unter welcher Bedingung, und woran sieht man, dass es klappt?
Nicht prüfbar
"Die Buchung soll benutzerfreundlich und schnell sein."
Prüfbar
"Patienten buchen auf dem Handy in unter einer Minute. Abnahme: drei Testpersonen buchen auf ihrem eigenen Handy, die Zeit wird gestoppt."
Schreib den Ablauf auf, nicht die Technik. "MySQL-Datenbank" ist eine Antwort, die der Anbieter geben soll. Deine Aufgabe ist, was der Ablauf am Ende leisten muss.
Prüfliste: bevor du das Lastenheft verschickst
Jeder Punkt, der hier fehlt, kommt als Rückfrage vom Anbieter zurück. Diese Fragen stellen wir selbst, wenn ein Lastenheft bei uns ankommt. Was niemand fragt, rechnet der Anbieter mit einer eigenen Annahme ein, und die kennst du erst, wenn das Angebot da ist.
- Jede Anforderung hat eine ID und eine Priorität.
- Jede MUSS-Anforderung hat ein Abnahmekriterium, das jemand ohne dich prüfen kann.
- Die Abgrenzung nennt konkret, was nicht dazugehört.
- Alle Systeme, die mitspielen, stehen mit Namen und Version drin.
- Es gibt einen Budgetkorridor.
- Der Termin hat einen Grund, nicht nur ein Datum.
- Eine Person darf entscheiden, und es steht drin, wie schnell.
- Offene Fragen stehen als offen drin, statt zu fehlen.
Ob ein klassisches Lastenheft für dein Projekt überhaupt das richtige Werkzeug ist, und was im Streitfall rechtlich zählt, steht im Ratgeber zum Unterschied zwischen Lastenheft und Pflichtenheft.
Lieber gemeinsam statt allein?
Wenn sich die Anforderungen beim Schreiben ständig ändern, ist das normal. In einem Discovery Workshop füllen wir die Abschnitte gemeinsam, schauen uns deinen echten Ablauf an und machen aus der Vorlage einen Plan mit Prototyp und Festpreis.
FAQ
Häufig gestellte Fragen
Wie muss ein Lastenheft aufgebaut sein?
Bewährt sind neun Abschnitte: Ausgangslage und Ziel, Ist-Zustand, Soll-Zustand, funktionale Anforderungen, Qualitätsanforderungen, Schnittstellen, Abgrenzung, Rahmen sowie Lieferumfang und Abnahme. Genau diese Struktur hat die Vorlage auf dieser Seite.
Wie formuliert man eine Anforderung im Lastenheft?
Wer will was unter welcher Bedingung, und woran sieht man, dass es klappt. Jede Anforderung bekommt eine ID, eine Priorität und ein Abnahmekriterium, das jemand ohne dich prüfen kann. Beschreibe den Ablauf, nicht die Technik.
Was bedeuten MUSS, SOLL und KANN?
MUSS heißt: ohne diese Anforderung wird nicht abgenommen. SOLL ist wichtig, darf aber notfalls in eine spätere Stufe rutschen. KANN ist ein Wunsch, der nur umgesetzt wird, wenn Budget und Zeit reichen. Die Priorität hilft dem Anbieter, ein Angebot in Stufen zu rechnen.
Wie lang muss ein Lastenheft sein?
So lang, dass ein Anbieter ohne Rückfrage rechnen kann, und nicht länger. Bei einem kleinen, klaren Vorhaben reichen oft zwei bis vier Seiten. Wichtiger als die Länge sind prüfbare Anforderungen und eine klare Abgrenzung.
Gibt es die Vorlage als Word oder PDF?
Ja, beides, kostenlos und ohne Anmeldung. Die Word-Datei kannst du direkt ausfüllen, die PDF eignet sich zum Ausdrucken oder als Muster. Beide enthalten Anleitung und das ausgefüllte Beispiel.
Wer schreibt das Lastenheft?
Der Auftraggeber, also du. Der Anbieter antwortet darauf mit dem Pflichtenheft und beschreibt, wie er jede Anforderung umsetzt. Wie das aussieht, zeigt die Pflichtenheft-Vorlage mit demselben Beispiel.