Lastenheft erstellen leicht gemacht

Lastenheft

Das Lastenheft (Leistungsverzeichnis, Statement of Work, Anforderungen) beschreibt die Anforderungen des Auftraggebers an die im Rahmen eines Projekts zu erbringenden Leistungen. Die Erstellung des Lastenhefts ist üblicherweise Aufgabe des Auftraggebers. Es dient als Grundlage für Angebotsanfragen und Ausschreibungen.

Der Auftragnehmer setzt nach Erhalt des Lastenhefts die zu erbringenden Ergebnisse (Lasten) in erforderliche Tätigkeiten (Pflichten) um und erstellt das sogenannte Pflichtenheft als Teil des Angebots an den Auftraggeber. Im einfachsten Fall besteht das Pflichtenheft aus einem Verweis auf das Lastenheft sowie einem Termin und einem Preis. Ein ausführliches Pflichtenheft kann schon eine vollständige Projektplanung beinhalten. Besteht enger Abstimmungsbedarf zwischen Auftragnehmer und Auftraggeber, kann ein Pflichtenheft in einer gemeinsamen Arbeitsgruppe oder Arbeitsgemeinschaft erstellt werden. Die Erstellung eines Pflichtenheftes sollte bei größeren Projekten selbst ein Projekt sein.

Lasten- und Pflichtenheft sollten Bestandteil des Vertrags zwischen Auftraggeber und Auftragnehmer sein.

Inhalt

In Anlehnung an das V-Modell XT sollte der Inhalt eines Lastenhefts wie folgt strukturiert werden:

Im folgenden gehen wir der Reihenfolge nach die einzelnen Abschnitte durch.

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 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 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 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 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.

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.

Der richtige 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. Ein sehr detailliertes Lastenheft 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 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 hier geht.

Hier kannst du eine Lastenheft-Dokumentvorlage herunterladen. Die Vorlagen gibt es im Microsoft Word-Format sowie für die Allegra Projektmanagement-Software.

[Gesamt:121    Durchschnitt: 4.9/5]