Share ZU:
2 June 2015 @ Frank Stöckel

Was machst Du eigentlich so?

Treffen sich Menschen in ihrer Freizeit, ist dies eine oft gestellte Frage, die uns, abhängig davon wer sie stellt, manchmal in eine nicht ganz einfache Situation bringen kann. Auch mir als Berater wird diese Frage oft gestellt und ist relativ einfach zu beantworten, wenn ich mit Gleichgesinnten, wie z. B. Ingenieuren, SW-Entwicklern, Projektleitern oder Beratern zusammen bin. Wird diese Frage jedoch von Personen aus Berufsgruppen sozialer Bereiche, des Gesundheitswesens, der Landschaftsbranche, Hotellerie etc. gestellt, müssen andere Formulierungen als die Standardsätze wie z.B. „ich unterstütze Entwicklungsunternehmen dabei, sicherzustellen, dass sie das richtige Produkt in möglichst kurzer Zeit und mit möglichst wenig Aufwand entwickeln“ verwendet werden.

Am Wochenende hatte ich mal wieder so einen Fall. Diesmal war es ein Polizist, der mir diese Frage bei einem Grillabend gestellt hatte. Weitab von der alltäglichen Arbeit wollte ich es mal anders angehen, mal etwas Neues versuchen, etwas verständlicher und anschaulicher ein Bild abzugeben, was ich denn eigentlich so mache. Die Idee war es, anhand eines Beispiels aus seinem Umfeld mein „Was ich eigentlich so mache“ konkret zu beschreiben.

Der erste Schritt meines Vorgehens war, im Arbeitsbereich eines Polizisten ein wichtiges und bekanntes System zu identifizieren. Was mir sofort in den Sinn kam, war das Martinshorn des Polizeiwagens. Es kennt auch jeder, ist wichtig, hat merkliche Auswirkungen auf seine Umwelt, ist gesetzlich verankert und Kinder sind davon auch sehr beeindruckt. Es ist also damit alltäglich und konkret für einen Polizisten.

Der zweite Schritt war, bei meinem Gesprächspartner zu erfragen, was denn an dem aktuellen System verbesserungswürdig ist bzw. welche Funktionen noch grundsätzlich fehlen. „Tja, das aktuelle System wurde kürzlich ersetzt und hat jetzt einen neuen Ton“, meinte er. Weitere Änderungen bzw. Verbesserungen sind ihm jedoch erst mal nicht eingefallen.

Klassischer Fall! Die direkten Anwender des zu verbessernden Systems können oft nicht eindeutig ihre Anforderungen nennen, da die Anwender mit dem System tagtäglich zu tun haben und aus ihrem gewohnten Gebrauch nicht den notwendigen Abstand haben, um das System auch mal grundsätzlich in Frage zu stellen bzw. um sich auch mal völlig neue Anforderungen auszudenken.

Als Nächstes habe ich versucht, durch Fragestellungen und durch Durchspielen von Szenarien mit dem Martinshorn das Zusammenspiel des Systems mit den Polizisten im Fahrzeug besser zu verstehen. Im Fokus waren der Fahrer und der Beifahrer in einem Polizeiauto.

„Wie ist das denn, wenn man so einen Einsatz hat, das Martinshorn aktiv ist und man mit hoher Geschwindigkeit durch die Stadt fährt?“, „Was stört denn am meisten?“. Mein Gast listete folgende Punkte auf: Aufgrund des hohen Lautstärkepegels im Auto kann der Funkverkehr im Fahrzeuginnenraum nicht mehr richtig aufgenommen werden und man ist auch nicht mehr so konzentriert im Straßenverkehr. Eine Kommunikation zwischen den Polizisten innerhalb des Fahrzeugs ist auch nur schwerlich möglich. Nach einer weiteren Frage, was denn nun das eigentliche Ziel des Martinshorns ist, wurde dann auch schnell klar, dass dadurch die Verkehrsteilnehmer im Straßenverkehr zwar auf das schnell fahrende Fahrzeug hingewiesen werden sollen, gleichzeitig werden jedoch auch die am Tatort befindlichen Personen wie z. B. die Bankräuber vor dem ankommenden Polizeifahrzeug gewarnt. Ein Nebeneffekt, der so nicht immer gewünscht ist.

