Systemspezifikation – wozu der Aufwand?

Bei der System- oder Softwareentwicklung wird ein wichtiger Aspekt oftmals nur stiefmütterlich behandelt: die Erstellung und Pflege der Systemspezifikation. Was können die Gründe dafür sein, und welche Folgen ergeben sich daraus? Und noch wichtiger: Wie kann man diesem Problem begegnen? Dieses Thema möchten wir in diesem Blog behandeln.

Die Gründe:

Die Gründe für eine mangelhafte Systemspezifikation sind vielfältig. Oftmals wird schlicht die Notwendigkeit nicht erkannt. Ein Beispiel aus der täglichen Praxis: Ein Unternehmen soll im Kundenauftrag das Produkt XY entwickeln. Der Kunde liefert dem Unternehmen seine Anforderungen in Form eines Lastenhefts. Das Lastenheft wird von der Systementwicklung analysiert und kommentiert. Es folgen Lastenheftabstimmungen zusammen mit dem Kunden – die Dokumentation erfolgt dabei direkt im Lastenheft, z.B. über ein Kommentarattribut. Es wäre nun sinnvoll, die gewonnenen Erkenntnisse in Form einer Systemspezifikation zu dokumentieren und die gewonnenen Systemanforderungen mit den Kundenanforderungen zu verlinken. Oftmals wird dieser Schritt jedoch übersprungen. Die abgestimmten Kundenanforderungen werden direkt an die Entwicklungsabteilung kommuniziert, wo von nun an „im stillen Kämmerlein“ das System entwickelt wird. Das Abholen von Systemanforderungen seitens der Entwickler wird als unnötig erachtet. Wozu sollte dieser Aufwand betrieben werden, wenn die Entwicklung auch ohne diesen Schritt möglich ist? Darüber hinaus benötigen die Erstellung und auch die Pflege der Systemspezifikation Zeit und verursachen Kosten – Kosten, die aus Managementsicht gerne gespart werden. Schließlich wartet bereits das nächste Lastenheft darauf, analysiert und abgestimmt zu werden. Das resultierende Produkt wird mit hoher Wahrscheinlichkeit einen Qualitätsverlust erleiden, und auch das Unternehmen selbst wird mit den Folgen dieser Vorgehensweise konfrontiert werden.

Die Folgen:

Ein wichtiger Bestandteil der Systemspezifikation ist die Dokumentation des Systemverhaltens. Lastenhefte erfüllen oftmals nicht die hohen Anforderungen an ein gutes Anforderungsdokument und sind daher als Verhaltensbeschreibung in der Regel ungeeignet. Wenn die Erstellung der Systemspezifikation also nicht gewissenhaft durchgeführt wird, fehlt diese Verhaltensbeschreibung oder ist zumindest nicht aktuell. Häufig kommt es vor, dass Änderungen am System von der Entwicklungsabteilung selbst ausgehen und bereits umgesetzt werden – auf Systemebene kann dann nur noch eine Nachdokumentation erfolgen. Das umgekehrte Vorgehen sollte jedoch die Regel sein!

Eine weitere Folge ist die fehlende Verlinkung aller Entwicklungselemente. Wenn die Systemspezifikation und das reale Systemverhalten nicht übereinstimmen, ist eine Traceability von Softwareelementen über Systemanforderungen hin zu den Kundenanforderungen nicht möglich – wie soll also gewährleistet werden, dass alle Anforderungen korrekt und vollständig umgesetzt wurden?

Auch Nachfolgeprojekte werden durch eine schlechte Systemspezifikation beeinflusst. Eine gute Systemspezifikation könnte eine stabile und abgestimmte Grundlage für das neue Projekt sein. Fehlt diese, gehen bereits gelerntes Wissen und geleistete Arbeit verloren. Frühere Fehler werden erneut gemacht.

Gegen Ende der Produktentwicklung ist die Systemspezifikation schließlich die Grundlage für Systemtests. Wenn diese jedoch nicht das tatsächliche Systemverhalten widerspiegelt, hat der Systemtest nur wenig Aussagekraft. Die Folge sind Funktionen, welche den Systemtest nicht bestehen, da ihr Verhalten von der Systemspezifikation abweicht. Viel schlimmer sind jedoch Funktionen, die vom Systemtest überhaupt nicht erfasst werden, weil sie im Produkt zwar implementiert sind, aber niemals den Weg in die Systemspezifikation und damit in einen Testfall gefunden haben!

Zudem sollte nicht unterschätzt werden, dass eine gute Systemspezifikation mit angemessenem Abstraktionsniveau eine hervorragende Grundlage für Kundengespräche und -abstimmungen darstellen kann. Während der Produktentwicklung wird es sicherlich zu Rückfragen seitens des Kunden kommen. Wenn die Systemspezifikation dessen Anforderungen übersichtlich strukturiert und gut verständlich aufbereitet, steigt die Akzeptanz des Kunden und ein erfolgreicher Projektabschluss wird umso wahrscheinlicher. Fehlt eine gute Spezifikation jedoch, ist bei Rückfragen des Kunden oftmals Nacharbeit erforderlich, um eine Gesprächsgrundlage zu schaffen – Powerpoint-Präsentation werden mühsam erstellt und ausgetauscht, finden jedoch nie ihren Weg in die Systemspezifikation.

Auch unternehmensintern ist die Systemspezifikation ein gutes Hilfsmittel für neue Projektmitarbeiter oder auch das Management, um sich einen Überblick über das System zu verschaffen.

Fazit:

Es ist die Aufgabe des Requirements Engineers als Teil der Systementwicklung, ständigen Kontakt mit der Entwicklungsabteilung zu pflegen. Nur wenn seine Arbeit, unter anderem in Form der Systemspezifikation, eine Unterstützung für die Entwicklung darstellt, werden beide Abteilungen Hand in Hand arbeiten und von diesem Vorgehen profitieren. Es gilt also nicht nur, einem definierten Prozess zu folgen, welcher die Erstellung und Pflege einer Systemspezifikation vorschreibt – der Job des Requirements Engineers beinhaltet auch eine nicht zu unterschätzende menschliche Komponente.

Ist dieser Zustand des gemeinsamen Arbeitens erreicht, können die zuvor genannten negativen Folgen, die sich aus einer schlechten Systemspezifikation ergeben, vermieden werden.

Dieser Blogbeitrag wurde von Marcel Klein für HOOD geschrieben.