Lastenheft

Einführung

Gemäß DIN 69901-5 beschreibt das Lastenheft die „vom Auftraggeber festgelegte Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Auftragnehmers innerhalb eines Auftrages“ und ist häufig Bestandteil eines Werkvertrages. Das Lastenheft definiert, was und wofür etwas gemacht werden soll. Es ist z. B. im Software-Bereich das Ergebnis einer Anforderungsanalyse. Das Lastenheft kann der Auftraggeber in einer Ausschreibung verwenden und an mehrere mögliche Auftragnehmer verschicken. Daher wird es oft um formelle Aspekte, die zu einer Ausschreibung nötig sind, angereichert. Die Adressaten des Lastenhefts sind der Auftraggeber sowie die Auftragnehmer.

Mögliche Auftragnehmer erstellen auf Grundlage des Lastenheftes ein Pflichtenheft, welches in konkreterer Form beschreibt, wie der Auftragnehmer die Anforderungen im Lastenheft zu lösen gedenkt. Das Pflichtenheft basiert auf dem Lastenheft und ist das Ergebnis einer Designphase. Der Auftraggeber wählt dann aus den Vorschlägen den für ihn geeignetsten aus.

Lastenheft und Pflichtenheft beinhalten meist einen intensiven Kommunikationsprozess, um die Anforderungen und den Lösungsweg für beide Parteien zu klären und schriftlich festzulegen. Lastenheft und Pflichtenheft fließen als Vertragsbestandteile in einen Werkvertrag ein, so dass alle relevanten Abnahmekriterien beschrieben und abprüfbar sind (Quelle: Balzert, Lehrbuch der Softwaretechnik: Basiskonzepte und Requirements Engineering ,2009, Seite 490 ff).

Um ein Lastenheft übersichtlich zu halten, wird es vorzugsweise in knapp orientierendem Text gefasst und durch Detaillierungen beispielsweise in tabellarischer Form, durch Zeichnungen oder Grafiken ergänzt. Besonders im Software-Bereich (zum Beispiel bei ERP-Systemen) sind Lastenhefte oft als Tabelle mit Feldern angelegt, bei der der Software-Anbieter jede aufgeführte Position je nachdem bewertet, ob er sie im Standard erfüllen kann oder nicht. Dazu ist oft Raum für Anmerkungen. Es gibt dazu auch formalisierende Ansätze, wie Modellierungssprachen.

Die Anforderungen in einem Lastenheft sollten durch ihre Formulierung so allgemein wie möglich und so einschränkend wie nötig formuliert werden. Hierdurch hat der Auftragnehmer die Möglichkeit, optimale Lösungen zu erarbeiten, ohne durch zu konkrete Anforderungen in seiner Lösungskompetenz eingeschränkt zu sein.

Aufbau

Ein Lastenheft lässt sich auf verschiedene Weisen gliedern. Folgende Angaben werden typischerweise berücksichtigt (Vergl. Balzert, Lehrbuch der Softwaretechnik: Basiskonzepte und Requirements Engineering ,2009, Seite 485 ff.):

• Ausgangssituation/Problemstellung
• Beschreibung des Ist-Zustands
• Beschreibung des Soll-Konzepts
• Beschreibung von Schnittstellen
• Funktionale Anforderungen
• Nicht funktionale Anforderungen
• Risikoakzeptanz
• Skizze des Entwicklungszyklus und der Systemarchitektur oder auch ein Struktogramm
• Lieferumfang
• Abnahmekriterien

Verknüpfung mit UML

UML (Unified Modeling Language) wird hauptsächlich im Pflichtenheft zur detaillierten Modellierung der Systemarchitektur und des Verhaltens verwendet. Im Lastenheft, das die Anforderungen aus Sicht der Auftraggeberin oder des Auftraggebers festhält, spielt UML eine untergeordnete, aber dennoch nützliche Rolle, um die groben Vorstellungen zu visualisieren und zu präzisieren. Es hilft, komplexe funktionale Anforderungen zu verdeutlichen, ohne bereits die technische Umsetzung vorwegzunehmen.

=

Anwendungsfalldiagramm (Use Case Diagram) === Das Anwendungsfalldiagramm ist das am besten geeignete UML-Diagramm für das Lastenheft. Es stellt die Systemfunktionen aus der Sicht der Nutzenden dar. Es zeigt, welche Akteure (z.B. Kundin, Administrator) mit dem System interagieren und welche Anwendungsfälle (z.B. "Produkt bestellen", "Rechnung einsehen") sie ausführen können. Es konzentriert sich auf das "Was" und nicht auf das "Wie". Durch die Darstellung der groben Systemgrenzen und der wichtigsten Nutzerinteraktionen schafft es eine gemeinsame Verständigungsbasis zwischen Auftraggeberin und Auftragnehmerin.

Aktivitätsdiagramm (Activity Diagram)

Ein Aktivitätsdiagramm kann im Lastenheft genutzt werden, um einen komplexen Geschäftsprozess zu visualisieren. Es zeigt den Ablauf von Aktionen und Entscheidungen, die eine bestimmte Anforderung erfüllen. Es kann beispielsweise den gesamten Bestellprozess von der Produktauswahl bis zur Zahlungsbestätigung darstellen. Dies hilft, Missverständnisse über die Reihenfolge der Schritte und die Verzweigungen in einem Prozess frühzeitig zu vermeiden. Es beschreibt, was passieren muss, nicht wie es technisch implementiert wird.

Zustandsdiagramm (State Machine Diagram)

In seltenen Fällen kann ein Zustandsdiagramm im Lastenheft verwendet werden, um die Zustände eines Objekts mit komplexem Lebenszyklus darzustellen. Dies ist besonders nützlich, wenn die Geschäftslogik stark von Zustandswechseln abhängt. Ein Beispiel wäre der Bestellstatus, der von "offen" über "bezahlt" zu "versandt" wechselt. Obwohl dieses Diagramm oft im Pflichtenheft zu finden ist, kann es auch im Lastenheft die grundlegenden Regeln eines Prozesses visualisieren.

Klassendiagramm

Im Lastenheft hat das Klassendiagramm nur eine sehr begrenzte Bedeutung, da es bereits in die technische Detaillierung geht. Das Lastenheft konzentriert sich auf die Anforderungen aus der Nutzerperspektive. Eine detaillierte Strukturierung in Klassen ist zu diesem Zeitpunkt oft noch nicht erforderlich und würde die Freiheit der Auftragnehmerin in der Implementierung unnötig einschränken. In der Praxis wird es eingesetzt, um einen Überblick über die Geschäftsobjekte aus fachlicher Sicht zu liefern.