Als Systemingenieur in der Automobilentwicklung bewerte ich seit Jahren technische Lastenhefte. Dadurch habe ich so ziemlich alles gesehen: von chaotischen Lastenheften, bis hin zu Lastenheften, die absolut super waren. Ich habe Lastenhefte bewertet, als Projekte noch in der Initialisierungsphase waren. Ebenso habe ich Lastenhefte bewertet, als ich sechs Monate vor SOP (Start der Produktion) ein Projekt als Troubleshooter übernommen habe. So habe ich über die Jahre meine eigene pragmatische Vorgehensweise geschaffen, wie ich mit Lastenheften umgehe und sie bewerte.

Meine Vorgehensweise habe ich in diesem Artikel zusammengefasst. Ich gebe Ihnen eine Schritt-für-Schritt Anleitung, wie ich ein Lastenheft analysiere. Ich zeige, wie ich mit dem Vorgehen effektiv zu einem Ergebnis komme. Sie können sofort loslegen und diese Vorgehensweise für sich nutzen und anpassen.

Warum sind Lastenhefte sinnvoll?

Lastenhefte beschreiben das „Wünsch-dir-was“ eines Kunden. Sie sind ein wichtiges Puzzlestück in der Entwicklung, um einem Lieferanten die erwarteten Anforderungen zu beschreiben. Entsprechend der DIN 69901-5 sind Lastenhefte die „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 ZA007 „Lastenhefte vs. Pflichtenhefte“ bin ich im Detail auf den Unterschied eingegangen.

Die Situation in der Praxis?

Im technischen Umfeld haben wir häufig die Situation, dass Ingenieure Lastenhefte bewerten müssen. Die Lastenhefte kommen vielleicht als fertiges Modul für ein Requierement Werkzeug (z.B. Doors), häufig aber auch als PDF’s. Oft habe ich auch Lastenhefte als Skizzen in einer Präsentation auf dem Tisch gehabt.

Meine Erfahrung ist, dass Lastenhefte häufig von nicht entsprechend ausgebildeten Ingenieuren geschrieben werden. Entweder sind es Produktmanager, die oft nicht den technischen detaillierten Hintergrund haben, oder es sind Entwicklungsingenieure, die diese Aufgabe nebenbei mit erledigen.

Bei manchen Lastenheften ist erkennbar, dass sie aus einem Baukasten zusammengestellt sind und sich dann in Teilen widersprechen. Oder sie beinhalten Dinge, die nicht in ein technisches Lastenheft gehören. Dementsprechend sind diese Lastenhefte oft die natursprachliche Beschreibung eines Autors, die sich nur an wenige oder keine Dokumentationsregeln hält. Außerdem sind Begriffe wie „Lastenheft“, „Pflichtenheft“ und „Spezifikation“ nicht klar gegeneinander abgegrenzt, so dass sie in einem Dokument oftmals vermischt werden.

Bewertung eines Lastenheftes

Ich beschreibe hier meine Vorgehensweise, wie ich Lastenhefte für ein technisches System bewerte. Wie schon gesagt: Das ist mein „Kochrezept“. Probieren Sie es aus und passen sie es pragmatisch Ihren Bedürfnissen an.

1. Klärung der Vollständigkeit
Zunächst geht es darum zu klären, ob alle relevanten Informationen vorliegen. Das bedeutet, ich lese mir die Lastenhefte grob durch und versuche zu verstehen, was beschrieben wird. Wenn ich nur Skizzen in Form von Präsentationen bekomme, setze ich mich mit dem Verfasser zusammen und lasse mir erläutern, was er beschrieben hat.

2. Referenzanalyse
Nun analysiere ich die Lastenhefte auf Verweise nach anderen Spezifikationen. Das können z.B. interne oder externe Normen sein. Es können auch Verweise auf Lastenhefte sein, die das gesamte System (System of a System) beschreiben. Dann besorge ich mir alle Dokumente und bewerte, inwieweit diese für das zu entwickelnde System relevant sein können. Oft sind es oft nur Kapitel aus einer Norm oder anderen allgemeinen Vorgaben. Beispielsweise: Es soll ein LIN-System entwickelt werden. Dann kann ich alles über andere Busschnittstellen, wie z.B. CAN, überspringen.

