Lastenheft: Beispiel und Vorlage

1 Überblick

Ein Lastenheft beschreibt aus Sicht des Auftraggebers, was eine Webanwendung leisten soll und warum. Sie schreiben es selbst oder lassen sich dabei begleiten. Der Auftragnehmer antwortet darauf mit einem Angebot oder einem Pflichtenheft, in dem steht, wie er die Anforderungen umsetzt. Damit ist das Lastenheft die Grundlage für vergleichbare Angebote, für den Vertrag und am Ende für die Abnahme.

Das Beispiel weiter unten können Sie als Vorlage verwenden: Übernehmen Sie die Gliederung und ersetzen Sie die erfundenen Inhalte durch Ihre eigenen. Für eine kleine Webanwendung muss das Dokument nicht umfangreich sein. Fünf bis zehn Seiten reichen meist aus, wenn sich jede Anforderung überprüfen lässt.

Was hineingehört

• Ausgangslage: Wer Sie sind, wie die Arbeit heute abläuft und wo es hakt. Wer das Problem versteht, schlägt bessere Lösungen vor als jemand, der nur eine Funktionsliste bekommt.
• Ziele: Die wenigen Ergebnisse, die das Projekt erreichen muss, so formuliert, dass Sie später feststellen können, ob sie erreicht wurden.
• Nutzergruppen und Rollen: Wer arbeitet mit der Anwendung, wie oft, auf welchen Geräten, und was darf jede Rolle sehen und ändern?
• Funktionale Anforderungen: Was die Anwendung tut. Jede Anforderung erhält eine eigene Nummer und beschreibt genau ein Verhalten.
• Nicht-funktionale Anforderungen: Wie gut sie es tut. Ladezeit, unterstützte Browser, Barrierefreiheit, Datenschutz, Datensicherung, Serverstandort, Sprachen.
• Abgrenzung: Was ausdrücklich nicht zum Projekt gehört. Kein Abschnitt verhindert später mehr Streit als dieser.
• Abnahmekriterien: Die konkreten Prüfungen, an denen sich entscheidet, ob die Leistung erbracht ist.
• Offene Punkte: Alles, was noch nicht entschieden ist, mit der Person, die entscheidet.

So formulieren Sie eine Anforderung

Beschreiben Sie das Ergebnis und nicht die Technik. „Eine Mieterin kann einen Schaden mit Foto melden, ohne anzurufen“ ist eine Anforderung. „Die Anwendung nutzt ein bestimmtes Framework“ ist bereits eine Lösung und nimmt dem Anbieter die Möglichkeit, etwas Günstigeres oder Robusteres vorzuschlagen. Anders ist es bei echten Rahmenbedingungen, etwa einer vorhandenen Software, mit der Daten ausgetauscht werden müssen. Nennen Sie diese als Rahmenbedingung und begründen Sie sie kurz.

Geben Sie jeder Anforderung eine Priorität. Drei Stufen genügen: Muss, Soll, Kann. Liegt das Angebot über Ihrem Budget, zeigen die Prioritäten beiden Seiten, wo gekürzt werden kann, ohne den Zweck des Projekts zu gefährden.

Häufige Fehler

• Eigenschaftswörter statt Messgrößen. „Schnell“, „modern“ und „benutzerfreundlich“ lassen sich nicht prüfen. Schreiben Sie, was eine Person erledigen können muss und wie lange es dauern darf.
• Fehlende Rollen und Rechte. Wer darf Datensätze löschen, wer sieht Kosten, wer darf Daten exportieren? Solche Fragen werden teuer, wenn sie erst während der Entwicklung auftauchen.
• Keine Angaben zu vorhandenen Daten. Müssen Adressen, Objekte oder alte Vorgänge übernommen werden, nennen Sie Anzahl und Format.
• Nur der Normalfall ist beschrieben. Was geschieht, wenn eine E-Mail nicht zustellbar ist, ein Foto zu groß ist oder zwei Personen denselben Vorgang bearbeiten?
• Abnahmekriterien, die die Anforderungen nur wiederholen. Ein Kriterium nennt eine Situation, eine Handlung und das erwartete Ergebnis.
• Das Dokument gilt als endgültig. Anforderungen ändern sich, sobald eine erste Version zu sehen ist. Vereinbaren Sie vorab, wie Änderungen gemeldet, geschätzt und freigegeben werden.

So nutzen Sie das Beispiel

Übernehmen Sie den Aufbau und ersetzen Sie den Inhalt. Behalten Sie die Nummerierung bei, denn über sie können Sie sich im Angebot, in Besprechungen und im Abnahmeprotokoll eindeutig auf eine Anforderung beziehen. Werden personenbezogene Daten verarbeitet, beziehen Sie Ihre Datenschutzbeauftragte oder Ihren Datenschutzbeauftragten früh ein. Fragen zu Vertrag, Haftung und Gewährleistung klärt eine Anwältin oder ein Anwalt, nicht eine Vorlage.

2 Beispiel

3 Für wen das relevant ist

4 Fragen und Antworten

Wie lang sollte ein Lastenheft für eine kleine Webanwendung sein?

Fünf bis zehn Seiten reichen in der Regel. Entscheidend ist nicht der Umfang, sondern dass jede Anforderung eine Nummer hat, genau ein Verhalten beschreibt, eine Priorität trägt und sich bei der Abnahme prüfen lässt. Zwanzig prüfbare Anforderungen sind mehr wert als vierzig Seiten Beschreibung.

Worin unterscheiden sich Lastenheft und Pflichtenheft?

Das Lastenheft schreibt der Auftraggeber: Es sagt, was gebraucht wird und wozu. Das Pflichtenheft schreibt der Auftragnehmer: Es sagt, wie die Anforderungen umgesetzt werden. Bei kleinen Projekten ersetzt häufig ein ausführliches Angebot, das sich auf die Nummern im Lastenheft bezieht, das Pflichtenheft.

Muss ich im Lastenheft die Technik vorgeben?

Nein. Beschreiben Sie Ergebnisse und nennen Sie nur echte Rahmenbedingungen, zum Beispiel eine vorhandene Software mit Schnittstelle, einen geforderten Serverstandort oder ein System, das Ihr Team bereits betreut. Die Wahl von Framework und Architektur gehört in die Antwort des Anbieters, und Sie dürfen eine Begründung verlangen.

5 Verwandte Seiten

• Beispiel für einen Abnahmetestplan

  Ein ausgearbeiteter Plan mit Testfällen, Rollen und Abnahmekriterien zeigt, wie Sie ein Webprojekt prüfen, bevor Sie es freigeben.

• Beispiel für ein Wartungs-SLA

  So sieht eine Wartungsvereinbarung aus, in der Prioritäten, Fristen und Ausschlüsse so klar stehen, dass beide Seiten sie nachprüfen können.

• User-Story-Beispiel

  Sechs ausformulierte User Storys mit Akzeptanzkriterien zu einer Funktion: Anforderungen, die sich schätzen, umsetzen und abnehmen lassen.

• Beispiel für eine Ausschreibung zur Webentwicklung

  Eine ausgefüllte Ausschreibung, mit der Sie von mehreren Webdienstleistern Angebote erhalten, die sich Zeile für Zeile vergleichen lassen.

• Beispiel für ein Website-Briefing

  Ein kurzes, erfundenes Briefing mit Zielen, Zielgruppe, Umfang, Budgetrahmen und Zeitplan, das Sie für Ihre eigene Anfrage umschreiben können.