Lastenheft. Anforderungen aus der Kundensicht beschreiben.
Was sind die Vorteile eines Lastenhefts? Wieso brauchen Sie es und wie erstellen Sie Lastenhefte?
Was ist ein Lastenheft?
Ein Lastenheft (auch Anforderungsspezifikation, Anforderungskatalog oder Kundenspezifikation genannt) ist in der Regel ein Dokument, das die Anforderungen an das gewünschte System beschreibt und aus der Kunden- bzw. Nutzersicht formuliert ist. In diesem Sinne entspricht es einem “Wunschzettel” des Kunden, den der Auftragnehmer erfüllen soll. Anforderungen im Lastenheft sind daher in natürlicher Sprache formuliert und äußern sich nicht über die technische Umsetzung. Dafür ist das sogenannte Pflichtenheft zuständig. In der Software-Entwicklung repräsentiert das Lastenheft das Ergebnis der Anforderungsanalyse und beschreibt die Anforderungen an die zu entwickelnde Software. Obwohl traditionell als Dokument angelegt, lässt es sich auch in anderen Formen erstellen, zum Beispiel – in ganz einfacher Weise – in rein mündlicher Form.
Vorteile eines Lastenhefts
Lastenhefte sind ein Mittel zur eindeutigeren Kommunikation: Richtig formuliert liefern sie eine verständliche Beschreibung der Kundenwünsche. Denn zumeist starten Sie nur mit einer abstrakten Idee der spezifischen Fachdomäne, in der diese sich bewegen. Nachbesserungen spät im Projekt, die das Projektende verzögern oder Kosten verursachen, lassen sich vermeiden. Außerdem legen Sie durch Lastenhefte wichtige Rahmenbedingungen für die Entwicklung fest, schaffen ein klares Zielbild und (vertragliche) Verbindlichkeiten, auf die sich im Verlauf des Projekts bezogen werden kann.
Definition des Lastenhefts laut DIN69901-5:
“(Ein Lastenheft ist die) vom Auftraggeber festgelegte Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Auftragnehmers innerhalb eines Auftrags.”
Unterschied zwischen Lastenheft und Pflichtenheft
In der Praxis kommt es häufig zu einer Vermischung des Lasten- und Pflichtenhefts.
Merkmale Lastenheft
- Sicht des Auftraggebers/Kunden/Nutzers
- Kundenebene
- Beschreibt das Was und Warum
- Schafft Grundlage für die Realisierung auf der Auftragnehmerseite
Merkmale Pflichtenheft
- Sicht des Auftragnehmers
- Systemebene
- Beschreibt das Wie und Womit
- Schafft Grundlage für die Auswahl der Angebote auf der Auftraggeberseite
Wie erstellen Sie ein Lastenheft?
Für die Struktur eines Lastenhefts existieren Vorschläge, jedoch keine verbindlichen Regeln. Häufig finden Sie zum Beispiel die Struktur nach H. Balzert (siehe “Lehrbuch der Software-Technik”). In der internationalen Software-Entwicklung hat sich vor allem der IEEE-Standard “Software Requirements Specification” (kurz: SRS) durchgesetzt. Die SRS fand ihren Ursprung im englischen Sprachraum und fasst – im Gegensatz zum Deutschen – Lasten- und Pflichtenheft zusammen. Für beide Standards gilt: Anpassungen an den Lastenheft-Vorlagen sind möglich und auch notwendig.
So erstellen Sie schnell und einfach ein Lastenheft.
Machen Sie den Test. Requirements Engineering
mit objectiF RPM oder objectiF RM »
Inhalt und Aufbau der Software Requirements Specification (SRS)
Die folgende Gliederung entspricht dem IEEE 29148:2011-Standard. Im Internet finden Sie diesen Aufbau häufig mit kleinen Abänderungen, wie zum Beispiel auf Wikipedia.
1. Einführung
- Zweck (Dokument)
- Umfang (Produkt)
- Produktübersicht
- Produktperspektive (Beziehung des Produkts zu anderen Produkten, z.B. als Blockdiagramm)
- Produktfunktionen (Zusammenfassung der Funktionen, die die Software bereitstellt)
- Anwendermerkmale (Beschreibung der Zielgruppe des Produkts)
- Grenzen (Hardware, Regulationen durch Gesetze)
- Definitionen
2. Referenzen (Liste referenzierter Dokumente innerhalb der SRS)
3. Spezifische Anforderungen
- Externe Schnittstellen (Ein- und Ausgaben des Produkts)
- Funktionen (Funktionen, um Ein-und Ausgaben verarbeiten zu können)
- Usability-Anforderungen
- Performance-Anforderungen
- Logische-Datenbank-Anforderungen (Logische Anforderungen an Informationen, die in die Datenbank gespeichert werden sollen wie der Informationstyp)
- Design-Grenzen
- Software-Systemattribute (Zuverlässigkeit, Verfügbarkeit, Sicherheit, Wartung des Produkts)
- Unterstützende Informationen (Beispieldaten, Beschreibung, welche Probleme das Produkt löst)
4. Überprüfung
- bzgl. der Unterpunkte in “3. Spezifische Anforderungen”
5. Anhänge
- Annahmen und Abhängigkeiten (Betriebssystem)
- Abkürzungen
Inhalt und Aufbau des Lastenhefts nach Balzert
- Zielbestimmung: Ziele, die mit der Software erreicht werden sollen
- Produkteinsatz: Anwendungsbereiche und Zielgruppen
- Produktübersicht: Umgebung bzw. Kontext der Software
- Produktfunktionen: Hauptfunktionen des Produktes aus Sicht des Auftraggebers (Anzeigefunktionen, Löschfunktionen etc.)
- Produktdaten: (permanent gespeicherte) Hauptdaten des Produktes (Konfigurationsdaten, Benutzerdaten etc.)
- Produktleistungen: besondere Ansprüche an Funktionen (Zeit, Datenumfang oder Genauigkeit), Sollbedingungen
- Qualitätsanforderungen (Zuverlässigkeit, Benutzungsfreundlichkeit, Performance etc.)
- Ergänzungen
Wer ist für das Lastenheft verantwortlich?
Traditionell unterscheiden Sie bei der Lastenheft-Erstellung zwischen Auftraggeber und Auftragnehmer. Das Lastenheft liegt dann in der Verantwortung des Auftraggebers. Das kann zum Beispiel eine Behörde sein, die ein Lastenheft für eine Ausschreibung erstellt. Oftmals wissen Auftraggeber jedoch am Anfang gar nicht, was sie genau brauchen. Oder ihre Ideen sind noch viel zu abstrakt, um sie in einem Lastenheft niederzuschreiben. Daher bewährt es sich in der Regel, das Lastenheft in Zusammenarbeit mit den Auftragnehmern zu erarbeiten.
Anforderungen richtig dokumentieren
Das Herzstück des Lastenhefts bilden die Anforderungen. Daher dürfen Sie diese nicht einfach dort „hineinklatschen“. Wie in der Gliederung angedeutet, sollten Sie mindestens zwischen funktionalen und nicht-funktionalen Anforderungen im Lastenheft unterscheiden. Zudem braucht jede Anforderung ein eindeutiges Kürzel bzw. eine ID, um identifizierbar zu sein. Auch ihre Priorität, Verbindlichkeit oder Stabilität sollten Sie neben der eigentlichen Beschreibung mit angeben.
In der Regel arbeiten Sie nicht nur textlich, um die Wünsche an das System zu erfassen. Sie setzen zusätzlich Diagramme wie Anforderungs- oder Anwendungsfalldiagramme ein und visualisieren dort die Beziehungen zu anderen Elementen wie Testfällen oder Blockdiagrammen. Diese Arbeitsergebnisse sollten Sie ebenfalls im Lastenheft aufnehmen, damit Sie das Verständnis des Kontexts erhöhen. Da Sie also mit einer Vielzahl an unterschiedlichen Elementen arbeiten, bietet es sich an, ein Tool für das Requirements Engineering und Management zu verwenden. Damit können Sie aus Ihren Projektinhalten gleich auch ein Lastenheft generieren.
Lesen Sie hier weiter, um mehr über Requirements Engineering mit Tool zu erfahren »
Lastenheft – Passt das in die agile Entwicklung?
Lastenhefte sind vor allem aus dem klassischen Projektmanagement bekannt. Dort arbeiten Sie phasenweise, erstellen am Anfang des Projekts das gesamte Lastenheft und entwickeln darauf basierend das System. Klingt einfach, hat aber gravierende Nachteile: Zu Anfang eines Projekts kennt man zum Beispiel noch gar nicht alle Anforderungen. Diese ergeben sich oftmals erst aus den existierenden Systemkomponenten bzw. der Architektur (siehe das Twin Peaks Model). Außerdem treffen Sie kontinuierlich auf Änderungen im Projekt, weil sich zum Beispiel die Ziele der Kunden bzw. Stakeholder ändern – Anforderungen befinden sich also im stetigen Wandel.
Agile Projekte verfolgen hingegen eine iterative Vorgehensweise, um Anforderungen zu ermitteln. Das bedeutet: Sie erarbeiten Anforderungen im Wechselspiel zur Entwicklung, anstatt ganz am Anfang eine ausführliche Anforderungsspezifikation zu erstellen. Ist also das Lastenheft in der agilen Entwicklung noch von Bedeutung?
Ja, absolut. Denn ein initialer, dokumentierter Plan schafft Sicherheit für Auftraggeber und Auftragnehmer. Auch voraussichtliche Kosten und Aufwände müssen sich abschätzen lassen. Daher haben Lastenhefte auch im agilen Projektmanagement ihre Existenzberechtigung. Allein die anfängliche Ausführlichkeit wandelt sich: Zum Beispiel halten Sie zunächst nur die Anforderungen für das erste Release in einem Lastenheft fest, lassen darauf basierend den ersten Prototypen entwickeln und leiten weitere Anforderungen von diesem ab. Das Lastenheft wächst von Release zu Release und ändert sich demnach im Verlauf des Projekts, bietet jedoch immer einen eindeutigen Referenzpunkt im Falle von Missverständnissen oder Unstimmigkeiten.
Wissen zum Mitnehmen
Alles über das Requirements Engineering mit objectiF RM kompakt
So erstellen Sie ein Lastenheft mit objectiF RPM oder objectiF RM
objectiF RPM und objectiF RM liefern Ihnen eine Word-Vorlage für das Lastenheft, die Sie unverändert einsetzen oder an Ihre Bedürfnisse anpassen können. Um die vorgegebene Word-Vorlage zu nutzen, müssen Sie nur ein neues Dokument basierend auf dieser Vorlage erstellen und den Inhalt über einen Mausklick hineingenerieren.
Sie wollen die Vorlage anpassen? Kein Problem! Sie bearbeiten das Layout der Dokumentvorlagen direkt in Word, zum Beispiel definieren Sie dort ein anderes Farbschema für Ihre Überschriften. Die Kapitelstruktur des Lastenhefts können Sie über Drag & Drop definieren.