Mit diesem Wissen erstelle ich eine Liste der Referenzen und bewerte sie nach ihrer Relevanz. Dazu nutze ich die Einstufungen:
– A = highly relevant, shall be reviewed
– B = partly relevant, should be reviewed
– C = Standard relevance, may be reviewed
– Z = Relevant for Project, but covered by specialists

Wenn mein System aus verschiedenen Subsystemen besteht, ordne ich die Referenzen noch diesen Subsystemen zu. Somit kann der jeweilige Verantwortliche nachvollziehen, welche Referenzen für ihn relevant sind.Als Ergebnis erhalte ich eine Übersicht über die Referenzen im Lastenheft und kann entscheiden, wie ich damit umgehen will.

3. Übertragung in ein editierbares Format
Jetzt übertrage ich die relevanten Lastenhefte bzw. Abschnitte oder Texte ich ein editierbares Format. Ziel ist ein Dokument, in dem jeder Satz einzeln in einer Tabelle aufgeführt ist. Wenn Sie mit gelieferten Doorsmodulen o.ä. arbeiten, können sie diesen Schritt überspringen. Wenn Sie kein Requirement Management Werkzeug haben, mit Excel geht es im Zweifel auch. Wichtig ist, dass ich die einzelnen Sätze eines Lastenheftes in eine Tabelle übertragen habe, um sie dort weiter bewerten zu können. Ich mache das mit einem eigenen Skript. Sie können aber auch einen PDF-Editor nutzen. Wichtig ist nur, dass Sie die Sätze vereinzeln können. Das kann bedeuten, dass ich den Umweg über einen einfachen Texteditor nehme und dann eine CVS-Datei erzeuge, die ich wieder in Excel importiere. Egal ob Doors oder Excel, oft muss ich anschließend noch das Ergebnis „beautifyen“; das geht aber recht schnell.

4. Vergabe von eindeutigen ID‘s
Wenn ich jeden Satz vereinzelt habe, vergebe ich eine eindeutige ID. Das bedeutet, ich füge vor dem Satz eine Spalte ein und nummeriere diese durch. Dazu nutze ich folgende ID-Konvention: [Systemname]_[Kunde]_[fortlaufende Nummer]. Damit bin ich immer ganz gut gefahren und konnte dann in Webmeetings oder Abstimmungsgesprächen direkt auf die ID‘s Bezug nehmen.

5. Zuweisen des Anforderungstyps
Jetzt geht es darum, zu bewerten, welche Relevanz die Anforderungen für das System haben. Unabhängig, ob sie später akzeptiert werden, nutze ich die Einstufungen:
– Heading -> Identifikation der Überschriften
– Requirement (Req)-> Identifikation einer echten Anforderung
– Requirement Information (ReqInfo) -> Information zu einer Anforderung
– Document Information (DocInfo) -> Information zum vorliegenden Dokument

6. Zuweisen der betroffenen Domäne
Als nächsten Schritt gehe ich alle Anforderungen durch und weise sie einer Domäne zu. Dadurch kann ich anschließend bei der Bewertung auf die Spezialisten zugehen und mit Ihnen die Anforderungen klären. Ich nutze dazu die Einstufungen:
– Project -> Anforderungen, die das Projekt und nicht das System betreffen
– System -> Anforderungen, die das System als Ganzes betreffen
– Mechanic -> Anforderungen, die die Mechanik betreffen
– Hardware -> Anforderungen, die die Hardware betreffen
– Software -> Anforderungen, die die Software betreffen
– Testing -> Anforderungen, die den Testbereich betreffen

Manche Anforderungen können auch mehrere Zuweisen gleichzeitig beinhalten. Beispielsweise Software und Hardware, wenn es um eine Datenschnittstelle geht.

7. Zuweisen des Status einer Anforderung
Nun weise ich jedem Satz kontinuierlich einen Status zu. Ich nutze dazu die Einstufungen:
– n/a (not applicable) -> für Überschriften
– open -> noch nicht bearbeitet
– in work -> ist in Bearbeitung
– in clarification -> wird gerade geklärt
– in review -> wird gerade gereviewed
– closed -> ist abgeschlossen