Folgende Anforderungen ergaben sich im Rahmen des Gesprächs:

  1. Das Martinshorn in einem Polizeifahrzeug darf bei geschlossenen Fenstern und Türen nur einen Ton von maximal 40 dB im Fahrzeuginnenraum erzeugen.
  2. Hinter dem Fahrzeug und senkrecht zum Fahrzeug befindliche Hörer dürfen max. 50% vom maximalen Pegel hören. (Ein tönendes Martinshorn darf nur bestimmte Wege bzw. Räume mit der maximalen Lautstärke bestrahlen. Im Fokus stehen die in Fahrtrichtung befindlichen Fahrzeuge und Passanten).
  3. Die Lautstärke des Signaltons muss abhängig von der Geschwindigkeit vom System automatisch eingestellt werden. (Diese Abhängigkeit muss noch genau definiert werden. Es gilt das Prinzip: „Je schneller, desto lauter“.)
  4. Die Lautstärke des Martinshorns muss in fünf Stufen vom Fahrer oder Beifahrer eingestellt werden können (u. U. alternativ zu Nr. 3.).
  5. Wenn Funkverkehr im Fahrzeug eingeht, wird das Martinshorn geringfügig (geringfügig ist noch genauer zu definieren) heruntergefahren. (Damit die Polizisten den Funkverkehr mitverfolgen können.)

Alle diese Anforderungen, die wir hier diskutiert haben, fanden wir beide sehr interessant. Einmal für die Polizisten im Fahrzeug (die eigentlichen Nutzer) d. h. aus Sicht der Polizei und zum anderen jedoch auch für Unternehmen, die solche Systeme entwickeln. Was ich denn nun hier genau mache, habe ich wie folgt beantwortet. Wir unterstützen z. B. Firmen, die solche Signalsysteme entwickeln und Aufträge gewinnen möchten. Durch unsere Beratung ist unser Kunde bzw. das Signalentwicklungsunternehmen in der Lage, wichtige Anforderungen zu ermitteln, die einen Mehrwert zu Mitbewerbersystemen aufweisen. Wir nennen das „die Erhebung von Anforderungen“. Herauszubekommen was für den Kunden einen wirklichen Mehrwert bietet, damit er sich deshalb für das System unseres Kunden entscheidet.

Oder wir unterstützen Firmen bzw. Organisationen wie z.B. die Feuerwehr oder die Polizei bei der Erhebung, was sie von einem Signalisierungssystem erwarten, um dann eine Ausschreibung zu starten. Dies erfolgt in einem ersten Schritt jedoch noch unabhängig von einer möglichen Lösung, wie diese Anforderungen umgesetzt werden können. Dies hat den Vorteil, dass wir dann die Chance haben, ein System zu definieren, dass sich erst mal an dem wirklichen Nutzen orientiert und sich nicht nach den Technologien richtet, die aktuell verfügbar sind. Natürlich sind die verfügbaren und auch bezahlbaren Technologien ein entscheidender Faktor, aber bei der Erhebung der Anforderungen stören sie oft und hemmen Innovation.

Wichtig dabei ist, wenn es um innovative Anforderungen geht, die technische Machbarkeit nicht in den Vordergrund zu stellen. Dies sind andere Diskussionen, an denen auch andere Personen bzw. Rollen beteiligt werden sollen.

Im Gespräch haben wir auch mögliche Lösungen andiskutiert, wie man z.B. durch aktive akustische Systeme über die Lautsprecher im Innenraum den Signalton des Martinshorns teilweise unterdrücken könnte. Ein anderer Punkt war noch, stärker Richtungslautsprecher einzusetzen, um den Beschallungsraum noch wirksamer einzugrenzen. Aber das wird Thema beim nächsten Grillabend. Methodisch gesehen stellt dies dann die Ableitung unserer erhobenen Anforderungen dar, die aufzeigt, wie die Anforderungen nun umgesetzt werden sollen.

Ich gebe zu, die Erklärung war ein wenig länger als sonst, aber sie war, denke ich,  verständlicher.

Frank Stöckel

Kontaktieren Sie Frank Stöckel

Herr Frank Stöckel ist als Principal Consultant im Bereich Requirements Engineering (RE) tätig. Seine Schwerpunkte liegen in der Einführung von Requirements Engineering in Entwicklungsunternehmen mit Hilfe von Assessments, Seminaren, Workshops und Coaching. Fokus hierbei stellen wichtige initiale Pilotprojekte dar, die dann in unternehmensweite Prozessverbesserungsmaßnahmen führen, um RE langfristig in Entwicklungsunternehmen zu etablieren. Herr Stöckel führt Werkzeugauswahlverfahren für RM Tools durch, erarbeitet Konzepte zur Realisierung und Einführung von DV-Lösungen unter Einbindung von Werkzeugen des gesamten Entwicklungsprozesses. Darüber hinaus hat er in den letzten Jahren insbesondere in der Automobilindustrie Produktivstellungen (Roll-Outs) sowie Prozessentwicklungen von Anforderungsmanagement inkl. angrenzenden Prozessdisziplinen wie Projekt- und Testmanagement, Änderungsmanagement, Systemmodellierung, Lieferantendatenaustausch etc. erfolgreich geleitet. Kenntnisse in Modellierungstechniken runden sein Profil ab. Als erfahrener Trainer gibt er sein vielfältiges Wissen weiter, z.B. auch als akkreditierter Trainer für den Kurs „Certified Professional Requirements Engineering - Foundation Level".