t2informatik » Wissen kompakt » Lastenheft

Was ist ein Lastenheft?

Wie ist der Aufbau, was ist der Unterschied zu einem Pflichtenheft und welche Herausforderungen gilt es zu meistern?

Lastenheft – Definition

Ein Lastenheft ist ein Dokument, das Anforderungen an ein gewünschtes System aus Kunden- bzw. Anwendersicht beschreibt. Es beinhaltet die Ergebnisse der Anforderungsanalyse des Auftraggebers und ist damit ein Wunschzettel, den ein Auftragnehmer realisieren soll. Die DIN 69901-5 definiert ein Lastenheft als „vom Auftraggeber festgelegte Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Auftragnehmers innerhalb eines Auftrages“.

Alternative Bezeichnungen sind Anforderungs-, Anwender- oder Kundenspezifikation, Anforderungskatalog sowie im englischen Requirements Specification bzw. User Specification.

Meist sind die Anforderungen im Lastenheft in natürlicher Sprache formuliert, ohne auf die technische Umsetzung einzugehen. Idealerweise sollten die Formulierungen so allgemein wie möglich und so einschränkend wie nötig formuliert werden, so dass Auftragnehmer Lösungen entwickeln können, ohne zu sehr in ihren Kompetenzen eingeschränkt zu werden. Die technische Umsetzung wird vom Auftragnehmer im sogenannten Pflichtenheft dokumentiert.

Unterschied Lastenheft und Pflichtenheft

Immer wieder gibt es Fragen, was der Unterschied zwischen Lastenheft und Pflichtenheft ist.

Ein Lastenheft besitzt folgende Merkmale:

  • es ist aus Sicht des Auftraggebers formuliert,
  • es fokussiert den Anwender und seine Anforderungen,
  • es beschreibt das „Was“ und nennt das „Warum“ (bspw. in Form von Zielen),
  • es bildet die Grundlage für die Realisierung durch einen oder mehrere Auftragnehmer.

Ein Pflichtenheft besitzt folgende Merkmale:

  • es ist aus Sicht des Auftragnehmers formuliert.
  • es adressiert die Systemebene,
  • es beschreibt das „Wie“ und somit den Plan zur Umsetzung des „Was“ aus dem Lastenheft,
  • es bildet die Grundlage für den Vertragsabschluss zwischen Auftraggeber und Auftragnehmer.

Das Lastenheft ist somit die Basis für das Pflichtenheft. Ohne Lastenheft kein Pflichtenheft.

Lastenheft
\

Vom Auftraggeber zum Auftragnehmer

In einem Lastenheft beschreibt ein Auftraggeber die Gesamtheit seiner Forderungen an die Lieferungen und Leistungen eines Auftragnehmers.

\

Der Aufbau

In unterschiedlichen Branchen gibt es unterschiedliche Vorschläge wie ein Lastenheft aussehen sollte. Gemeinsam haben die meisten Lastenheft-Vorlagen eine Einleitung, eine Beschreibung der gewünschten Lösung und die Anforderungsdefinition.

\

Der Umfang

Ein Problem in der Praxis der Lastenhefterstellung ist der große Umfang des Dokuments. Leicht steigt die Anzahl der beschriebenen Anforderungen in einen vier- oder fünfstelligen Bereich. Die Verwendung von Templates und das Beachten einiger Regeln ergibt daher viel Sinn.

Vorteile und Nachteile Lastenheft

Lastenhefte fördern die Kommunikation zwischen Auftraggeber und potentiellen Auftragnehmern. Durch die Dokumentation der Wünsche von Anwendern und die Erläuterungen von Zielen und Herausforderungen bildet es eine gute Basis zur Beschreibung und nachfolgenden Entwicklung von passenden Lösungen.

Folgende Vorteile bietet die Arbeit mit Lastenheften:

  • Strukturierte und fundierte Beschreibung von Anforderungen und erwarteten Lieferungen und Leistungen des Auftragnehmers.
  • Systematische Auswertung definierter Lasten wird ermöglicht.
  • Steigerung der Vergleichbarkeit der Pflichtenhefte, da diese auf der Struktur der Lastenhefte basieren.

Folgende Nachteile entstehen bei der Arbeit mit Lastenheften:

  • Der Aufwand zur Erstellung ist auch bei Verwendung einer Vorlage hoch.
  • Der Umfang wächst schnell an, wenn viele Details dokumentiert werden.
  • Je umfassender und detaillierter es wird, desto schwieriger wird das Verständnis.
  • Nachträgliche Änderungen durch neue Erkenntnisse lassen sich nur schwer integrieren.

 

