Software Entwicklung macht Spaß! Welches Software Entwicklerteam freut sich nicht, eine herausfordernde Kundenanfrage schnell in eine spannende Lösung umzusetzen und einen ersten Prototypen zu präsentieren. Dagegen ist jede Motivation eines Entwicklerteams ganz schnell dahin, wenn man sagt, dass ein Projekt im Wasserfallmodell in den nächsten 2 Jahren umgesetzt wird und dass in der ersten Phase erstmal alle Requirements erfasst werden. Im folgendem Beitrag wird mit dem umgedrehten V-Modell mal ein Perspektivwechsel angeregt, mit dem Ziel den praktischen Nutzen des Requirement Engineering in den Projekten deutlich zu erhöhen.

In Projekten der Funktionalen Sicherheit besteht ein hoher Druck, einen komplexeren Entwicklungsprozess anzuwenden. Trotz der (angeblichen!) normativen Forderungen kann man aber auch in vielen dieser Projekte beobachten, dass schnelle Prototypen dem Erstellen von Requirements, Architektur und Traceability vorgezogen wird.

Da es sich hier um ein sehr weitverbreitetes Phänomen handelt, möchte ich in diesem Beitrag das Ganze hinterfragen. Gibt es vielleicht sogar gute Gründe so vorzugehen, wie es in der Praxis zu sehen ist. Man kann ja auch die Frage stellen: Können Tausende von Entwicklern und Projektleitern wirklich so irren, wie es viele Berater und manche theoretischen Abhandlungen gerne glauben machen wollen?

Fehlerquellen in Software Projekten

Schauen wir uns zunächst mal Statistiken zu Fehlerursachen in Software Projekten an. Hier sehen wir, dass die meisten Fehler, welche in einem Projekt gemacht werden, ihre Ursache in den Requirements haben. Das gezeigte Kuchendiagramm ist dabei nur eines von vielen. Alle Untersuchungen, die ich zu diesem Thema je gesehen habe, zeigen sehr ähnliche Ergebnisse. Requirements spielen also eine wichtige Rolle wenn es darum geht die Fehler und damit die Qualität der Produkte zu verbessern.

Die Design Phase setzt das „Was“ der in Requirements definierten Funktionen in das „Wie“ um, d.h. das Software Design stellt die Lösung dar. Die Modellbasierte Entwicklung hat hier in den letzten Jahren große Fortschritte gebracht. Inzwischen können toolgestützt, in sich konsistente und korrekte Modelle entworfen werden. Vielfach sind die Modelle so gut, dass es möglich ist, daraus automatisch Source Code zu generieren. Modelle als auch Source Code basieren auf mathematischen Regeln. Damit kann die Korrektheit und Konsistenz mathematisch überprüft werden. Dies führt zu einer deutlichen Reduktion der Fehler.

Bei den Requirements ist dies bisher leider nicht möglich. Die Requirements sind die Schnittstelle zwischen Auftraggeber (Kunde/Nutzer/etc.) und dem Auftragnehmer (Dienstleister/Entwicklerteam/etc.). Hier handelt sich um eine Schnittstelle nur zwischen Menschen. Wiederum ist das einzig umfassend vorhandene Kommunikationsmittel zwischen Menschen die natürliche Sprache. Die natürliche Sprache erfüllt keine der eigentlich für Requirements gewünschten Eigenschaften:

• Konsistenz
• Korrektheit
• Eindeutigkeit
• Vollständigkeit

Das Requirements Engineering versucht diese Schwächen zu minimieren. Wie die Fehlerstatistik zeigt, gelingt das offensichtlich nur sehr eingeschränkt.

Prototypen – Der Kunde weiß nicht was er will!

Die gezeigte Fehlerstatistik ist heutzutage jedem Softwareprojektleiter bekannt und trotzdem fällt die Spezifikationsphase häufig aus oder wird nur oberflächlich durchgeführt. Wir können sogar noch einen Schritt weitergehen: Mit der agilen Software Entwicklung hat sich in den letzten Jahren ein Vorgehen durchgesetzt, welches einen dokumenten-lastigen Ansatz ablehnt. Statt umfangreichen Spezifikationsdokumenten werden in agilen Projekten die schnellen und kurzen Feedbackschleifen mit dem Kunden und Nutzer des Produktes deutlich höher gewichtet.

