In 5 Schritten erfolgreich ein Lastenheft erstellen

Du hast ein großes Projekt vor dem Bug und benötigst ein Lastenheft? Das Lastenheft soll professionellen Standards entsprechen – und gleichzeitig möglichst schnell fertiggestellt sein?

Seit über 10 Jahren haben wir uns darauf spezialisiert, professionelle Lastenhefte zu schreiben – und helfen Projekten damit Dein Projektrisiko frühzeitig um über 70% zu senken.

Seit vielen Jahren erstellen wir Lastenhefte für technische Systeme. Der genaue Prozess des Lastenheft erstellen wird weiter unten beschrieben. Hier ein erster Überblick:

  • Schritt 1: Erfassen: Wir starten mit dem System Footprint Workshop, um gemeinsam mit Dir und Deinem Team einen Überblick über die existierenden und notwendigen Anforderungen zu erhalten.
  • Schritt 2: Sortieren: Wir übertragen die wichtigen Inhalte jetzt in unsere professionelle Lastenheftvorlage, denn in dieser Phase beginnt bereits das tatsächliche, kontinuierliche Erstellen.
  • Schritt 3: Füllen: Jetzt gibt es einen ersten Überblick über das System, die Anforderungen und alle Informationen. Somit ist es an der Zeit, noch vorhandene Lücken zu klären und zu füllen.
  • Schritt 4: Prüfen: In dieser Phase nutzen wir Peer Reviews. Sie sind sehr nützlich, um schnell die Qualität und den Reifegrad des Lastenheftes zu erhöhen.
  • Schritt 5: Freigeben: In der letzten Phase gehen wir in einen moderierten Release-Review-Workshop, bei dem sich alle treffen und noch einmal alles durchgehen. Wir dokumentieren die Auffälligkeiten mit einer Review-Checkliste und pflegen anschließend alle offenen Punkte ein.

Ein gutes Lastenheft reduziert das Projektrisiko um 70%!

Der System Footprint

Du must ein Lastenheft erstellen?

Hier kannst Du ein kostenloses Erstgespräch vereinbaren.

Was gehört ins Lastenheft und was nicht?

Projekt vs. Produkt: Wenn wir ein Projekt haben, reden wir von Anforderungen. Wir haben Zeit- und Meilensteine, Funktionalitäten, Schnittstellen und vieles mehr – und all das nennen wir Anforderungen. Der kleine, aber feine Unterschied ist, es gibt Anforderungen an ein Projekt und es gibt Anforderungen an das System. Das, was am Ende rauskommen soll, unabhängig davon, ob das in Stahl oder in Elektronik oder in Bits und Bytes geht, hat auch Anforderungen.

Der entscheidende Unterschied zwischen Anforderungen an ein Projekt und an ein System ist Folgender: Die Anforderungen an das Projekt sind unglaublich wichtig, WÄHREND das Projekt läuft. Diese Anforderungen an das Projekt werden aber in dem Moment historisch, wenn das Projekt abgeschlossen ist.

Und das ist der Unterschied zu den Anforderungen an ein technisches Systems: Dort sind und bleiben Anforderungen noch immer existent, wenn das Projekt abgeschlossen ist. Das ist ein ganz wichtiger Punkt: In das Lastenheft gehören nur die Anforderungen an das technische System. Die Anforderungen an das Projekt gehört in ein anderes Dokument. Z.B. in ein Projekthandbuch oder einen Projektauftrag. Ich weiß, dass viele so etwas dann plötzlich doch wieder nicht haben, aber da gehört es hin.

Wie aber kann ich innerhalb von 3 Stunden alle relevanten Anforderungen erhalten?

Lasten vs. Pflichten: Ein anderes beliebtes Spiel ist die Unterscheidungen von Lasten und Pflichten. Auch da reden wir wieder von Anforderungen. Wir haben ein Lastenheft, sauber mit technischen Anforderungen. Und wir haben ein Pflichtenheft. Auch da sind Anforderungen drin. An dieser Stelle müsst wir wirklich genau aufpassen: In ein Lastenheft gehören nur Anforderungen und Wünsche aus Sicht des Kunden. Das sind Anforderungen, das sind Lasten, das ist das, was ich mir als Auftraggeber wünsche.