Das bedeutet, jede Anforderung beginnt mit open und endet mit closed. Außer natürlich die Überschriften, die bleiben n/a. So kann ich über die Analysephase jederzeit den Status der Ergebnisse nachvollziehen.

8. Klärung der Anforderung
Jetzt kommt der knifflige Teil des Jobs. Ich muss die Anforderungen klären. Einen größeren Teil kann ich oft schnell abhaken, aber etwa 20% der Anforderungen bedürfen häufig eine intensivere Nachfrage, was genau gemeint ist. Die alte 80/20 Regel kommt hier deutlich zum Tragen. Alle Fragen und Antworten dokumentiere ich in einem eigenen Bemerkungsfeld hinter dem Anforderungssatz.

9. Abschließende Bewertung der Anforderung
Wenn ich alle Fragen geklärt habe, nehme ich die Bewertung der Anforderung vor. Hierzu nutze ich „akzeptiert“, „teilweise akzeptiert“ oder „nicht akzeptiert“.Hier kann ich aus dem „Wünsch-dir-was“ der Kundenanforderungen entscheiden und manche abweisen oder eine Alternative vorschlagen. Auch das dokumentiere ich dann im Bemerkungsfeld.

10. Hilfreiche Tipps & Tricks

  • Einsatz von Templates
    Ich nutze meine Templates für die Bewertung. Damit habe ich immer ein Schema, um nichts zu vergessen. Ich habe Ihnen mein Template bereitgestellt. Passen Sie es Ihren Bedürfnissen an.
  • Schnittstelle zum Aufwandsschätzen
    Die Bewertung ist die Grundlage für die Aufwandsschätzung. Bedenken Sie dies, wenn Sie eine Releaseplanung erstellen. Mehr dazu finden Sie in dem Tutorial Effektive Aufwandsschätzung für komplexe Projekte. Dort habe ich beschrieben, wie ich eine Releaseplanung und eine Aufwandsschätzung durchführe.
  • Schnelllesen lernen
    Lernen Sie, schnell zu lesen. Ich halte das für eine Kernkompetenz eines Systemingenieurs. Ich kann Ihnen dazu ein Buch empfehlen: „Schneller lesen – besser verstehen“ von Wolfgang Schmitz. Dadurch habe ich meine Lesegeschwindigkeit deutlich gesteigert.
  • Unterschätzen Sie nicht den Aufwand
    Eine zu oberflächliche Analyse und Abstimmung wird hinten heraus extrem teuer. Eine zu aufwändige Analyse bringt keinen Mehrwert. Meiner Erfahrung nach sind ca 10-15% des Entwicklungsaufwands eines Projekts eine gute Größe. Bei komplexen und sicherheitskritischen Systemen oder bei schlecht geschriebenen Lastenheften kann es auch mal mehr werden.

Was ist das Ergebnis?

Nun habe ich eine bewertete Liste der Anforderungen. Diese kann ich zusammen mit dem kaufmännischen Teil dem Kunden im Rahmen eines Angebotes zuschicken. Wenn ich in einem Troubleshooting-Projekt bin, nutze ich das Ergebnis, um die Situation neu auszuverhandeln. Das ist nicht angenehm, muss aber sein. Bedenken Sie, die Welt dreht sich weiter, und vorherige Analyse war nur eine Situationsaufnahme mit den damals bekannten Vorgaben.

Zusammenfassung

Lastenheftbewertung ist ein kleine Kunst für sich. Aber egal, wie lange sie für die Analyse brauchen, die Zeit, die Sie investieren, lohnt es sich am Ende um ein Vielfaches. Ich habe nur zu oft als Troubleshooter kritische Projekte übernommen, die ihr Entwicklungsbudget vervielfacht haben, nur weil sie vorher keine Zeit investiert hatten.

Weitere Empfehlungen

In dem Podcast bespreche ich immer wieder das Thema Spezifikation und die Herausforderungen damit.

In diesen Episoden bin ich besonders auf Anforderungen und Spezifikationen eingegangen:

In einem weiteren Tutorial beschreibe ich mein “Kochrezept”, wie ich ein Lastenheft erstelle: 5 Schritte zur Erstellung eines guten Lastenheftes