Lastenheft: Vorlage, Beispiel & Anleitung

1. Was ist ein Lastenheft?

Das Lastenheft (Leistungsverzeichnis, Statement of Work, Anforderungen) ist ein wichtiges Element in der klassischen Projektdokumentation. Es beschreibt die Anforderungen des Auftraggebers an die im Rahmen eines Projekts zu erbringenden Leistungen und legt damit den Eckpunkt “Scope” im Magischen Dreieck fest. Das Lastenheft erstellen ist üblicherweise Aufgabe des Auftraggebers. Es dient als Spezifikation und Grundlage für Angebotsanfragen und Ausschreibungen. Lastenhefte werden meistens in der Projektmanagement-Phase “Initialisierung” erstellt. Sie sind eine Voraussetzung dafür, einen Projektplan erstellen zu können und definieren einen großen Teil des Projekt-Scope.

Nach Erhalt des Lastenhefts setzt ein potentieller Auftragnehmer die zu erbringenden Ergebnisse (Lasten) in erforderliche Tätigkeiten (Pflichten) um und erstellt das sogenannte Pflichtenheft. Dieses ist Teil des Angebots an den Auftraggeber. Im einfachsten Fall besteht das Pflichtenheft aus einem Verweis auf das Lastenheft sowie einem Termin und einem Preis.

Lasten- und Pflichtenheft sollten Bestandteil des Vertrags zwischen Auftraggeber und Auftragnehmer sein. Sie sollten vor Projektbeginn erstellt werden, wozu bei größeren Vorhaben ein eigenes Projekt erforderlich sein kann.

2. Wie ist ein Lastenheft aufgebaut?

In Anlehnung an das V-Modell XT sollte ein Lastenheft wie folgt strukturiert sein:

• Einleitung
• Beschreibung der Ausgangssituation und der Zielsetzung
• Funktionale Anforderungen
• Nicht–funktionale Anforderungen
• Gesamtsystem-Architektur
• Anforderungen an die Funktionssicherheit
• Lieferumfang
• Abnahmekriterien und Vorgehen zur Abnahmeprüfung
• Glossar

Im folgenden gehen wir der Reihenfolge nach die einzelnen Abschnitte durch. Für den schnellen Start haben wir eine Lastenheft-Vorlage erstellt.

Einleitung

In der Einleitung beschreiben wir übersichtsmäßig die Motivation für das Projekt und geben eine knappe Übersicht über den erwarteten Nutzen.

Ausgangssituation und Zielsetzung

Im zweiten Abschnitt werden beim Lastenheft erstellen die Ausgangssituation und der Anlass zur Durchführung des Projektes anschaulich dargestellt. Der Nutzen bzw. Mehrwert gegenüber existierenden Lösungen und damit die Motivation für die Durchführung des Projekts wird hier allgemein verständlich beschrieben.

Es werden zusätzlich alle relevanten Stakeholder des Projektes benannt und die technische und fachliche Einbettung des zu entwickelnden Systems in seine Umgebung skizziert. Damit wird auch die Systemgrenze definiert und die Schnittstellen zu anderen Systemen werden aufgezeigt. Für die Entwicklung werden erste Rahmenbedingungen identifiziert und beschrieben wie z. B. der im Projekthandbuch festgelegte konkrete Entwicklungsprozess, technische Vorgaben oder Vorgaben zur Sicherheit.

Funktionale Anforderungen

Die funktionalen Anforderungen beschreiben die Fähigkeiten des Systems, mit deren Hilfe ein Anwender ein fachliches Problem lösen kann. Die Anforderungen werden beim Lastenheft erstellen aus den zu unterstützenden Geschäftsprozessen und den Ablaufbeschreibungen zur Nutzung des Systems abgeleitet.

Es gibt viele Methoden zur Darstellung funktionaler Anforderungen. Beispiele sind