Wir beschreiben nicht die Lösung. Es ist Teil der Antwort im Pflichtenheft, wie dieses Problem aus Sicht des Projektes zu lösen ist. Und da passiert häufig etwas, was ich in der Praxis erlebt habe: Lasten und Pflichten werden vermischt und sind plötzlich eins. Ich habe Lastenhefte gesehen, die gehen wirklich bis auf die unterste Ebene, mit Pseudocode wird dann Funktionalität in Software dargestellt.

Das ist Quatsch, die völlig falsche Flugebene. In einem Lastenheft beschreibe ich, z.B. das ich als Auftraggeber eine Funktion brauche, die muss das und das können. Ob das hinterher z.B. in Hardware oder in Software gegossen wird, ist Entscheidung auf der Projektebene. Sie sollen die sinnvollste Lösung in Bezug auf Zeit und Geld finden. Aber das ist nicht Aufgabe des Auftraggebers, also gehört das auch nicht ins Lastenheft.

Wie detailliert sollte ein Lastenheft sein?

Das Problem ist den meisten bekannt: Wenn wir Lasten erstellen und somit Anforderungen definieren, ist es immer wieder eine Herausforderung, die richtige Flugebene zu finden. Das bedeutet nicht zu detailliert reingehen – aber auch nicht zu wenig schreiben. Das ist in der Tat ein Balanceakt.

Besonders im Kontext von Lastenheften ist diese Frage extrem relevant, denn Lastenhefte haben eine ganz andere Funktion als zum Beispiel Pflichtenhefte. Mit dem Lastenheft formulieren wir Wünsche und Anforderungen aus Sicht des Kunden, das heißt, hier müssen wir sehr gut aufpassen, dass wir das richtige Abstraktionsniveau vorlegen.

Denn sonst wird das Lastenheft entweder mit unsinnigen Inhalten und risikoreicher Prosa aufgeblasen – nach dem Motto viel hilft viel – oder das Lastenheft ist inhaltlich zu dünn und das Papier nicht wert, auf dem es steht. In beiden Fällen rausgeschmissenes Geld und gleichzeitig erhöht es Ihr Projektrisiko deutlich.

Um ein konkretes Beispiel zu geben: Mir wurden Lastenhefte gezeigt, in denen detaillierte Lösungen beschrieben waren. Das ist definitiv der falsche Level für das falsche Dokument. Es macht sehr viel Sinn zu sagen, „ich brauche im System eine Funktion X, die Y tut“. Aber ich beschreibe NIEMALS auf der Lastenheft-Ebene eine detaillierte Lösung. Gewinnen tust Du damit nichts. Du erhöhst nur Dein Projektrisiko, da Dein Auftragnehmer, im Zweifel wörtlich, ihre möglicherweise auch noch falsch beschriebene Lösung umsetzt. Schreibst Du aber zu wenig, dann gibt es keine Grenzen für den Auftragnehmer und er betreibt häufig „Jugend forscht“.

In beiden Fällen darfst Du Dich auf finanzielle Nachforderungen Deines Lieferanten einstellen. Egal wie recht oder unrecht er hat, es führt bei Dir zu Aufwand sich damit rumzuschlagen und in der Regel kommt es auch zu Verzögerungen im Projekt.

Der richtige Detaillierungsgrad ist also extrem entscheidend. Nur so kann ein Lastenheft wirklich effektiv das Projektrisiko reduzieren. Um aber ein Gefühl für den richtigen Detaillierungsgrad zu haben bedarf es jahrelanger Erfahrung bei der Erstellung eines Lastenheftes. Es ist ein anspruchsvolles Handwerk, das gelernt sein will.

Falls Du nicht sicher bist, helfe ich Dir gerne weiter. Erfahre mehr über meinen Service und wie ich Dir in zwei Wochen ein professionelles Lastenheft erstelle.

Welche Kapitel sollten im Lastenheft enthalten sein?

