Kategorien von Requirements – Warum sind sie sinnvoll?

Wenn ich den aktuellen Stand des Requirements Engineering reflektiere, fallen mir folgende Punkte auf:

1. Es gibt inzwischen eine Vielzahl guter Werkzeuge zur Dokumentation von Requirements
2. Es gibt gute und etablierte Methoden zur Erstellung von natürlich sprachlichen Requirements
3. Es gibt noch relativ wenig standardisierte Methoden zum richtigen Umgang mit immer wiederkehrenden Kategorien von Requirements

Ich möchte in diesem Blog-Beitrag insbesondere den letzten Punkt der Kategorisierung von Requirements beleuchten.
In nachfolgender Darstellung versuche ich die Fragestellung grafisch zu erfassen:

Die Darstellung zeigt die Beziehung zwischen ausgewählten Kategorien und Ebenen von Requirements:
X-Achse: Funktional, Performance, Nicht-funktional
Y-Achse: System und Software Requirementsebene

Kategorie: Funktionale Requirements

Wenn wir funktionale Requirements betrachten, dann werden diese nach der Definition der Systemgrenzen und der System-Schnittstellen mit den bewährten Methoden zur Erstellung von natürlich sprachlichen Requirements erstellt und in einem geeigneten Werkzeug erfasst.

Eine erste Herausforderung stellt dann in der Praxis die Vervollständigung der Requirements dar. Die Erstellung von Modellen kann hier helfen das Ziel zu erreichen. Da die Erstellung eines Modells aber auch mit erheblichem Aufwand verbunden ist, ist diese Weg in vielen Projekten nicht möglich und sinnvoll. Stattdessen werden in der Regel Reviews durchgeführt um die Vollständigkeit der Requirements zu erreichen.

Im nächsten Schritt sollen die System Requirements in Software Requirements aufgebrochen werden. Dies stellt auch oft eine große Herausforderung dar. Zu empfehlen ist, ein Verhältnis von 1(System Requirements) zu 3 bis 7 (Software Requirements). Darüber hinaus werden an dieser Stelle wesentliche Architekturentscheidungen (implizit oder explizit) getroffen. Daher ist es wichtig parallel die System- und Softwarearchitektur zu entwerfen. In der Praxis wird diesem Teil des Requirements Engineering oft viel zu wenig Zeit eingeräumt. Aus meiner Erfahrung hängt dies damit zusammen, dass die Komplexität dieser Aufgabe falsch eingeschätzt wird.

Die aus diesem Prozess entstehenden Software Requirements können wieder mit den bewährten Methoden und dem Tooling erstellt werden. Hier gibt es vergleichsweise wenig Probleme, obwohl nicht verschwiegen werden soll, dass es nach wie vor viele Projekte gibt in denen auch die Formulierung der Requirements sehr verbesserungsbedürftig ist.

Kategorie: Performance Requirements

Performance Requirements werden oft nicht eigenständig betrachtet, sondern den (oft sehr unterschiedlichen) nicht-funktionalen Requirements zugeordnet. Aus meiner Sicht ist dies meist schon die erste Ursache, dass die Herausforderungen bei Performance Requirements nicht ausreichend bewusst gemacht werden.

Sowohl auf System- als auch auf Softwareebene begegnen mir z.B. immer wieder Requirements die zwar Vorgaben zum zeitlichen Verhalten geben, aber die Bedingungen unter denen diese Anforderungen erfüllt werden müssen sind oft sehr ungenau oder gar nicht definiert.

Eine weitere, komplexe Herausforderung ist der Aufbruch der System-Performance Requirements in Software und Hardware Performance Requirements. Dieser Aufbruch ist deutlich komplexer als bei rein funktionalen Requirements. Der wesentliche Grund hierfür liegt in der Komplexität des Zusammenspiels zwischen Hardware und Software. Insbesondere bei technologisch neuen Projekten, ist zum Zeitpunkt der Requirements-Erstellung das notwendige Detailwissen noch nicht vorhanden. Aufgrund dessen weil diese Problemstellung nicht bewusst ist, werden dann trotzdem Software Requirements erstellt, die technisch falsch oder irrelevant sind. In der späteren Testphase erzeugen solche Requirements dann unverhältnismäßig große Verifikationsaufwände, bzw. ein Nachweis ist technisch gar nicht möglich.

Aus meiner Sicht würde viele Performance Requirements wesentlich besser definiert werden, wenn man pro-aktiv die beschriebene Problemstellung berücksichtigen würde.

Kategorie: Nicht-funktionale Requirements

Die Kategorie habe ich an dieser Stelle für alle Requirements definiert, die weder in die Kategorie Funktional noch Performance fallen. Um der Problemstellung dieser Requirements wirklich gerecht zu werden, müssten hier aber weitere (Unter-)Kategorien gebildet werden: Prozess- oder Vertragsrequirements sind anders zu behandeln als Architektur Requirements oder Useability Requriements. Die Betrachtung dieser Punkte werde ich in weiteren, zukünftigen Blogs behandeln.

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).