• Anwendungsfälle (Use Cases). Diese sind für sich alleine oft zu grob, um daraus konkretes Verhalten ableiten zu können und werden deshalb gerne mit anderen Modellierungsformen kombiniert.
• Goal-Scenario mit Betonung auf Scenario. Das gewünschte Verhalten wird in Szenarien beschrieben. Diese Methode eignet sich besonders für Systeme, die einen großen Teil ihrer Funktionalität an der Bedienschnittstelle exponieren.
• Blockschaltbilder eignen sich gut für technische Systeme und Steuerungen.
• Datenmodelle sind hilfreich bei datenzentrierten Systemen. Ein Datenmodell dient als Grundlage für den späteren Datenbankentwurf.

Die funktionalen Anforderungen sind die zentralen Vorgaben für die Systementwicklung. Sie werden in das Pflichtenheft übernommen und bei Bedarf konkretisiert.

So sieht eine einzelne funktionale Anforderung im Lastenheft aus — formuliert nach dem Satzbaumuster und mit eigener Kennung und Abnahmekriterium:

Feld	Inhalt
ID	FA-014
Priorität	MUSS
Anforderung	Wenn ein Instandhaltungsauftrag den Status „abgeschlossen” erhält, muss das System den zuständigen Anlagenverantwortlichen per E-Mail benachrichtigen.
Quelle	Workshop Instandhaltung vom 12.03., Herr Berger
Abnahmekriterium	Ein Auftrag wird abgeschlossen; die Benachrichtigung ist innerhalb von 60 Sekunden im Postfach des hinterlegten Verantwortlichen nachweisbar.

Drei Dinge machen diese Anforderung prüfbar: Sie beschreibt genau eine Fähigkeit, sie nennt eine messbare Bedingung (60 Sekunden statt „zeitnah”), und sie trägt eine eindeutige ID, auf die sich Angebot, Pflichtenheft und Abnahmeprotokoll später beziehen können.

Nicht-funktionale Anforderungen

Nicht-funktionale Anforderungen sind Anforderungen an das System, die zwar zur Anwendbarkeit des Systems beitragen, aber nicht-fachlicher Natur sind. Dazu gehören z.B. Anforderungen an die Benutzbarkeit, die Performance oder die Skalierbarkeit des Systems.

Die durch nicht-funktionale Anforderungen definierten Eigenschaften eines Systems müssen schon in der Entwurfsphase berücksichtigt werden und tragen häufig zu den Entwicklungskosten bei. Anforderungen, die nicht eindeutig zu den funktionalen Anforderungen gehören, werden den nicht-funktionalen Anforderungen zugeordnet.

Gesamtsystem-Architektur

Es ist praktisch unmöglich, Anwenderanforderungen allein im . Problemraum ohne Betrachtung des Lösungsraums zu definieren. Es ist deshalb sinnvoll, schon mit der Erstellung des Lastenhefts eine Gesamt­system­archi­tektur aus Anwendersicht zu skizzieren. Diese funktionale Systemarchitektur legt auch die Schnittstellen zu eventuellen benachbarten Systemen fest.

Ist der Einsatz von Fertigprodukten geplant, sollten diese in der in der Gesamtsystemarchitektur identifiziert und festgeschrieben werden. Zur Systemarchitektur gehört im weiteren eine Beschreibung der Einsatzumgebung und ggfs. die Festlegung von Sicherheitsanforderungen.

Anforderungen an die Funktionssicherheit

Geht es im Lastenheft um sicherheitskritische Systeme, werden in diesem Abschnitt Vorgaben für die Behandlung der Funktionssicherheit definiert. Die im Rahmen des Systembetriebs bestehenden Risiken werden aufgezeigt, nach Schadenshöhe klassifiziert sowie mit einer geschätzten Eintritts­wahrschein­lichkeit versehen. Für jeden identifizierten Schadensfall ist z.B. in einer Form einer Risiko-Akzeptanzmatrix anzugeben, für welche Schadensklasse und welche Eintrittswahrscheinlichkeit welche Risikoklasse toleriert wird.