Diese Frage, die mich von einem Hörer erreichte, begegne ich immer wieder. Im Prinzip basiert sie auf der zugrunde liegenden Frage: Welcher Aufbau, welche Struktur, welcher Inhalt machen Sinn in einem Lastenheft?

Wenn wir ein Lastenheft schreiben und es jemandem zum Lesen geben, ist es erst mal ganz wichtig, ein Verständnis aufzubauen. Die Lastenhefte, die ich im Auftrag für Kunden anfertige, sind so strukturiert, dass am Anfang eine Einleitung steht. Das heißt, wir erstellen ein kurze Übersicht: Was ist der Hintergrund, warum ist das Lastenheft entstanden, wer hat es überhaupt erstellt, gibt es Referenzen, welche Prozesse sind einzuhalten, welche Tools haben wir benutzt usw.

Ein weiteres sehr wichtiges Kapitel, was wir erstellen ist für das Verständnis wichtig: Eindeutig zu kommunizieren, was das System ist für welches das Lastenheft erstellt wurde. So klären wir direkt zu Beginn des Lastenhefts wie die Genzen des Systems definiert sind, und was im Lastenheft steht und was nicht drin steht. 

Ein wesentlicher nächster Teil ist das Nutzenversprechen des Systems. Ein System hat ja nur dann einen Sinn, wenn es einen Nutzen verspricht und einen Zweck erfüllt. Dementsprechend müssen wir das Nutzenversprechen definieren und dokumentieren. Und dieses Versprechen wird über sogenannten Use-Cases, die Benutzungsfälle, erlebbar, wenn der Nutzer sich mit dem System beschäftigt. Hinzu kommen die sogenannten Stakeholder-Constraints, also die Einschränkungen und Vorgaben von Interessensgruppen.

In einem weiteren Kapitel beschreiben wir die gewünschten Funktionen des Systems. Zusätzlich steht ein System in der Regel nicht für sich alleine, sondern hat Schnittstellen nach außen – im Grunde das, was wir auch bei der Schnittstellenabgrenzung erarbeitet und dokumentiert haben.

Und nun noch ein ganz wesentliches Kapitel: Die technischen Einschränkungen und Vorgaben. Als eine Art Eselsbrücke, damit wir alle Sachen berücksichtigen, sprechen wir immer von RAMST (Reliability, Availability, Maintainability, Safety, Testability). Eben die technischen Vorgaben oder Einschränkungen, die das System erfüllen muss.

Wer erstellt das Lastenheft und wer sollte seinen Input geben?

Eine absolut berechtigte Frage, weil ich auch in Projekten immer wieder erlebe, dass Unsicherheit herrscht, wer eigentlich für das Lastenheft zuständig und verantwortlich ist.

Die Frage ist jetzt natürlich: Wer erstellt das Ganze? Normalerweise gibt es zwei verschiedene, aber typische Szenarien.

Das eine klassische: Auftraggeber bestellt bei Lieferant. Es ist also die Aufgabe des Auftraggebers, ein Lastenheft zu schreiben und klar zu formulieren, was für Wünsche und Anforderungen es an das System hat. Der Lieferant nimmt sich das Lastenheft, bewertet es und setzt im Projektablauf ein Pflichtenheft dagegen.

Der Auftraggeber ist dafür zuständig, das Lastenheft zu erstellen. Den Input bekommt er in der Regel aus seinem eigenen Haus. Vor ca. einem Jahr habe ich ein Lastenheft für eine Robotik-Verkettungsanlage in der Fertigung eines mittelständischen Maschinenbauers geschrieben. Die Aussage des Projektleiters war: „Wir haben eine Ausschreibung und wollen fünf Millionen Euro in eine Robotik-Anlage investieren. Und da brauchen wir ein Lastenheft.“ Unser Job als Spezialisten war es, dieses Lastenheft zu erstellen, und der Input kam aus dem Unternehmen: Von den verschiedenen Beteiligten aus Entwicklung, Produktion, Qualitätsmanagement usw. Das ist das eine typische Szenario.

