Die Herausforderung Nicht-Funktionale Requirements!

Meiner Beobachtung nach bekommt das Requirements Engineering im Allgemeinen nicht die angemessene Aufmerksamkeit. Wenn man Software und/oder Hardware Projekte betrachtet die Scheitern, ist ein fehlendes, oder falsches Requirements Engineering in vielen Fällen eine Hauptursache.

Wenn man einen Schritt weiter geht und sich die Arten von möglichen Requirements betrachtet, dann kann man in einem ersten Schritt, ganz grob eine Einteilung in Funktionale und Nicht-funktionale Requirements vornehmen.

In der Regel wird die Anzahl der Funktionalen Requirements, deutlich höher sein, als die Anzahl der Nicht-Funktionalen Requirements. Funktionale Requirements sind wesentlich homogener als Nicht-Funktionale Requirements. Wie der Name schon impliziert, beschreiben die Funktionalen Requirements, die Funktion des zu entwickelnden Systems. Der Nachweis der richtigen Implementierung, lässt sich meist einheitlich über einen Test führen. Nach Entwurf einer Architektur, lässt sich für funktionale Requirements auch recht gut eine Dekomposition durchführen.

Für Nicht-funktionale Requirements treffen die eben diskutierten Punkte meist nicht zu. Eine Dekomposition lässt sich für sie oft kaum durchführen und sie sind nicht einheitlich mit einem Test nachzuweisen. Obwohl Ihre Anzahl oft geringer ist, als die der funktionalen Requirements, sind sie aber viel eher „verantwortlich“ für das Scheitern von Projekten.

Daher beschäftigt sich der nachfolgendem Blog mit diesem Thema etwas näher.

Kategorien von Nicht-Funktionalen Requirements

Eine wesentliche Ursache der Probleme die durch Nicht-Funktionale Requirements entstehen, liegt darin, dass viele, Requirements unter dem Begriff zusammengefasst werden, die eine komplett eigenstände Betrachtung und Behandlung benötigen. Diese eigenständige Behandlung findet dann meist nicht statt und die Probleme werden damit größer.

Im obigen Bild sind einige Requirements Kategorien dargestellt, die klassischerweise oft unter dem Überbegriff Nicht-Funktionale Requirements zusammengefasst werden.

Im nachfolgenden Bild habe ich diese Requirements Kategorien in eine Ordnung gebracht. Ganz links stehen die Requirements Kategorien die einen hohen funktionalen Anteil bzw. funktionale Aspekte besitzen. Performance/Timing Requirements und Schnittstellen Requirements werden oft gar nicht als „echte“ Nicht-Funktionale Requirements betrachtet.

Vertrags- und Prozess-Requirements auf der anderen Seite der Skala dagegen, haben nur noch einen sehr indirekten oder gar keinen Einfluss auf die Funktionalität. Alle anderen genannten Kategorien liegen irgendwo dazwischen.

Hier deutet sich nun schon an das eine einheitliche Behandlung dieser Requirements nicht zielführend ist.

Die Requirements die noch stark mit der Funktionalität verbunden sind (linke Seite) können meist überwiegend mit Tests nachgewiesen werden. Für Requirements auf der rechten Seite ist die Anwendung klassischer Verifikationsmethoden (Test, Review, Analyse, Demonstration) gar nicht mehr zielführend. Vieles kann hier oft nur über Besprechungsprotokolle oder ähnlichem nachgewiesen werden.

Im Nachfolgenden Kapitel werden weitere Unterschiede herausgearbeitet.

Warum sind Nicht-Funktionale Requirements für das Scheitern von Projekten oft verantwortlich?

Die richtige Implementierung von Funktionalen Requirements liegt meist in der Hand einer Entwicklungsmannschaft oder eines einzelnen Entwicklers. Aufgrund des Fach-Know-Hows gibt es niemanden außerhalb dieser Gruppe, der auf diesen Teil des Projektes signifikant Einfluss nehmen kann und will. Sollte es trotzdem der Fall sein, sind die Problemstellungen meist eindeutig und damit schnell und zu lösen. Darüber hinaus hat die Entwicklungsmannschaft ein großes Interesse (Ehrgeiz des Ingenieurs) die gestellten Anforderungen richtig umzusetzen. Die Ausnahme bilden „klassische“ Forschungsprojekte. Diese Projekte sind darauf ausgelegt, dass technologische und funktionale Fragestellungen vollständig offen sind. In solchen Projekten ist allerdings der Einsatz der hier diskutierten Art des Requirements Engineering nicht sinnvoll.

Bei Nicht-Funktionalen Requirements gibt es deutliche Unterschiede. Es gibt wesentlich mehr, unterschiedliche Interessensgruppen. Das klassische Beispiel sind Schnittstellen Requirements. Hier liegt es in der Natur der Sache, dass mehrere Beteiligte sich auf eine gemeinsame Lösung und technische Umsetzung einigen müssen. Diese Abstimmungsprozesse sind komplex, aufwendig und langwierig.

Vertrags- und Prozess Requirements benötigen die Einbeziehung des eigenen und des Kundenmanagement. Bei der Lösung offener Fragestellungen bei solchen Requirements spielen politische Interessen eine Rolle. Dadurch wird die Einigung auf eine Lösung schwierig und manchmal auch unmöglich.

Performance/Timing Requirements stellen eine echte technologische Herausforderung dar. Ihre vollständige und korrekte Beschreibung ist schon sehr anspruchsvoll. Darüber hinaus ist eine Dekomposition auf untere Ebenen nur möglich wenn sehr viel Fach- und Detailwissen über das System vorhanden ist. Die technische Komplexität die dadurch in ein Projekt hineinkommt, ist zu Beginn sehr schwer abschätzbar. Es steigt aber das Risiko des technischen Scheiterns des Projektes.

Die einzige Gemeinsamkeit die diese Requirements haben ist Ihre Gruppierung als Nicht-Funktionale Requirements. Wie beschrieben gibt es, im Gegensatz zu funktionalen Requirements, viel mehr, unterschiedliche und komplexe Herausforderungen, um diese Requirements korrekt umzusetzen. Daraus ergibt sich dass ein Scheitern aufgrund solcher Requirements deutlich wahrscheinlicher ist als das Scheitern durch rein funktionale Requirements.

Fazit:

Die

• meist geringere Anzahl von Nicht-Funktionalen Requirement im Gegensatz zu Funktionalen Requirements,
• die Vereinfachung der Problemstellung durch die Gruppierung von völlig unterschiedlichen Requirements unter einem Begriff,
• sowie die Unterschätzung der Komplexität der hinter Nicht-Funktionalen Requirements verborgenen Fragestellungen

sind wesentliche Gründe warum Nicht-Funktionale Requirements für das Scheitern von Projekten verantwortlich sind. Die sachgerechte und bewusste Unterteilung der Nicht-Funktionalen Requirements ist ein erster wichtiger Schritt, um das Problem zu beherrschen. Wenn dann noch eine geeignete Vorgehensweise für die jeweils identifizierte Kategorie definiert wird, kann ein wesentlicher Grund für das Scheitern von Projekten eliminiert werden.

Ihre individuellen Fragen zum Requirements Engineering beantworten wir gerne in einem ersten, kostenlosen 30min Beratungsgespräch!
Vereinbaren Sie gleich einen Termin: Eine kurze Mail an info[at]heicon-ulm.de genügt, oder greifen Sie gleich zum Telefonhörer: +49 (0) 7353 981 781 (Mo bis Fr 08:00 – 18:00Uhr).