Lieferumfang

In diesem Abschnitt sind beim Lastenheft erstellen alle Gegenstände und Dienstleistungen aufzulisten, die im Projektverlauf oder zum Abschluss durch den Auftragnehmer zu liefern sind. Der Lieferumfang kann ein ganzes System, Teile davon, Dokumente und Dienstleistungen enthalten.

Ein Lieferumfang für ein Softwareprojekt umfasst typischerweise mehr als die Software selbst:

• Software: einsatzfähige Installation in Test- und Produktivumgebung, einschließlich aller im Lastenheft geforderten Funktionen
• Datenmigration: Übernahme der Altdaten aus dem Vorsystem, mit dokumentiertem Abgleichprotokoll
• Schnittstellen: dokumentierte und getestete Anbindung an die benannten Nachbarsysteme
• Dokumentation: Administrations- und Benutzerhandbuch in deutscher Sprache
• Dienstleistungen: Schulung der Administratoren und Key User, Unterstützung während der ersten zwei Wochen des Produktivbetriebs
• Nachweise: Testprotokolle zu den vereinbarten Abnahmekriterien

Was hier nicht steht, muss später nachverhandelt werden. Gerade Datenmigration, Schulung und Dokumentation werden häufig vergessen und sind dann die teuersten Nachforderungen im Projekt.

Abnahmekriterien und Vorgehen zur Abnahmeprüfung

Durch Abnahmekriterien wird festgelegt, welche Eigenschaften und welches Verhalten eine Lieferung erfüllen muss, damit sie den Anforderungen genügt. Die Kriterien sollten messbar dargestellt werden und können nach Ausgangssituation, Aktion(en) und erwartetem Ergebnis strukturiert werden. Abnahmekriterien können sich sowohl auf einzelne Anforderungen (“Unter welchen Bedingungen gilt die Anforderung als erfüllt?”) als auch auf den Lieferumfang (“Welche Bedingungen müssen erfüllt sein, damit eine konkrete Lieferung abgenommen wird?”) beziehen. Die Abnahmekriterien sind Basis der Abnahmeprüfung.

Es bietet sich an, Abnahmekriterien in Form von konkreten Abnahmeszenarien zu beschreiben, die das System bei der Lieferung durchlaufen muss. Ein solches Szenario nach dem Schema Ausgangssituation – Aktion – erwartetes Ergebnis:

AK-007 (zu FA-014) Ausgangssituation: Ein Instandhaltungsauftrag ist angelegt, ein Anlagenverantwortlicher mit gültiger E-Mail-Adresse ist zugeordnet. Aktion: Ein Techniker setzt den Auftrag auf den Status „abgeschlossen”. Erwartetes Ergebnis: Der Anlagenverantwortliche erhält innerhalb von 60 Sekunden eine E-Mail, die Auftragsnummer, Anlage und Abschlusszeitpunkt enthält.

Der Unterschied zu einem unbrauchbaren Kriterium liegt in der Messbarkeit: „Das System benachrichtigt den Verantwortlichen zuverlässig” lässt sich nicht abnehmen, das Szenario oben schon.

Die Abnahmekriterien können nach der Auftragsvergabe weiter detailliert werden; dadurch können auch die Anforderungen präzisiert werden. Die erwarteten Ergebnisse der Abnahme und das Vorgehen bei der Abnahmeprüfung für jede Lieferung sollte auf jeden Fall schon vor der Abnahme detailliert festgelegt und zwischen Auftraggeber und Auftragnehmer abgestimmt werden.

3. Lastenheft-Beispiel: ein Softwareprojekt

Die Abschnittsbeschreibungen oben sagen, was hineingehört. Dieses Beispiel zeigt, wie es dann aussieht. Es ist bewusst klein gehalten und frei erfunden — die Struktur ist aber genau die aus Abschnitt 2.