Lastenheft Guide - t2informatik Download

Jetzt den Lastenheft Guide kostenlos downloaden.

Alles Wichtige über Lastenhefte, über Inhalte und Strukturen, sowie über Herausforderungen für Unternehmen auf 8 Seiten zum Mitnehmen.

Hier klicken »

Lastenhefte in der Praxis

Szenarien der Lastenhefterstellung

Es gibt drei typische Szenarien bei der Lastenhefterstellung:

  • das klassische Szenario mit einem oder mehreren externen Lieferanten
  • das interne Szenario mit Anforderungen aus einem Fachbereich
  • das Wettbewerbsszenario mit verschiedenen potentiellen Kunden

Im klassischen Szenario möchte ein Auftraggeber eine Leistung von einem Auftraggeber – einem Lieferanten – erhalten. Es ist die Aufgabe des Auftraggebers, das Lastenheft mit den Anforderungen zu formulieren. Diese Aufgabe fällt oft in den Aufgabenbereich des Produktmanagements oder des Marketings. In der Folge liefert der Auftragnehmer das Pflichtenheft.

Beim internen Szenario obliegt dem Fachbereich die Lastenhefterstellung. Da die Umsetzung der Anforderungen durch einen internen Bereich wie der IT erfolgt, verschwimmen hier häufig die Grenzen zwischen Lastenheft und Pflichtenheft, so dass ein Spezifikationsdokument erstellt wird, dass neben den Anforderungen auch Lösungsbeschreibungen umfasst.

Beim Wettbewerbsszenario entwickelt ein Unternehmen Produkte für einen Markt. Die Teilnehmer des Marktes formulieren aber keine Lastenhefte, diese Aufgabe übernimmt auch hier das Produktmanagement oder das Marketing. Hier sind gute Marktkenntnisse wichtig und die Anforderungen werden idealerweise mit einem definierten Prozess ermittelt. Mithilfe des Kano-Modells lässt sich möglicherweise die Wettbewerbsfähigkeit erhöhen und der Einsatz eines Minimal Viable Products kann frühzeitiges Kundenfeedback ermöglichen.

Der Detailierungsgrad

Wer ein Lastenheft erstellt, steht vor der Herausforderung, den passenden Detailierungsgrad zu treffen. Einerseits sollte die Formulierung nicht zu detailliert erfolgen, andererseits dürfen auch keine wesentlichen Aspekte fehlen. Sind bspw. Anforderungen unvollständig, sollte dies leicht zu erkennen sein. Unnötige Inhalte und umfassende Prosatexte erzeugen Aufwand – sowohl bei der Beschreibung als auch bei der anschließenden Auseinandersetzung im Zuge der Lösungsfindung durch den Auftragnehmer. Fehlende Aspekte erhöhen das Projektrisiko, provozieren Nachfragen und führen zu Verzögerungen; diese Zwickmühle führt in der Praxis häufig wieder zu umfassenderen Spezifikationen.

Die Verwendung einer erprobten Vorlage kann bei der Erstellung von Lastenheften helfen. Sie definiert die Struktur, hilft bei einer einheitlichen Detaillierung der Anforderungen, und bietet idealerweise mittels kurzer Kommentare und Beispielen Hinweise zur Formulierung. Gleichzeitig wird die Beschreibung einer Lösung von vornhinein ausgeschlossen – die Lösungsbeschreibung gehört in das Pflichtenheft – so das der Umfang des Dokuments natürlich begrenzt wird. Zusätzlich lässt sich die Übersichtlichkeit durch die Verwendung von Tabellen steigern, denn diese lassen sich leicht erweitern oder kommentieren. Auch die Verwendung von Skizzen, Zeichnungen oder Grafiken steigert das Verständnis, ohne zu viele unnötige Worte zu benutzen.

Die Lastenhefterstellung gilt gemeinhin als anspruchsvolles Handwerk, das gelernt sein will und das Erfahrung benötigt. Es kann also sinnvoll sein, bei der Erstellung auf erfahrene Partner oder Dienstleister zuzugreifen.

Die Anforderungen im Lastenheft