Das zweite ist etwas kniffliger, kommt aber mindestens genauso häufig vor. Das Unternehmen entwickelt ein Produkt und liefert in einen Markt hinein. Das bedeutet, dass es den Kunden in dem Sinne nicht gibt. Eine typische Situation ist z.B. ein großer Werkzeughersteller, der Werkzeuge für Handwerker baut. Aber ein Handwerker erstellt kein Lastenheft. Ähnlich bei einem namhaften Unternehmen aus der feinmechanisch-optischen Industrie, das beispielsweise Medizintechnikprodukte, Ferngläser oder Mikroskope entwickelt. Aber auch hier gibt es ja nun nicht den Vogelforscher, der ein Lastenheft schreibt und sagt, wie er sein Fernglas gern hätte. Ein weiteres, beispielhaftes Szenario gab es bei einem großen Hersteller medizintechnischer Geräte, der in Krankenhäuser oder Arztpraxen liefert. In der Regel schreiben aber auch Ärzte keine Lastenhefte für diese Produkte.

Hier existiert innerhalb eines Unternehmens typischerweise eine wesentliche Rolle, die das dann übernimmt und quasi die Kundensicht einnimmt: Der Produktmanager bzw. das Marketing. In diesem Fall sind also der Produktmanager und das Marketing für das das Lastenheft verantwortlich.

Da oftmals die Erfahrung fehlt, macht es Sinn sich professionelle Unterstützung bei der Erstellung eines Lastenheftes zu holen.

Podcast-Folgen zum Lastenheft erstellen

In meinem Zukunftsarchitekten-Podcast habe ich mehrere Folgen zum Thema Lastenheft erstellen produziert. Hier meine Empfehlungen:

Die Episoden dauern jeweils 20 bis 30 Minuten. Du kannst sie einfach über iTunes oder Android abonnieren und auf dem Smartphone hören.

[thrive_leads id=’5883′]

Ein professionelles Lastenheft erstellen lassen

Die Verantwortung für ein Lastenheft liegt in der Regel bei Projekt-Entscheidern, wie dem Geschäftsführer, Abteilungsleiter oder Projektleiter. Sie wollen einen Auftrag an einen Dienstleister oder Lieferanten vergeben und benötigen dafür ein Lastenheft. Mal ist das Lastenheft die Basis für eine Ausschreibung. Häufig fordern auch Dienstleister ein Lastenheft ein, um ein seriöses Angebot erstellen zu können. Es herrscht entsprechender Zeitdruck. Und der Druck führt zu entsprechenden Fehlern.

Schon durch Deinen Besuch auf dieser Seite legst Du einen ersten wichtigen Baustein für Deinen Projekterfolg. Denn Projekte ohne Lastenheft verdoppeln oder verdreifachen häufig Ihre Budgets.

Die Gefahr ist groß, dass das Projekt aus dem Ruder läuft. Aus einer Millionen Kosten werden drei Millionen. 9 Monate verwandeln sich in drei Jahre. Nicht wenige Projekte krepieren schlussendlich – weil die Anforderungen zum Start nicht richtig erarbeitet wurden.

Du gehst einen anderen Weg. Eine Lastenhefterstellung hat für Dich folgende Vorteile:

  • Du erhältst ein professionelles Ergebnis. Das Lastenheft hat eine sinnvolle Struktur und den richtigen Detaillierungsgrad. Es wird sichergestellt, dass nichts vergessen wird.
  • Du sparst viel Zeit. Ein Lastenheft selbst zu erstellen, dauert in der Regel mehrere Monate – wenn keine Erfahrung vorhanden ist. Ich erstelle ein Lastenheft innerhalb von zwei Wochen.
  • Du erhöhst die Sicherheit. Du kannst guten Gewissens in das Projekt starten. Weil Du von Anfang an den Überblick hast. Du kannst den  Dienstleister besser steuern und führst das Projekt so zum Erfolg.

Kundenstimmen

Wir waren sehr unsicher, wie wir das Projekt angehen sollten. Wir hatten keine Ahnung wie ein Lastenheft aussieht, geschweige denn, wie wir eines erzeugen können. Darum haben wir uns für die professionelle Unterstützung bei der Erstellung unseres Lastenheftes entschieden.