Ausgangssituation. Ein Maschinenbauunternehmen mit 350 Mitarbeitern erfasst Instandhaltungsaufträge auf Papier und überträgt sie abends in eine Excel-Tabelle. Rückfragen zum Status laufen über das Telefon, Auswertungen zur Ausfallhäufigkeit einzelner Anlagen sind nicht möglich. Das Unternehmen will die Aufträge digital erfassen und auswerten und schreibt dafür ein Lastenheft.

Zielsetzung im Lastenheft. „Instandhaltungsaufträge werden künftig direkt an der Anlage digital erfasst. Der Status eines Auftrags ist für Produktionsleitung und Anlagenverantwortliche ohne Rückfrage einsehbar. Die Ausfallhäufigkeit je Anlage ist über einen Zeitraum von mindestens 24 Monaten auswertbar.” — Beachte, dass hier kein Produkt und keine Technologie genannt wird: Das Lastenheft beschreibt das Problem, nicht die Lösung.

Anforderungen. Jede Zeile trägt eine Kennung, eine Priorität und ein prüfbares Abnahmekriterium:

ID	Prio	Anforderung	Abnahmekriterium
FA-011	MUSS	Ein Techniker muss einen Instandhaltungsauftrag mit Anlage, Fehlerbild und Datum auf einem mobilen Endgerät anlegen können.	Auftrag wird auf einem Tablet angelegt und ist danach am Arbeitsplatzrechner vollständig sichtbar.
FA-014	MUSS	Wenn ein Auftrag den Status „abgeschlossen” erhält, muss das System den zuständigen Anlagenverantwortlichen per E-Mail benachrichtigen.	Siehe AK-007.
FA-021	MUSS	Die Produktionsleitung muss die Anzahl der Aufträge je Anlage für einen frei wählbaren Zeitraum auswerten können.	Auswertung für ein Quartal wird erzeugt und stimmt mit der Summe der Einzelaufträge überein.
FA-032	SOLL	Ein Techniker soll einem Auftrag Fotos hinzufügen können.	Zwei Fotos werden angehängt und sind nach dem Speichern in der Auftragsansicht abrufbar.
NF-004	MUSS	Das System muss bei 40 gleichzeitig angemeldeten Benutzern eine Antwortzeit von unter 2 Sekunden je Seitenaufruf einhalten.	Lasttest mit 40 parallelen Sitzungen; 95 % der Aufrufe unter 2 Sekunden.
NF-009	MUSS	Personenbezogene Daten müssen ausschließlich auf Servern innerhalb der EU verarbeitet werden.	Schriftlicher Nachweis der Standorte aller verarbeitenden Systeme.
SS-002	KANN	Das System kann Anlagenstammdaten aus dem ERP-System übernehmen.	Import einer Beispieldatei mit 50 Anlagen ohne manuelle Nacharbeit.

Lieferumfang und Abnahme stehen in eigenen Abschnitten — die Listen dazu findest Du oben unter Lieferumfang und Abnahmekriterien.

Was im Softwareprojekt anders ist

Bei einem Lastenheft für ein Softwareprojekt verschiebt sich das Gewicht gegenüber einem klassischen Anlagen- oder Bauprojekt an vier Stellen:

• Schnittstellen und Datenmigration werden zum Hauptrisiko. Sie gehören ins Lastenheft, auch wenn die Details noch offen sind — mindestens mit der Liste der Nachbarsysteme und der Aussage, wer die Altdaten aufbereitet.
• Nicht-funktionale Anforderungen entscheiden über die Kosten. Antwortzeiten, Verfügbarkeit, Mandantentrennung und Datenschutz lassen sich nachträglich kaum noch einbauen. Formuliere sie messbar, wie NF-004 oben.
• Rollen und Berechtigungen sind fachliche Anforderungen, keine technische Feinplanung. Wer darf welche Aufträge sehen, ändern, abschließen? Diese Frage im Lastenheft offen zu lassen, verursacht später den größten Änderungsaufwand.
• Der Betrieb gehört dazu. Cloud oder eigenes Rechenzentrum, Wartungsfenster, Reaktionszeiten im Störungsfall — das sind Anforderungen des Auftraggebers und keine Sache des Angebots.