Wer Projekte managt, managt Anforderungen. Deadlines, Meilensteine, Termine, Budgets, Prozessvorgaben, Reports – all das wird häufig als Anforderung deklariert. Anforderungen an ein Projekt sind wichtig, während ein Projekt läuft. Nach Projektende werden diese Anforderungen obsolet – hier liegt der Unterschied zu den Anforderungen an das System oder die Software; diese bleiben auch nach dem Abschluss des Projekts noch bestehen. In das Lastenheft gehören „nur“ die Anforderungen an das System oder die Software. Anforderungen an das Projekt sollten im Projektauftrag oder in einem Projekthandbuch dokumentiert werden. Im Zuge der Definition der Anforderungen empfiehlt es sich auch die Abgrenzung des Systems. Ein System interagiert oft mit anderen Systemen. Ohne Systemgrenzen werden Anforderungen häufig über die Grenzen hinaus spezifiziert. Dies ist nicht nur inhaltlich unnötig, sondern erzeugt sinnlose Aufwände. Mit den Systemgrenzen bestimmen Sie, welche anderen Systeme, Schnittstellen und Regeln bei der Entwicklung beachtet und welche nicht beachtet werden sollen. Sie legen also durch die Systemgrenze den Kontext fest, in dem eine Entwicklung stattfindet. Der Systemkontext sollte dokumentiert und allen Projektbeteiligten zugänglich gemacht werden. Zur Dokumentation bieten sich verschiedene Diagramme wie das Kontextdiagramm aus der „Strukturierten Analyse“ oder ein Use Case Diagramm an.

Häufige Fehler bei der Erstellung

Bei der Erstellung von Lastenheften werden einige Fehler immer wieder begangen:

  • Es werden vorhandene Tools wie bspw. MS Excel verwendet anstelle von spezialisierten Anforderungsmanagement-Tools. Was für oder gegen MS Excel spricht können Sie unter Anforderungen mit oder ohne Excel nachlesen.
  • Eine klare Struktur erleichtert sowohl die Erstellung als auch das Nachvollziehen der beschriebenen Inhalte. Ohne eine sinnvolle Struktur – dies kann bspw. durch das reine Kopieren von Inhalten aus verschiedenen Dokumenten entstehen – geht der Überblick schnell verloren. Ohne Überblick werden widersprüchliche Aussagen übersehen, Aspekte werden wiederholt und Lücken nicht identifiziert.
  • Trotz Verwendung von Vorlagen kann die Menge von Anforderungen bei komplexen Systemen schnell in den fünfstelligen Bereich wachsen. Hier empfiehlt sich die Verwendung von ergänzenden Ebenen, denn sonst liest niemand das Dokument vollumfänglich.
  • Die Priorisierung der Aufgabe zur Erstellung des Lastenheftes und der Faktor Zeit werden unterschätzt. Häufig nimmt die Formulierung zu viel Zeit in Anspruch, da Aufwände unterschätzt werden oder zu geringe Kapazitäten bereitgestellt werden. Die Auswirkungen können zu Lieferverzögerungen oder gar zu verpassten Marktchancen führen.

 

Die Qualität der Anforderungen

Die Definition von Anforderungen aus Sicht der Anwender ist ein wesentlicher Aspekt bei der Erstellung von Lastenheften. Das IEEE (Insitute of Electrical and Electronic Engineers) hat dazu einen Standard zur Spezifikation von Software – die sogenannte Software Requirements Specification (SRS) – veröffentlicht. Die SRS ist nicht gleichbedeutend mit einem Lastenheft, denn sie definiert neben den customer requirements – auch C-Requirements genannt – auch development requirements – entsprechend D-Requirements genannt. In anderen Worten: eine Software Requirements Specification umfasst sowohl Lastenheft als auch Pflichtenheft. Dennoch definiert sie charakteristische Eigenschaften von Anforderungen, die generell auch bei der Erstellung von Lastenheften beachtet werden sollten. Anforderungen sollten daher:

  • korrekt,
  • eindeutig,
  • widerspruchsfrei,
  • nach Wichtigkeit und/oder Stabilität bewertet,
  • verifizierbar,
  • modifizierbar und
  • verfolgbar sein.

 

Agile Lastenhefte

Immer wieder gibt es Diskussionen, ob ein Lastenheft agil sein kann. Die eine Fraktion sieht in einem Lastenheft die Basis für ein nachfolgendes Pflichtenheft und einen zu vereinbarenden Vertrag. Elemente in Verträgen sind bindend, so dass diese nicht wie in einer agilen Entwicklung erst nach und nach vereinbart werden können. Die andere Fraktion argumentiert, dass ein Lastenheft kein statisches Dokument sein muss. Es beschreibt für sie lediglich den aktuellen Stand der Ziele, Wünsche und Anforderungen an ein System – nicht mehr und nicht weniger. Diese Freiheit der Interpretation führt zu einem agilen Lastenheft.