Diese kurzen Feedbackschleifen in einer agilen Entwicklung stellen bezüglich der Spezifikation von Systemen eine praktische Antwort auf die angedeuteten Schwächen der Requirements Engineering Methode dar. Ein zweiter, für die Praxis ganz wichtiger Punkt, kommt aber noch hinzu. In industrierelevanten Projekten kennt weder der Nutzer noch das Entwicklerteam des Produktes zu Beginn alle benötigten Funktionalitäten vollständig. Je länger und je größer das Projekt ist, desto größer ist die Lücke.

Auch diesen zweiten Punkt kann man als Schwäche der Requirements Engineering Methode interpretieren. Viele Bücher beschäftigen sich ausgiebig mit dem (systematischen) Ermitteln der Requirements. Wenn man die gelebte Praxis als Maßstab nimmt, dann scheinen die in der Theorie definierten verschiedenen Kreativ-Techniken zur Ermittlung von Requirements nicht sehr attraktiv und erfolgreich zu sein.

Wie zu Beginn des Beitrages erwähnt, entwickeln natürlicherweise Softwareteams gerne Source Code. Wenn man das in einem wirklich gelebten agilen Entwicklungsprozess tut, kann man sehr systematisch einen Prototypen des Systems entwickeln.

Entscheidend ist, dass man die agilen Methoden wirklich anwendet. Use Cases und User Stories, aber auch Lastenhefte, sind für die Prototypen die ideale, leichtgewichtige Dokumentation.

Ich bezeichne auch Lastenhefte absichtlich als leichtgewichtige Dokumentation, denn das Lastenheft erstellt der Kunde/Nutzer – nicht das Entwicklerteam. Wenn kein Lastenheft da ist, dann erstellen die Entwicklerteams eben kurze aussagekräftige Use Cases und User Stories.

Ein typisches Beispiel für ein Lastenheft sieht wie folgt aus:

• Die Heizungssteuerung soll das Ausgangssignal abc steuern.

Das umgedrehte V-Modell

Wenn man gar keine dokumentierten Produkteigenschaften hat, dreht man tatsächlich das V-Modell vollständig um. Man beginnt eine Software Entwicklung nur mit dem, was man mündlich und damit oberflächlich als Produkteigenschaften meint verstanden zu haben.

Die vielen Jahrzehnte der Software Entwicklung haben bewiesen, dass dieser Ansatz fast zwangsläufig zum Scheitern verurteilt ist. Das entstehende Produkt ist am Ende zu weit von den Kundenbedürfnissen entfernt. Umfangreiche Nacharbeiten, welche im Nachhinein einer Neuentwicklung gleich kommen, sind notwendig. Das noch größere Problem dieses Ansatzes ist, dass keinerlei Planbarkeit gegeben ist. Das führt zu großem Frust bei allen Projektbeteiligten.

Damit könnten wir schlussfolgern dass die agile Entwicklung mit leichtgewichtiger Dokumentation und schnellen und kurzen Feedback Schleifen die Lösung ist.

Je kleiner, kürzer in der Laufzeit und weniger sicherheitsrelevant die Projekte sind, desto eher ist dies auch richtig.

Prototypenbau in Projekten der Funktionalen Sicherheit?

Prototypen flankiert mit einer leichtgewichtigen Spezifikationsform wie UseCases, User Stories etc. sollten immer dann am Anfang eines größeren, komplexeren Projektes stehen, wenn noch recht große Unsicherheit über die zu erfüllende Funktionalität des zu entwickelnden Produktes besteht. Das gilt auch für Projekte der Funktionalen Sicherheit. Keine Funktionale Sicherheitsnorm fordert eine durchgängige, konsistente Spezifikation und Traceability in frühen Projektphasen. Hier ist viel wichtiger, dass z.B. ein Assessor nachvollziehen kann, dass Sie einen Plan haben und wissen was Sie warum tun.

Sie dürfen auch ein Sicherheitskonzept am Anfang eines Projektes nicht mit einer testbaren funktionalen Spezifikation gleichsetzen. Ein Konzept kümmert sich ums große Ganze. Ein Sicherheitskonzept unterscheidet deswegen auch ganz bewusst nicht zwischen Funktionalität und Architektur.

