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).
Hi Martin,
das ist ein sehr interressanter Beitrag!
Was Du beschreibst, sind die Auswirkungen von Unterlassungen. Der Grund für diese Auswirkungen liegt aber in den übergeordneten Prozessen des Unternehmens verborgen, die vor dem eigentlichen RE liegen.
Denn meiner Ansicht nach werden die nichtfunktionalen Anforderungen oft
a) nur oberflächlich vergeben
b) nicht mit den funktionalen Anforderungen verknüpft
weil keine Prozesse und Vorgehensweisen für diese Anforderungen definiert sind. Das heißt, die einzelnen Stakeholder kommunizieren und verstehen diese Anforderungen nicht. Oder werden einfach als unwichtig etrachtet und deshalb unterschätzt und ignoriert.
Aus diesem Grund sind diese Anforderungen dann oft scheinbar nicht testbar.
Nehmen wir z.B. nichtfunktionale Requirements aus der Produktion und der Wartung.
Wenn z. B. die Forderung besteht, dass ein Bauteil innerhalb eines bestimmten Zeitraums montiert werden soll, kann innerhalb eines Tests nachgewiesden werden ob der Zeitraum ausreicht oder nicht.
Forderungen, die die Wartung betreffen, können ebenfalls überprüft werden. Z.B. Fernwartung, Aufwände bei der Kalibrierung usw..
Bei Vertragsrequirements kann man z. B. die reinen Prozessrequirements durch den Nachweis der Erbringung der notwendigen Prozessschritte verifizieren. Andere Vertragsrequirements wie die Erfüllung von Normen, zugesicherten Kompatibilität usw. lassen sich dann wieder technisch prüfen.
Aus meiner Sicht lassen sich daher alle Requirements testen und nachweisen, sofern man sie messbar machen kann oder will!
In diesem Sinne noch ein schöner Abend.
Viele Grüße,
Paul
Auch von meiner Seite vielen Dank für den Beitrag!
Aus meiner Sicht gibt es sehr wohl aber noch Requirements an ein Produkt, die sich nicht verifzieren lassen. Ja, es gibt die funktionalen und die nicht-funktionalen Requirements. Diese sind oft miteinander verlinkt. Meist ergänzen die nicht-funktionalen die funktionalen in gewissen Bereichen, um ein Requirement näher zu definieren.
Weiterhin gibt es aber noch die Randbedingungen (auch nicht-funktionale Requirements). Das sind Requirements, die nicht direkt das Produkt beeinflussen. Beispiel: „Das Produkt muss im Dezember 2015 auf dem Markt sein“. Das ist ein Requirement das erstmal nichts mit dem Produkt zu tun hat, sehr wohl aber eine Anforderung, z.B. von Product Management gefordert werden kann, um, in diesem Fall, früher als die Mitwettbewerber auf dem Markt zu sein.
Ein Projektleiter muss ggf. diese Randbedingung in seinen Terminplan mit einfließen lassen. Im Beispiel: er würde evtl. mehr Mitarbeiter in das Projekt stecken, um den Termin halten zu können.
Mit freundlichen Grüßen
Johann Hoy
Sehr geehrter Herr Hoy,
das ist ein super Punkt.
Auch hier haben Sie recht, wenn Sie sagen, dass der Start of Production (SOP) auf den ersten Blick keinen unmittelbaren Einfluss auf die technischen Requirements hat. Das wäre auch so, wenn jedes Unternehmen unbegrenzte Resourcen zur Entwicklung hätte.
In der Praxis hat der SOP aber dann doch einen Einfluss auf die Priorisierung der Requirements.
Das heißt, wenn der SOP feststeht, können je nach Budget, mehr oder weniger Funktionalität zu dem gewünschten SOP realisiert werden.
Das passiert dann auch. Zumindesat bei den Unternehmen, die ein vernünftiges Projektmanagement besitzen… 🙂
Ich verweise an dieser Stelle auf das sogenenannte „magische Dreieck“ im Projektmanagement. Das „magische Dreick“ stellt das verfügbare Budget, erreichbare Produktqualität und realisierbarer Funktionsumfang in Zusammenhang.
Das heißt, an dieser Stelle sieht man, dass Requirementsmanagement und Projektmanagement in engem Zusammenhang stehen.
Viele Grüße,
Paul Huber
I went over this site and I conceive you have a lot of wonderful information, bookmarked .