Das großartigste ist, dass man sich die ganze Zeit sicher ist, dass das Lastenheft schnell und einfach erledigt sein wird. Wir haben uns durch die Zusammenarbeit sehr viele schlaflose Nächte erspart.

Ich empfehle es jedem, der ein Lastenheft braucht. Ich glaube es gibt keinen effizienteren Prozess ein Lastenheft zu erstellen.

Du brauchst schnell ein Lastenheft?

In einem Gespräch können wir mögliche Lösungen besprechen. 100% Vertraulich, 100% unverbindlich.

  • Unverbindlich anfragen
  • Vom Expertenwissen profitieren
  • Sofort Projektrisiko senken

Seit vielen Jahren beschäftigen ich mich damit, wie Lastenhefte erstellt werden. Meine Expertise im Überblick:

Über 20 Jahre Erfahrung

Björn Schorre bringt mehr als 20 Jahre Erfahrung aus der Automobilbranche, der Automatisierung der Telekommunikationstechnik mit. Er arbeitet als Software-Architekt für Embedded Systeme. Er verfügt über fundierte Kenntnisse in der System- und Prozessentwicklung, sowie dem Projektmanagement. In verschiedenen Projekten bis zu Projektbudgets in zweistelliger Millionenhöhe hat er seinen Kenntnisse erworben. Außerdem gibt er sein Wissen in Webinaren weiter und  ist Betreiber des Podcasts der Zukunftsarchitekten.

Über 50 zufriedene Kunden

Für über 50 zufriedene Kunden habe ich Lastenhefte erstellt. Dabei habe ich Erfahrung aus unterschiedlichen Branchen gesammelt, wie IT, Maschinenbau und Medizintechnik. Nach einem praxiserprobten Prozess kann ich branchenunabhängig ein professionelles Lastenheft erstellen.

Ein Festpreis für Dich

Durch meine jahrelange Erfahrung kann ich Dir ein Festpreis-Angebot erstellen. So hast Du absolute Sicherheit bei den Kosten. Durch die einmalige Investition kannst Du das Projektrisiko reduzieren.

Beispiele von Kundenaufträgen

Automatisches Messsystem für Servicecenter

Kunde: HILTI Service

Auftrag: Erstellung eines Lastenheftes für ein Messsystem, das im Servicecenter zur Prüfung und Kalibrierung eingesetzt wird und mit dem zentralen Flottenmanagement synchronisiert ist.

Laser-Distanzmessgerät mit kameragestützter Zielerfassung

Kunde: HILTI Laser-Messsysteme

Auftrag: Erstellung eines initialen Lastenheftes für ein mechatronisches System (Mechanik, Elektronik, Embedded Software) zur Angebotsanfrage bei mehreren Entwicklungsdienstleistern.

Dokumenten-Management-System für Medizintechnik

Kunde: B.Braun Aesculap

Auftrag: Erstellung eines initialen Lastenheftes für ein DMS-Systems, damit die IT Abteilung ein neues System zur Verwaltung von Zulassungsdokumenten bei einem externen Dienstleister beauftragen kann.

Robotik-Verkettungssystem für Maschinenbau

Kunde: KSM Castings

Auftrag: Erstellung eines initialen Lastenheftes für ein Robotik-Verkettungssystem in der Produktion, damit der Einkauf mehrere Automatisierungsdienstleister anfragen kann und belastbare Angebote erhält.

Quadcopter für professionelle Logistik

Kunde: airstier

Auftrag: Erstellung eines Lastenheftes für ein Quadrocopter mit Hybridantrieb für die Anwendung im professionellen Logistikumfeld. Auf Basis des Lastenhefte konnte die Entwicklung des Quadcopters geplant und umgesetzt werden.

Kraftstoffzuheizer für LKW und Landmaschinen

Kunde: Hengst

Auftrag: Erstellung eines Lastenheftes für einen mechatronischen Kraftstoffzuheizer für Lastwagen und landwirtschaftliche Maschinen. Das Lastenheft diente zur Übergabe eines Teilprojektes an einen Entwicklungs- und Fertigungsdienstleister.

Welche Situation kennen wir in der Praxis?

