Share ZU:
11 June 2013 @ Philip Stolz

Die geeignete Lösungsdichte – Welche Frage hätte ich dem Kunden stellen sollen?

Im klassischen Requirements Engineering werden Anforderungen auf verschiedenen Abstraktionsebenen definiert:Abstraktionsebenen

Über die Abstraktionsebenen hinweg sollten die Lösungsdetails idealerweise nach und nach zunehmen. In der Automobilindustrie entspricht die Beschreibung des Ziels dem Lastenheft des Kunden und die abstrakte Beschreibung der Lösung dem Pflichtenheft des Lieferanten.

Das nachfolgende Beispiel zeigt, dass es hilfreich sein kann, über das richtige Maß an Lösungsdichte von Zeit zu Zeit nachzudenken.

Es sollte eine Systemfunktion eines radarbasierten Fahrerassistenzsystems entwickelt werden, welche die genaue Einbauposition des Systems bestimmte, um somit Toleranzen bei der Produktion des Fahrzeugs zu kompensieren. Das System konnte seine Einbauposition nur mit Hilfe von Radarmessungen bestimmen. Da der Mitarbeiter des Kunden ebenfalls Radarspezialist war, hatte sich die Funktionsentwicklerin dazu entschieden, die Performanceanforderungen der Funktion mit dem Kunden in ihrer Fachsprache abzustimmen. Dazu stellte sie dem Kunden folgenden Zusammenhang dar:Performance

Der Kunde forderte auf Grund dieser Darstellung 2000 gemessene statische Rohziele in 30 min, da 2000 Messungen notwendig waren, um die Einbauposition genau zu bestimmen. Mit der verwendeten Hardware und dem verwendeten Messverfahren war dies allerdings nicht möglich, woraufhin der Kunden begann, den Einsatz eines spezifischen Verfahrens zur Anpassung der Parameter des Kalman-Filters zu fordern. Die Abstimmung wurde auf genau dieser Detailebene fortgesetzt und mit sehr großem Aufwand zu Ende gebracht.

Es stellte sich nun die Frage, wie wir die Anforderungen an diese Funktion mit künftigen Kunden abstimmen sollten. Zum einen steckt nicht jeder Kunde so tief in den Details und zum anderen kann nicht für jeden Kunden der Aufwand für eine gänzlich andere Implementierung investiert werden, so wie er sie sich vorstellt.

Ich ging mit der Entwicklerin die Historie gewünschter Implementierungsänderungen durch und wir stellten fest, dass es sich bei allen Anpassungen immer entweder um eine Änderung handelte, die  bewirkte, dass die Genauigkeit der ermittelten Einbauposition besser wurde, das Verfahren dafür aber länger benötigte oder um eine Änderung, die bewirkte, dass das Verfahren schneller wurde, dafür aber nicht so genaue Ergebnisse lieferte.

Offensichtlich handelte es sich also um einen Trade-Off zwischen Genauigkeit und Geschwindigkeit. Die erreichte Genauigkeit der ermittelten Einbauposition wiederum hatte eine Auswirkung auf die Reichweite des Systems, also die Entfernung, in der das System andere Fahrzeuge korrekt erkennen konnte.

Nach all diesen Überlegungen stellte die Entwicklerin fest, dass es auch mit unserem technisch versierten Kunden genügt hätte, einfach nur festzulegen, bis zu welcher Genauigkeit die Einbauposition ermittelt werden muss. Alle restlichen Details hätten sich dann auch mit wesentlich weniger Abstimmungsaufwand ergeben.

Fazit:

Dieses Beispiel hat gezeigt, dass die geeignete Lösungsdichte von Anforderungen nicht nur davon abhängt, ob die Anforderungen in der Sprache des jeweiligen Kunden formuliert werden. An dieser Stelle kann es helfen, sich nocheinmal die erste Grafik dieses Artikels vor Augen zu führen. Man sollte mit seinem Kunden klären, was das System leisten soll, das er bekommt. Die Frage, wie es das leistet, sollte man besser nicht zum Gegenstand der Kundenabstimmung machen.

Hinweis:

 

Philip Stolz

Kontaktieren Sie Philip Stolz

Herr Philip Stolz ist als Senior Consultant im Bereich Requirements Engineering (RE) tätig. Seine Schwerpunkte liegen in der Einführung und Prozessverbesserung von Requirements Engineering (RE). Herr Stolz verfügt über eine fundierte Ausbildung im Bereich Software Engineering (Dipl.-Inf., Softwaretechnik). Durch Erfahrung aus unterschiedlichen Entwicklungsprojekten in verschiedenen industriellen Branchen sind ihm typische Projektsituationen sowie das Vorgehen bei der Einführung methodischer Verfahren innerhalb von Projektteams bekannt.