Auf dieser Grundlage erstellt der Auftragnehmer anschließend das Pflichtenheft und beschreibt darin, wie er die Anforderungen umsetzen will.

4. Worauf ist beim Erstellen eines Lastenhefts zu achten?

Detaillierungsgrad

Den “richtigen” Detaillierungsgrad gibt es leider nicht. Ist das Dokument oberflächlich und vage, ist die Gefahr groß, dass das gelieferte Produkt nicht den Vorstellungen des Auftraggebers entspricht und es kommt nicht selten zu Nachforderungen oder Rechtsstreitigkeiten. Eine sehr detaillierte Spezifikation auf der anderen Seite kann den Lösungsraum unnötig einschränken und damit innovationshemmend sein. Es kostet u.U auch sehr viel Zeit, ein belastbares Lastenheft auszuarbeiten.

Ein gutes Rezept für die Erarbeitung der “essentiellen” Anforderungen für ein Lastenheft ist und bleibt die Systemanalyse, die auch im agilen Zeitalter nichts von ihrer Wirksamkeit verloren hat. Und es sind die essentiellen Anforderungen, um die es im Lastenheft vor allem geht.

Struktur und Inhalt

1	Kennzeichne die Anforderungen im Lastenheft eindeutig als solche und trenne sie von Kontextinformation.
2	Gib jeder Anforderung eine eindeutige Identifikation.
3	Formuliere verbindliche Anforderungen mit “muss” .
4	Verwende im Lastenheft durchgängig dieselbe Benennung für dieselbe Sache, auch wenn sich die Bezeichnung häufig wiederholt.
5	Definiere von Beginn zu jeder Anforderung ein Abnahmekriterium bzw. eine Verifikationsmethode.
6	Bevorzuge Tabellen und grafische Darstellungen gegenüber Textbeschreibungen.
7	Formuliere in einem (Ab-)Satz genau eine Anforderung, nie mehrere.
8	Dokumentiere die Quelle einer Anforderung soweit sie bekannt ist bzw. verweise darauf.
9	Definiere potentiell mehrdeutige Begriffe und Benennungen in einem Glossar.
10	Verwende kein „/“ Zeichen oder „bzw.“, ohne eindeutig zu kennzeichnen, ob Du mit dem Schrägstrich „und“ oder „oder“ oder beides „und/oder“ meinst.

Lastenheft mit Stil

1	Verwende bewährte Satzbaumuster wie in den Beispielen weiter unten gezeigt.
2	Formuliere die Anforderungen in ganzen Sätzen und nicht stichwortartig.
3	Verwende Aktivsätze und vermeide Passivsätze
4	Bilde kurze Sätze und vermeide Verschachtelungen
5	Vermeide “Weak Words” (aber, allzu, absolut, andere, äußerst, auch, entsprechend, siehe ausführlichere Liste unten)
6	Vermeide qualitative Adjektive wie z.B. langsam, schnell, schön, heiß, kalt, zyklisch, etc..

Satzbaumuster

Verwende bewährte Satzbaumuster wie z.B. dieses:

• [Bedingung] “Wenn der Druck 1 Bar überschreitet,”
• [Anforderungswort] “muss”
• [Subjekt] “die Steuerung”
• [Objekt] “das Entlastungsventil”
• [Aktion] “öffnen”

Für die Formulierung im agilen Projektmanagement wird gerne das folgende Satzbaumuster verwendet:

• [Als {Rolle}] Als administrativer Benutzer
• [möchte ich {etwas tun}] möchte ich eine Spalte einer Excel-Tabelle importieren
• [um zu {Ziel}] um damit eine Auswahlliste zu füllen

Vermeide “Weak Words”