Manchmal wird in diesem Kontext auch über die Vorgehensweise zur Erstellung des Dokuments gesprochen. Muss die Dokumentation der Lasten wirklich mehrere Monate in Anspruch nehmen oder gibt es nicht Möglichkeiten, hier agiler und pragmatischer vorzugehen? Natürlich kann ein Lastenheft, dass in drei Wochen erstellt wird, nicht den gleichen inhaltlichen Umfang und Reifegrad haben wie ein klassisch erstelltes Dokument nach drei oder sechs Monaten. Das ist auch nicht der Anspruch, denn in kurzen Zyklen erstellte und freigegebene Spezifikationen ermöglichen eine zügige Umsetzung. Somit ist auch der Einsatz in agilen Projekten möglich und Lastenhefte lassen sich immer wieder aktualisieren. Voraussetzung für diese flexible Vorgehensweise ist eine gut funktionierende Zusammenarbeit mit dem oder den Lieferanten.

Eine Blogbeitrag, wie Sie innerhalb von 14 Tagen ein Lastenheft erstellen, finden Sie hier  »

Lastenheft - t2informatik Download

Jetzt die Lastenheft Vorlage kostenlos downloaden.

Dokumentieren Sie Ihre Ausgangssituation und Zielsetzung, sowie den Umfang und die Anforderungen der Lösung mit einer übersichtlichen Lastenheft Vorlage.

Hier klicken »

Lastenheft Aufbau und Inhalt

Was gehört in ein Lastenheft?

Es gibt verschiedene Gliederungsvorschläge für Lastenhefte. So definiert bspw. der VDI (Verein deutscher Ingenieure e.V.) unterschiedliche Vorlagen u.a. für den Einsatz von Förder- und Lagersystemen oder den Einsatz von Automatisierungssystemen. Unternehmen sollten sich daher an Vorlagen orientieren, die speziell für ihre Branche  definiert wurden. In der Softwareentwicklung ist die von Helmut Balzert im „Lehrbuch der Softwaretechnik: Softwaremanagement“ beschriebene Gliederung weit verbreitet:

  • 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
  • Produktdaten: (permanent gespeicherte) Hauptdaten des Produktes
  • Produktleistungen: besondere Ansprüche an Funktionen (Zeit, Datenumfang oder Genauigkeit), Sollbedingungen
  • Qualitätsanforderungen  wie Zuverlässigkeit, Benutzungsfreundlichkeit, Performance etc.
  • Ergänzungen

Nachfolgend finden Sie eine Beschreibung eines alternativen Aufbaus.

Die Einführung

Zu Beginn der Spezifikation ist es wichtig, ein gemeinsames Verständnis aufzubauen. Hier helfen Erläuterungen zum Zweck und Aufbau des Dokuments, zu verwendeten Begriffen und zum Umfang der gewünschten Lösung:

  • Deckblatt mit Projektbezeichnung, Projektleiter, Verantwortlichkeit, Erstellungs- und Änderungsdatum, Ablageort, Version und Änderungsverzeichnis, Ersteller und Mitwirkenden, Zustand des Dokuments (z.B. initial, fertig) und Prüfverzeichnis
  • Zweck des Dokuments
  • Übersicht zum Aufbau des Dokuments
  • Ausgangssituation und Zielsetzung
  • Umfang der gewünschten Produkts, der Software, des Systems oder der Leistung des Auftragnehmers
  • Verweise auf andere Quellen und Ressourcen
  • Definitionen und Erläuterungen zu Begriffen

Darüber hinaus kann es sehr sinnvoll sein, bereits frühzeitig das Nutzenversprechen des Systems festzuhalten. Ein System hat nur dann einen Sinn, wenn es den Anwendern einen Nutzen verspricht und einen Zweck erfüllt.

Die allgemeine Beschreibung

Bei der allgemeinen Beschreibung geht es um die Einordnung der gewünschten Produkts in die vorhandene Infrastruktur des Unternehmens und die Beschreibung wesentlicher Merkmale:

  • Anwendermerkmale mit der Beschreibung der Zielgruppe des Produkts, den Motiven und Einstellungen
  • Produktperspektive mit der Beschreibung der Beziehung des Produkts zu anderen Produkten
  • Zusammenfassung der Funktionen, die das System bereitstellen soll
  • Einschränkungen und Grenzen für die Entwicklung, bspw. gesetzliche Regeln, Normen oder interner Vorgaben
  • Annahmen und Abhängigkeiten, die die Entwicklung beeinflussen, aber nicht behindern wie bspw. die Verwendung von definierten Datenbanken oder Programmiersprachen
  • Beschreibung des Systems inklusive Systemkontext, Systemarchitektur, Schnittstellen, Datenmodell etc.
  • Lieferumfang mit Beschreibung der Leistung des Lieferanten, der Inbetriebnahme der Lösung etc.

 

