Lastenhefte schreiben

Vor einiger Zeit hat mich ein Kunde angesprochen und mich Folgendes gefragt: „Herr Schorre, ich brauche ein Lastenheft – in den nächsten zwei Wochen. Geht das?“

Sieben Tipps zur Erstellung von Lastenheften

Wenn es um die Erstellung von Lastenheften geht, kann man gewisse Fehler vermeiden – wenn man sich von Beginn an bewusst macht, welche diese sind und wie und warum sie entstehen.

In dieser und der folgenden Ausgabe des Blogs möchte ich Euch sieben entscheidende Tipps geben, die die Erstellung von Lastenheften vereinfachen und Fehlerquellen minimieren.

Spezifikationen: Problembewusstsein schaffen – und Lösungen finden

In diesem Beitrag möchte ich auf die Frage eingehen, wie Projekte mit dem Problem der vielen, aber kaum gelesenen Spezifikationen umgehen – und wie sie damit umgehen sollten.

Welche Spezifikationen? Oder: Duck an cover

Den ersten und häufigsten Weg nenne ich gerne „duck and cover“ nach dem amerikanischen Spruch aus dem kalten Krieg. Diese Variante liegt in zwei Ausprägungen vor.

Aus Last mach Pflicht – Variante I

Die eine Ausprägung: Man nehme sich das Lastenheft, kopiere stumpf einfach alles – und schreibe darüber „Pflichtenheft“. Das habe ich als Troubleshooter in einem Projekt gehabt und schließlich gefragt: „Wie ist eigentlich diese Systems-Requirements-Specification entstanden?“ „Die ist aus dem Lastenheft kopiert. Wir haben keine Zeit und es sind viel zu viele Anforderungen.“

Das waren in der Tat 40.000 Anforderungen. Ich bin das durchgegangen, habe das analysiert und schnell zeigte sich, dass sie damit auch alle nicht-technischen Projektanforderungen kopiert haben – inklusive einiger unsinniger Anforderungen … Damit haben sie gleichzeitig akzeptiert, was dort drinsteht – und einfach weggeschaut.

In einem anderen Fall hatte ein klassisches, mittelständisches Maschinenbau-Unternehmen ihr System entwickelt, nämlich das, was auf der technischen Zeichnung stand, das waren ja die Anforderungen.

Die Probleme mit einem Teilsystem, das im Feld Schwierigkeiten machte, waren dann groß, denn Elektronik und Software, die mit verbaut waren, hat keiner richtig betrachtet. Und es gab auch kein Lastenheft, denn niemanden interessierte das – bis ich hinzukam. Für sie war es eher überflüssiger Ballast. Sie haben sich geduckt und gehofft, dass der Sturm an ihnen vorbeizieht.

Das große Nichtstun – Variante II

Die zweite Variante sehe ich häufiger bei kleinen und mittelständischen Unternehmen: Einfach gar nichts machen.

Diesen Fall habe ich mit absolut extensiven Spezifikationen bei einem Elektromobilitäts-Projekt erlebt. In der Vorprojektphase brachte der Hersteller ein 600-Seiten starkes Dokument und sagte, dies seien die Spezifikationen.

Parallel waren damit auch viele Widersprüchlichkeit verbunden, denn in der Automobilindustrie wird heutzutage regelrecht in einem Lego-Schema gearbeitet, vieles ist also „reused“. Das ist generell ein großes Thema, weil oft einfach mehrere Bauteile zusammengesteckt werden und ein Lastenheft ergeben sollen und zwar ein extrem ausführliches – das niemand lesen will.

Da wir zudem in einem Innovations-Projekt saßen, hatte gerade mal ein gefühltes Drittel überhaupt Relevanz für uns. Die anderen zwei Drittel dieses Lastenheftes waren zwar da und wir mussten die durchgehen, aber im Grunde konnten wir das hinterher alles komplett wegkehren.

Wirklich hinschauen – die Visualisierung der Spezifikationen

Der dritte Weg, der sich nun mehr und mehr durchsetzt, ist, die Anforderungen erstmal zu visualisieren und sich ein Gesamtbild zu machen.