Die Verwendung von Wörtern aus der folgenden Liste deutet auf unscharfe Vorstellungen hinsichtlich der Anforderungen hin. Wenn Du ein Lastenheft erstellst, dürfen diese Ausdrücke nicht in einem fertigen Teil von Anforderungstexten auftreten (nach Dreher, Marion).

A	ab, aber, absolut, ähnlich, aktuell, allenfalls, allerdings, allzu, als ob, andere, andernfalls, anders, anhaltend, annähernd, anscheinend, ansonsten, auf keinen Fall, augenscheinlich, ausführlich, ausnahmsweise, außerordentlich, äußerst
B	bald, bedienbar, bedingt, bei, beinahe, besonders, besser, beste, bestimmt, bestmöglich, bisweilen
C	ca.
D	damals, daneben, dann, demnächst, denkbar, denn, dereinst, deutlich, dicht, doch, durchaus
E	eben, ehedem, ehemals, eher, eigentlich, eilends, ein bisschen, ein paar, ein wenig, eindeutig, eine Weile, einfach, einige, einigermaßen, einmal, einst, einstmals, einzeln, elementar, eng, enorm, entsprechend, erstaunlich, etliche, etwa, etwa wie, etwas, etwelche, eventuell
F	fabelhaft, fast, fortschrittlich, für den Fall, furchtbar
G	gängig, ganz, gar, gebräuchlich, gegebenenfalls, gegen, genau, genug, gerade so, gering, gesamt, gewaltig, gewisse gewohnt, gleichzeitig, groß, größtenteils, gründlich, gut
H	halbwegs, halbwegs, halt, häufig, hauptsächlich, hin und wieder, höchst, höchstens, höchstwahrscheinlich, hoffentlich
I	intuitiv, inzwischen, irgend, irgendetwas, irgendwelche, irgendwer, irgendwie, irgendwo, irgendwoher, irgendwohin
J	ja, je nachdem, jemand
K	kaum, klassisch, klein, knapp, kolossal, kurz, kürzlich
L	landläufig, lang, langsam, längst, laut, leicht, leise, letztens
M	mal, man, manche, manchmal, mäßig, mehr, mehr oder minder, mehrere, mehrfach, mehrmals, meist, meistens, minder, mitunter, modern, möglich, möglicherweise, möglichst
N	nach Möglichkeit, nahezu, nebenbei, neuartig, neulich, niemals, nur, offensichtlich, oft, öfter, öfters, optimal
P	pauschal, phantastisch, plausibel, prinzipiell
Q	quasi
R	regelmäßig, reichlich, riesig, rund (abschätzend, wie ca.)
S	schätzungsweise, scheinbar, schlecht, schnell, schon, schön, schrecklich, schwer, schwerlich, sehr, selbsterklärend, selten, sicher, sicherlich, so, sogar, solche, soll, sollte, somit, sonstige, sorgfältig, sozusagen, speziell, stark
T	teils, teilweise, u. a.
U	u. U., überaus, überhaupt, üblich, übrige, umgehend, unbedingt, unbeträchtlich, und, und wann, ungefähr, ungemein, ungewöhnlich, ungezählt, unlängst, unmerklich, unter Umständen, unterdessen, etc.
V	verblüffend, vereinzelt, vermutlich, verschieden, verständlich, viel, vielfach, vielleicht, vielmal, vollendet, vollkommen, vorerst, vorhin
W	wahnsinnig, wahrscheinlich, weit, weitaus, weitem, weitere, wenig, wesentlich, wie wenn, winzig, wirklich, wohl, womöglich, Wunders wie
Z	z. T., zahllos, zahlreich, zeitgemäß, zeitweise, ziemlich, zirka, zu, zu meist, zudem, zugleich, zunächst, zuweilen, zyklisch

5. Lastenheft und PM-Standards

Die DIN 69901-5:2009-1 “Projektmanagement – Projektmanagementsysteme – Teil 5: Begriffe” definiert den Begriff Lastenheft im obigen Sinne. Der PMBOK Guide 2008 fasst das Statement Of Work (SOW) etwas enger. Das SOW ist dort als Beschreibung der zu erbringenden Dienstleistungen oder Werke definiert. Dies umfasst lediglich die Spezifikation des Produkts oder der Dienstleistung.