Lastenhefte beschreiben das „Wünsch-dir-was“ aus Sicht des Kunden. Sie sind ein wichtiges Puzzlestück in einem Projekt, um einem Lieferanten die erwarteten Anforderungen zu beschreiben. Entsprechend der DIN 69901-5 sind Lastenhefte „vom Auftraggeber festgelegte Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Auftragnehmers innerhalb eines Auftrages“. Das Gegenstück dazu sind Pflichtenhefte. In der Episode #7 „Lastenhefte vs. Pflichtenhefte“ bin ich im Detail auf den Unterschied eingegangen.

Im technischen Umfeld haben wir häufig die Situation, dass das Projektteam ein Lastenheft erstellen muss. Oft sind es Teammitglieder, die diese Aufgabe einfach irgendwie mit erledigen. Diese haben oft weder Zeit, noch Lust, noch Ahnung. Dementsprechend ist ein solches Lastenheft das Ergebnis eines unerfahrenen Autors. Die Inhalte sind häufig irgendwie zusammengeschrieben und halten sich nur an wenige oder keine Dokumentationsregeln. Leider sind die Begriffe „Lastenhefte“, „Pflichtenhefte“ und „Spezifikationen“ nicht klar gegeneinander abgegrenzt, so dass sie in einem Dokument auch oftmals vermischt werden.

Das Ergebnis ist ein Lastenheft, das untauglich ist für die Anfrage eines Lieferanten. Bei Angeboten fehlt die Sicherheit, das der Lieferant wirklich alles verstanden hat und nicht hinterher Nachforderungen stellt. Außerdem sind die Aussagen von mehreren Lieferanten auf dieser unsicheren Basis nicht vergleichbar.

Was gebraucht wird, ist ein belastbares Lastenheft mit dem richtigen Detaillierungsebene.

Erstellung eines Lastenheftes

Ich beschreibe hier meine Vorgehensweise, wie ich Lastenhefte für ein technisches System erstelle. Wie schon gesagt, das ist mein „Kochrezept“. Probiere es aus und passe es pragmatisch auf Deine Bedürfnisse an.

  1. Den Nutzen des Systems klären
    Wenn ein System oder Produkt entwickelt wird, dann verspricht dieses System ein Nutzen gegenüber dem Kunden. Dieses Nutzenversprechen ist der Grund, warum der Kunde das System oder Produkt kauft. Beim Beispiel des iPhones ist das Kern-Nutzenversprechen Image und einfache Bedienung. Das Wissen um den Nutzen ist für die Entwicklung entscheidend. Wir können bewerten, ob eine Anforderung das Nutzenversprechen unterstützt oder nicht. Auch für die Entwickler und die Tester ist das Wissen um das Nutzenversprechen wichtig, da sie auf dieser Basis ihre Aufgaben besser einschätzen können. Ich nutze den System Footprint und führe einen Workshop mit allen relevanten Spezialisten durch, um das Nutzenversprechen zu ermitteln.
    Das Vorgehen habe ich in der Episode #77: „The System Footprint 3.0“ erläutert.
  2. Alle Informationen sammeln und sichten
    Nun geht es darum, alle vorhanden Informationen zu sammeln. Das können alte Spezifikationen sein oder auch sonstige Dokumente wie Präsentationen und Meeting-Protokolle. Ich suche alle Informationen zusammen. Dazu gehört auch, dass ich mit Spezialisten und Stakeholdern Gespräche führe, um von ihnen weitere Informationen zu dem System zu erhalten. Wenn ich einen ersten Stand der Informationen geschaffen habe, geht es daran, die Informationen zu sichten. Dazu lese ich viele Dokumente quer, um mir einen Überblick zu verschaffen. Das Ergebnis aus dem System Footprint Workshop dient mir jetzt als Basis. Ich fülle den System Footprint weiter mit Inhalt.
  3. Das vorläufige Lastenheft erstellen und Peer-Reviews durchführen
    Wenn ich nun Klarheit habe, erstelle ich ein vorläufiges Lastenheft. Dazu nutze meine praxiserprobte Lastenheft Vorlage. Ich schreibe alle Anforderungen an das zu entwickelnde System auf. Dabei entscheide ich aufgrund des Nutzenversprechens, welche Anforderungen für das zu entwickelnde System relevant sind. Zwischenstände des Lastenheftes gebe ich immer wieder anderen Spezialisten für ein Peer-Review und pflege ihre Rückmeldung ein. Wie ein Peer-Review funktioniert, habe ich in Episode #13 „Geheimwaffe Review“ im Detail erläutert.
  4. Das finale Lastenheft nach Freigabe-Review abschließen
    Wenn ich das Lastenheft möglichst vielen relevanten Personen zum Peer-Review gegeben habe, erhalte ich eine hohe Sicherheit, dass das Dokument weitestgehend vollständig ist. Nun lade ich die wichtigsten Personen zu einem Freigabe-Review ein. Nach den Peer-Reviews ergeben sich erfahrungsgemäß keine gravierenden Gesichtspunkte mehr. Wenn in diesem Review doch noch Auffälligkeiten zur Sprache kommen, nutze ich mein Review-Protokoll-Template, um diese Punkte zu gewichten, zu dokumentieren und anschließend abzustellen.
  5. Das Lastenheft freigeben
    Der entscheidende Schritt bei der Erstellung eines Lastenhefts ist die Freigabe. Häufig wird dies aber nicht getan. Entweder aus Zeitdruck oder weil sich niemand traut, die Verantwortung zu übernehmen. Gerade den zweiten Grund halte ich für kritikwürdig. Wenn ich ein Lastenheft erstelle, übernehme ich auch die Verantwortung für meine Arbeit. Ansonsten kann ich es gleich bleiben lassen.