Vor allem in sehr innovativen Funktionalen Sicherheitsprojekten ist eine Prototypenphase im Anschluss an die Erstellung eines Sicherheitskonzeptes, flankiert von leichtgewichtigen, groben Requirements, ein echtes Erfolgsgeheimnis.

Entscheidend ist, dass die Prototypenphase auch wieder ein Ende findet. Sobald die offenen Punkte zur Funktionalität durch den Prototypen klar geworden sind. Die durch den Prototyp gewonnenen Erkenntnisse sollten dann in funktionalen Blackbox Requirements niedergeschrieben werden. In der Phase hat man dann soviel Wissen gesammelt, um die Requirements so detailliert zu formulieren, dass sie testbar werden. Funktionale Blackbox Requirements bedeutet, dass es sich um die System Requirements handelt. In den meisten Funktionalen Sicherheitsprojekten benötigt man noch eine zweite Ebene von textuellen, testbaren Requirements. Dazu später mehr.

Ein Beispiel für ein testbares System Requirement sieht wie folgt aus:

Das System soll 2 Minuten nachdem die Temperatur unter 5°C gefallen ist, das Ausganssignal Vent_a auf 5 Volt setzen.

Wann müssen Requirements und Traceability in Funktionalen Sicherheitsprojekten fertig sein?

Hier gibt’s viele Missverständnisse. Kein Funktionales Sicherheitsprojekt verlangt eine Wasserfallentwicklung! Vielmehr können sich Requirements genauso im Laufe eines Projektes verändern, so wie es auch der Source Code tut.

Was das in der Praxis für die System Requirements bedeutet, haben wir schon im letzten Abschnitt besprochen.

Der Prototyp mit Hilfe dessen man die System Requirements vervollständigt und konkretisiert hat, liefert naturgemäß auch Informationen über die Architektur. Mit diesen Informationen dokumentiert man dann in grafischer Form die System- und Software Architektur. Typischerweise hat eine Architektur mehrere Sichtweisen. Eine Sichtweise sollte so gestaltet sein, dass die Funktionalen Blöcke der Software identifiziert werden können.

Für komplexe funktionale Blöcke ist es oft wieder eine gute Idee den Prototypen entsprechend zu erweitern und aus den gewonnenen Erkenntnissen die Software Requirements zu dokumentieren und dann die Traceability zu den System Requirements zu etablieren.

Für die Traceability in den Source Code, sollte man die Architektur nutzen. Der Detaillierungsgrad der Architektur bestimmt letztlich die Qualität und Genauigkeit der Traceability in den Source Code.

Das aufgezeigte Vorgehen entspricht einer Parallelisierung der Source Code Entwicklung mit den Requirements und Traceability. Fertig, konsistent und korrekt muss dies alles sein, wenn das Projekt fertig ist. Nicht vorher!

Es müssen auch nicht alle System Requirements fertig sein, bevor man mit der Architektur und den Software Requirements startet. Viel wichtiger ist, dass man planvoll vorgeht.

Fazit

Zusammenfassend lässt sich festhalten, dass eine reine Wasserfallentwicklung immer scheitert, wenn die Projekte groß und komplex werden. Andererseits scheitern die Projekte aber auch wenn man ohne Konzept bezüglich der Spezifikation des Systems das Kodieren beginnt.

Das gilt auch für Projekte der Funktionalen Sicherheit. Niemand kann am Anfang eines Projektes korrekte, vollständige und testbare Spezifikationen schreiben, die nie mehr geändert werden müssen.

Vollständig und im Detail nachvollziehbar muss ein Projekt vor allem am Ende sein. Der Weg, wie das Ziel erreicht wird, ist durchaus in der Praxis sehr variabel. Als sehr effizient und effektiv gilt inzwischen die Variante der parallelen Entwicklung und Dokumentation wie im Beitrag beschrieben. Je besser die jeweiligen Feedbackschleifen organisiert sind, desto erfolgreicher wird das Projekt, vor allem mit Bezug auf Zeit und Kosten.

Weiterführende HEICON Blogbeiträge

• Requirements Engineering 2.0 – Ansätze wie die Methode weiterentwickelt werden muss!
• Requirement Engineering – Aspekte die schon in der Theorie zu kurz kommen!