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.

1. Anforderungen en masse

Den ersten Grund dafür, dass Spezifikationen nicht gelesen werden, erlebe ich immer wieder: Es sind zu viele. Eines der größten Projekte, das ich begleitet habe, war ein komplexer Board-Controller. Das Lastenheft des Herstellers hatte über 40.000 Anforderungen.

Das Tragische daran: Damals war das viel, heute scheint es zum Durchschnitt zu werden. Immer mehr Lastenhefte haben 40.000 valide Anforderungen – nicht Überschriften oder ergänzende Satzteilen, sondern echte, definierte Spezifikationen.

Ich stelle das nicht grundsätzlich infrage. Gerade bei komplexen Systemen kann diese Summe schnell explodieren. In solchen Fällen brauchen wir dann aber noch eine ergänzende, beschreibende Ebene. Ansonsten liest niemand diese Masse – gerade die Spezialisten nicht.

So bleibt aber niemand übrig, der sich für das ganze Lastenheft verantwortlich fühlt – und es vollständig liest. Das ist theoretisch natürlich die Aufgabe des System-Ingenieurs, aber dieser ist in der Praxis häufig noch nicht da.

2. Trennung der Ebenen und Hefte

Ein weiterer Grund ist die Vermischung von Lasten- und Pflichten-Ebenen. In einem Projekt im Bereich der Solar-Elektronik gab es beispielsweise ein Lastenheft aus dem Produktmanagement – welches gleichzeitig das Pflichtenheft war.

Dabei ist ein Lastenheft das Wünsch-Dir-Was des Kunden, ein Pflichtenheft aber ist die Antwort des System-Requirements auf dieses Wünsch-dir-was. In dem erwähnten Projekt bestand das Lastenheft aus nur drei, vier Seiten, in denen die Pflichten einfach in einer anderen Farbe ergänzt worden waren. Im Grunde waren also die Antworten in dem Lastenheft schon drin. Und so etwas liest leider niemand.

Nehmen wir folgendes Beispiel: Auf der einen Seite steht in so einem Hefte-Mix, das System soll in einem Spannungsbereich von 500 bis 10.000 Volt funktionieren. Darunter steht in einer anderen Farbe der Satz: „Wir haben in der Regel nur 5.000 Volt, die wir bedienen müssen.“

Was soll der Entwickler nun als relevante Informationen herausziehen? Durch diese Vermischung der Ebenen werden solche Spezifikationen eben ganz schnell beiseitegelegt. Schließlich wirkt das Ganze so unstimmig und unstrukturiert, dass man darin mehr Probleme als Hilfen sieht.

3. Trennung von Problem und Lösung

Dieses Problem tritt meiner Erfahrung nach sehr häufig auf. Bei Spezifikationen ist es jedoch grundlegen, auf der Systemebene die problembeschreibende, also funktionale Sicht von der nicht-funktionalen, welche keinen Lösungskontext vorgibt, zu trennen. Auf der einen Seite beschreibt man also nur das zu lösende Problem, während man auf der anderen eine lösungsbeschreibende Spezifikation definiert.

Gerade heute ist es sehr verlockend, alles mit neuen Methoden und (Entwicklungs-)Tools wie beispielsweise SysML oder Enterprise Architect zu erschlagen. Und mit SysML kann man in der Tat sinn- und wertvolle Requirement-Statements definieren. Entscheidend ist aber, Problem und Lösung konstant auseinander zu halten.

Oft wird jedoch sofort SysML eingesetzt, um Architekturbeschreibungen vorzunehmen und gleichzeitig Requirements Engineering auf der Systemebene durchzuführen. Diese Vermischung führt dazu, dass die Visualisierung, die im SysML enorm praktikabel ist, für keinen mehr nachvollziehbar wird. Moderatoren kann dann das Reindenken und Verstehen zwei Wochen kosten.

4. Trennung technische und Projekt-Anforderungen

Technische Spezifikationen zu lesen und darin permanent Projektanforderungen vorzufinden, macht weder Sinn noch Spaß.

Beispielsweise rechtliche, Prozess- oder Fertigungsprozessbelange haben zwischen technischen Anforderungen nichts zu suchen. Natürlich sind sie wichtig: Für den Entwicklungsprozess, die Qualitäter, den Produktions-Ingenieur etc. – nicht aber für die Beschreibung und Umsetzung des technischen Systems.

Diese vier Gründe führen regelmäßig dazu, dass Spezifikationen nicht gelesen werden. Wie man diese Probleme umgehen oder lösen kann, werde ich in den nächsten Beiträgen erläutern.