Die ICB 3.0 verzichtet auf die explizite Benennung eines Lastenhefts. Statt dessen spricht sie lediglich von “project scope” und “deliverables”. In der deutschen Competence Baseline NCB 3.0 wird ergänzend zumindest das Begriffspaar “Lastenheft/Pflichtenheft bei der technischen Kompetenz “Leistungsumfang und Lieferobjekte” benannt.

PRINCE2 verzichtet völlig auf die Systematik von Lastenheft und Pflichtenheft, da es die Beschaffungsprozesse nicht beschreibt. Inhaltlich treten stattdessen bei PRINCE2 für das Gesamtprojekt das Projektmandat und die Beschreibung des Projektprodukts ein. Anstelle von Lastenheften, die im Rahmen des Projekts zu erstellen sind, treten bei PRINCE2 der Projektstrukturplan und die Produktbeschreibungen sowie die Managementstrategien.

6. Lastenheft Vorlagen

Das Lastenheft erstellen kannst Du stark beschleunigen. Hier kannst du eine Lastenheft-Vorlage herunterladen. Die Vorlagen gibt es im Microsoft Word-Format sowie für die Allegra Projektmanagement-Software.

7. Häufige Fragen zum Lastenheft

Wie sieht ein Lastenheft aus?

Ein Lastenheft ist ein gegliedertes Dokument, keine Stichwortliste. Es beginnt mit Einleitung, Ausgangssituation und Zielsetzung, führt dann die funktionalen und nicht-funktionalen Anforderungen auf — üblicherweise als Tabelle mit Kennung, Priorität und Abnahmekriterium je Zeile — und schließt mit Lieferumfang, Abnahmekriterien und Glossar. Ein vollständig ausgefülltes Beispiel steht oben in Abschnitt 3.

Was gehört in ein Lastenheft für ein Softwareprojekt?

Zusätzlich zu den fachlichen Funktionen vier Punkte, die in Softwareprojekten regelmäßig fehlen und teuer nachverhandelt werden: die Liste der Schnittstellen zu Nachbarsystemen, die Verantwortung für die Datenmigration, messbare nicht-funktionale Anforderungen (Antwortzeit, Verfügbarkeit, Datenschutz) und das Rollen- und Berechtigungskonzept aus fachlicher Sicht. Details dazu oben unter Was im Softwareprojekt anders ist.

Was ist der Unterschied zwischen Lastenheft und Anforderungskatalog?

Ein Anforderungskatalog ist eine Sammlung von Anforderungen, oft als Tabelle oder Fragenliste für die Anbieterbewertung. Das Lastenheft ist das vollständige Dokument, das diese Anforderungen in einen Kontext stellt: Ausgangssituation, Zielsetzung, Systemgrenze, Lieferumfang und Abnahme. Der Anforderungskatalog ist damit in der Praxis meist ein Teil des Lastenhefts — nämlich der Abschnitt mit den funktionalen und nicht-funktionalen Anforderungen.

Wie ausführlich muss ein Lastenheft sein?

Es gibt kein Seitenmaß. Die brauchbare Grenze ist inhaltlich: Ein Lastenheft ist ausführlich genug, wenn zu jeder Anforderung ein prüfbares Abnahmekriterium formuliert werden kann. Lässt sich das für eine Anforderung nicht formulieren, ist sie zu vage — oder sie gehört gar nicht ins Lastenheft, sondern in die Lösungsbeschreibung des Auftragnehmers. Mehr dazu unter Detaillierungsgrad.

8. Weiterführende Informationen

Lies mehr über wie man einfach ein Pflichtenheft erstellt und wie man den Projekt-Scope richtig abgrenzt. Tipps zur Formulierung klarer Anforderungen findest du in unserem Artikel zum Lastenheft schreiben.