Die Anforderungen

Anforderungen sind das zentrale Element in einem Lastenheft. Sie sind in der Praxis nicht immer so leicht zu erheben, wie es vielleicht auf den ersten Blick erscheinen mag. Mögliche Interessenkonflikte der Stakeholder, unklare Rahmenbedingungen oder sich ändernde Prioritäten schon zu einem solch frühen Zeitpunkt sind nicht selten. Folgende Anforderungsgliederung ist häufig anzutreffen:

  • funktionale Anforderungen
  • nicht-funktionale Anforderungen mit Aussagen zur Performance, Qualität, Usability, Ergonomie etc.
  • externe Schnittstellen
  • Design Grenzen bzw. Constraints
  • sonstige Anforderungen wie z.B. logische Datenbank-Anforderungen
  • unterstützende Informationen wie Beispiele, Modelle, Skizzen oder Grafiken

Eignen sich andere Gliederungen besser, sollten hier entsprechende Anpassung vorgenommen werden.

Die Vorgaben und Einschränkungen

Es besteht die Möglichkeit, Informationen zu Einschränkungen oder Vorgaben, die das System erfüllen muss, im Kapitel „Anforderungen“ oder in einem separaten Kapitel zu dokumentieren. Dabei kann es sich um folgende Aspekte handeln:

  • Benutzbarkeit
  • Zuverlässigkeit
  • Effizienz
  • Änderbarkeit
  • Übertragbarkeit
  • Wartbarkeit
  • Risikoeinschätzung
  • Abnahmekriterien

 

Die Anlagen

Im letzten Kapitel sollten Anlagen und Verzeichnisse übersichtlich verwaltet werden. Hierzu gehören:

  • die im Kapitel „Einführung“ bereits genannten Quellen und Ressourcen. Auch Verweise bspw. auf den Projektantrag oder das Projekthandbuch mit dort spezifizierten Anforderung lassen sich hier darstellen.
  • Abkürzungsverzeichnis, Tabellenverzeichnis, Bildverzeichnis
  • sonstige Ergänzungen wie Notizen oder eine Liste mit Anforderungen, die erst zu einem späteren Zeitpunkt realisiert werden sollen.

 

Herausforderungen für Unternehmen

Erfahrung und Wirtschaftlichkeit

Die Beschreibung von Anforderungen aus Anwendersicht zur Entwicklung von Software, Systemen, Produkten oder Services ist nicht so leicht, wie es im ersten Moment klingt mag. Es empfiehlt sich daher, eine Lastenheft-Vorlage zu verwenden, die auf die konkreten Herausforderungen angepasst wird. Dies erleichtert die Formulierung der Inhalte, erfordert aber auch Erfahrung. Am Markt gibt es verschiedene Partner, die sich auf die Erstellung von Lastenheften spezialisiert haben. Natürlich verursacht die Arbeit mit externen Partner Kosten, ungenau oder widersprüchlich formulierte Anforderungen kosten aber vermutlich mehr. Wer sich also mit der Definition der Lasten beschäftigt, sollte immer auch einen Blick auf die Wirtschaftlichkeit werfen. Nimmt die Erstellung zu viel Zeit in Anspruch, werden möglicherweise Chancen vertan. Stehen nicht genügend Kapazitäten zur Verfügung verzögert sich die Erstellung. Hier helfen nur eine frühzeitige Priorisierung und ein miteinander vereinbartes Vorgehen. Und Erfahrung.

Gerne stellen wir Ihnen Wissen, Erfahrung und 100% Leidenschaft für Ihre Softwareentwicklung und Anforderungsanalyse zur Verfügung. Wir helfen Ihnen bei der Beschreibung von Use Cases und der Erhebung, Strukturierung und Verwaltung von Anforderungen. Dabei achten wird auf Konsistenz, Vollständigkeit und Nachvollziehbarkeit. Wir unterstützen Sie beim Identifizieren von technischen Zusammenhängen und berücksichtigen Stakeholder, Ziele und Randbedingungen. Und wir planen und steuern Ihre Projekte mit diesen Anforderungen auf Basis definierter Prozesse.

Hier erfahren Sie mehr zum Thema Softwareentwicklung »

Weitere Details und Hintergründe ...
Share This