Tipps und Tricks

  1.  Zeit einplanen und dranbleiben
    Einer der häufigsten Gründe, warum Lastenhefte keine hohe Qualität besitzen, ist es, dass nicht ausreichend Zeit zur Erstellung eingeplant wurde. Das führt dazu, dass unter Zeitdruck das Dokument zusammengehauen wird. Zwangsweise schleichen sich damit auch viele Fehler in das Dokument ein. Ein weiterer Grund ist, das Lastenheft irgendwie zwischen Tür und Angel zu erstellen. Dadurch wird immer wieder der Fokus verloren und es ist sehr schwer, kontinuierlich dran zu bleiben. Es gibt auch manchmal den gegenteiligen Effekt – nichts anderes mehr zu machen als Lastenhefterstellung. Dann sinkt die Konzentration und der Überblick geht verloren. Ich plane mir ausreichend Zeit ein, um ein Lastenheft zu erstellen – in der Regel mehrere Monate. Das beginnt bei der Anforderungserhebung, über die Erstellung bis hin zum Review. Außerdem plane ich regelmäßige Zeitfenster ein, an denen ich an dem Dokument arbeite. Zum Beispiel dreimal in der Woche zu festen Zeiten.
  2. Weniger ist mehr
    Ganz wichtig ist es, dass ich in Lastenheften keine Lösung beschreibe, sondern das Problem, das gelöst werden soll, der Empfänger des Lastenheftes hat jetzt die Aufgabe, es in eine Lösung umzusetzen. Wichtig ist dabei, dass er den Kernnutzen des Systems oder Produkts kennt. So kann er viel besser entscheiden, welche Lösung für die Anforderungen optimal ist. Was ich ganz klar beschreibe, sind die Schnittstellen des Systems. Denn hier entstehen die meisten Fehler bei der späteren Umsetzung. So ist mir eine ausführliche Schnittstellenbeschreibung sehr wichtig, und diese stellt die halbe Miete bei der Lastenhefterstellung dar.
  3. Keinen Pseudo-Code einsetzen
    Oft sehe ich eine, aus meiner Sicht, wirklich problematische Umsetzung in Lastenheften. Es werden Verhalten und Funktionen in „Pseudo-Code“ dargestellt. Warum ist das so problematisch? Durch Pseudo-Code wird ein Lastenheft interpretierbar, da die Anforderungsgrammatik nicht mehr genutzt wird. Wir schreiben Lastenhefte, damit andere Menschen das lesen und verstehen können. Für nicht software-affine Menschen wird das Lastenheft durch Pseudo-Code unverständlich. Wenn ich mir schon den Aufwand mache, dann kann ich auch einheitliche Darstellungsformen wie SysML nutzen. Ich empfehle hier pragmatische Darstellungen. Ein Bild sagt mehr als tausend Worte, und so nutze ich, wenn möglich, graphische Darstellungen, um Anforderungen verständlich darzustellen.
  4. Keine auf Personen bezogene Referenzen
    Eine der größten Sünden in einem Lastenheft ist es, Verweise auf eine Person in ein Lastenheft aufzunehmen. Diese Person hat möglicherweise zu dem Zeitpunkt, an dem jemand das Lastenheft liest, den Job gerade gewechselt. Die Krönung ist es, in einem Anforderungsmanagement-Werkzeug den Namen der Person auch noch als „Anforderung“ zu definieren. Ich habe das tatsächlich schon häufiger gesehen und möchte noch einmal eindringlich davor warnen.

