Lastenheft: Von null auf hundert mit Vorlage!
von Jörg Friedrich
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. 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.
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. 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.
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 Gesamtsystemarchitektur 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 Eintrittswahrscheinlichkeit 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.
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.
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. 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 Umfeld 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, ausnahms- weise, 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, ent- sprechend, 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, gleich- zeitig, 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 |
4. Lastenheft und PM-Standards
Die DIN 69901-5:2009-1 “Projektmanagement – Projektmanagementsysteme – Teil 5: Begriffe” definiert den Begriff Lastenheft im obigen Sinne. Der PMBOK(R) 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 Produktstrukturplan und die Produktbeschreibungen sowie die Managementstrategien.
5. 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.