Ich habe als Mentor in vielen Projekten genau das gemacht: Wir haben den System Footprint aufgehängt, die unterschiedlichsten Spezialisten und auch Bereiche wie Marketing, Vertrieb, Produktmanagement etc. eingeladen und sind gemeinsam durch diesen Footprint gegangen.

Durch diese Visualisierung wird allen erstmal bewusst, was die Anforderungen an dieses gesamte System sind. Wenn ich dann eine Spezifikation lese, habe ich dieses Bild auch im Kopf. Das ist einer der großen Gewinne daran – und dass es für alle funktioniert.

In einem Projekt beispielsweise was es für das Marketing sehr wichtig. Diese Abteilung gab sehr viele Anforderungen mit hinein, doch mit dem Footprint hat das alles wunderbar funktioniert. Er wird dort mittlerweile in den ganzen Business Units eingesetzt und die Unternehmensführung weiß, dass es für sie ein extrem wertvolles Mittel ist.

Es ersetzt keine Spezifikationen, das ist ganz wichtig, es visualisiert diese nur. Aber dann lässt sich mit ihnen auch arbeiten.

Die erste deutsche Online-Bibliothek zum Thema Lastenhefte

Der Blog „Agile Lastenhefte“ eröffnet seine Online-Bibliothek mit Templates, Lernvideos, Tutorials und vielem mehr Templates und Checklisten sind und bleiben heißbegehrte Werkzeuge. Ob für einen Startpunkt, für den Abschluss – oder für Probleme mittendrin: Sie schaffen den nötigen Überblick, bilden Strukturen ab und ermöglichen sinnvolle Deadlines für Lastenhefte.

Spezifikationen: Essentiell – und ungelesen

Warum werden Spezifikationen oft nicht gelesen? Alle wissen, dass sie essentiell sind, dennoch befinden wir uns häufig in Situationen, in denen plötzlich niemand weiß, worum es geht. Weiterlesen

Requirement Engineering für komplexe Systeme – Teil II

Im letzten Beitrag habe ich bereits zwei Probleme des Requirement Engineering in komplexen Systemen angesprochen: Fehlende Lastenhefte und die fehlende Trennung zwischen System- und Projekt-Anforderungen. Hier möchte ich zwei weitere, nicht weniger relevante Probleme diskutieren. Weiterlesen

Requirement Engineering für komplexe Systeme – Teil I

In diesem Beitrag möchte ich auf die Frage eingehen, warum Requirement Engineering für komplexe Systeme so wichtig ist. Hierfür erläutere ich zunächst die ersten großen Schwierigkeiten in solchen Situationen: Das fehlende Lastenheft und die fehlende Trennung zwischen System- und Projekt-Anforderungen. Weiterlesen

Prozess-Reviews

In diesem Beitrag möchte ich Prozess-Reviews beschreiben. Dieser Review-Typ bzw. das Audit ist für das gesamte Entwicklungsprojekt entscheidend.

Das Prozess- oder Reifegrad-Review weist die Entwicklungsreife eines Projekts nach. Dabei geht es nicht mehr um den Inhalt der Ergebnisse, sondern um den Nachweis der zu erbringenden Arbeitsergebnisse, also zum Beispiel Spezifikationen, Planungsdokumente, Testdurchführungen etc. Als Basis dienen hier meist Prozessreifegradmodelle wie z.B. SPICE oder CMI. Weiterlesen

Freigabe-Reviews für Lastenhefte – Ergebnisse im Team freigeben

Für ein gelungenes Lastenheft sind Reviews meiner Erfahrung nach unerlässlich. Ich habe bereits über die allgemeinen Vorteile von Reviews und die spezielle Form der Peer Reviews berichtet. Kommen wir nun zu den Freigabe-Reviews.

Im Gegensatz zu Peer Reviews ist dieser Typ Geheimwaffe deutlich formaler. Ein Freigabe-Review wird oft in einer Gruppe von Entwicklungsingenieuren durchgeführt. Das bedeutet, sie müssen geplant, vor- und nachbereitet werden. Welche Schritte genau das beinhaltet, möchte ich im Folgenden erläutern. Weiterlesen