Zusammenfassung

Erfolgreich ein Lastenheft zu erstellen ist eine Kunst für sich. Aber der Aufwand den Du investierst rechnet sich am Schluss um ein Vielfaches. Ich habe nur zu oft als Troubleshooter kritische Projekte übernommen, die ihre Budgets vervielfacht haben, nur weil sie keine Zeit in die Erstellung eines Lastenheftes investiert haben.

Fragen und Antworten

Ein Lastenheft dient der Beschreibung der erwarteten Leistung von einem beauftragten Unternehmen. Es ist damit die Spezifikation eines Produktes oder eines Services und gilt bei Vertragsabschluss auch als Vertragsbestandteil. Anhand eines Lastenhefts kann die Abnahme durchgeführt und protokolliert werden.

Als Anforderungsspezifikation enthält das Lastenheft alle Angaben, die das Produkt beschreiben. Dabei fokussieren sich die Beschreibungen auf die äußere Sicht hinsichtlich des Produktes. Das Lastenheft beinhaltet demnach die Problembeschreibungen und wie sich der Kunde die Lösung dieses Problems vorstellt.

Als Auftraggeber liegt die Erstellung und die Freigabe des Lastenhefts in seiner Hand. Es ist seine Beschreibung des Produktes und des Einsatzzweckes. Kein anderer wird diese Beschreibung besser bewerten können.

Das Lastenheft wird im ureigensten Sinne vom Auftraggeber verfasst, denn es obliegt ihm die Problembveschreibung in Worte zu fassen. Er kann sich für die Erstellung allerdings Hilfe holen, um ein professionelles Lastenheft zu erhalten (z.B. auf lastenhefterstellen.de).

Ein Lastenheft kann mit Word erstellt werden. Das ist die einfachste und zunächst schnellste Lösung. Spezielle Anforderungsmanagement-Werkzeuge könbnen dafür ebenfalls genutzt werden, wobei hier zwischen Kosten plus Aufwand und Nutzen unterschieden werden muss.

Ein Lastenheft sollte so detailliert sein, dass der Auftraggeber, wie auch der Auftragnehmer mit den Inhalten zufrieden sind. Der Auftraggeber muss alle seine Wünshce darin dokumentiert haben und für den Auftragnehmer sollten keine schwerwiegenden Fragen mehr offen sein.

Gibt es bei lastenhefterstellen.de :-))

Im Lastenheft sind die Wünsche des Auftraggebers dokumentiert. Der Auftraggeber die äußere Struktur und das Verhalten, aus seiner Sicht und so wie er sich das Produkt vorstellt. Im Pflichtenheft wird beschrieben, wie der Auftragnehmer das Produkt realisieren kann – unter BEachtung aller gesetzlichen Vorgaben und innerbetrieblichen Normen udn Vorgaben. Das Pflichtenheft stellt dabei eine textuell wie auch grafisch das Produkt als White-Box dar.

Für Erstellung eines Lastenheftes gibt es Dienstleister, die einen Service dafür anbieten. Am bekanntesten ist der Service auf der Seite lastenhefterstellen.de

[thrive_leads id=’7749′]