DS Automotion GmbH

Etablierte Firma

Alle Videos anzeigen

Gerald Hahn, Requirements Engineer bei DS Automotion

Gerald Hahn von DS Automotion berichtet im Interview über das Requirements Engineering: wie er in die Branche eingestiegen ist und was er Anfängern raten würde.

Beim Videoaufruf stimmst Du der Datenübermittlung an YouTube und der Datenschutzerklärung zu.

Video Zusammenfassung

In "Gerald Hahn, Requirements Engineer bei DS Automotion" beschreibt Gerald Hahn seinen Weg von HTL Elektrotechnik und einem berufsbegleitenden FH-Studium über zwei Jahrzehnte Projektmanagement (davon zehn Jahre bei DS Automotion) bis zum internen Wechsel vor zwei Jahren in die Softwareentwicklung – ohne Programmierhintergrund. Er erklärt, wie DS Automotion kundenspezifische Kopfsteuerungssoftware für fahrerlose Transportsysteme entwickelt und warum Requirements Engineering als frühe, aktive Schnittstelle zu Entwicklung, Integration, Test und Inbetriebnahme inklusive Nachtragsmanagement entscheidend ist. Sein Rat: methodisch-analytisch arbeiten, proaktiv mit vielen Ansprechpartnern kommunizieren und Anforderungen früh sauber fixieren, weil späte Änderungen teuer und zeitkritisch werden; die Nischenbranche bleibt dadurch abwechslungsreich und lernintensiv.

Requirements Engineering im FTS-Projektgeschäft: Unser Recap zu „Gerald Hahn, Requirements Engineer bei DS Automotion“

Warum diese Story zählt

Wer Software für reale Anlagen schreibt, weiß: Erst wenn Anforderungen sauber geklärt sind, kann die Implementierung zielsicher gelingen. In „Gerald Hahn, Requirements Engineer bei DS Automotion“ (Speaker: Gerald Hahn, Company: DS Automotion GmbH) haben wir eine kompakte, aber dichte Perspektive auf genau diesen Punkt gehört – aus der Praxis eines Unternehmens, das fahrerlose Transportsysteme (FTS) plant, baut, produziert und in Betrieb nimmt. Hahn hat seine Karriere vom technisch-wirtschaftlichen Bildungsweg über zwei Jahrzehnte Projektmanagement bis in die Softwareentwicklungsabteilung geführt – und er macht unmissverständlich klar, weshalb Requirements Engineering in diesem Umfeld zum kritischen Erfolgspfad wird.

Wir fassen zusammen, was sein Weg über die Jahre geprägt hat, wie DS Automotion Software für FTS-Projekte aufsetzt und weshalb methodisches und analytisches Denken im Anforderungsprozess wichtiger ist als das reine Programmieren. Vor allem aber verdichten wir die Hands-on-Learnings, die Hahn in seinem Erfahrungsbericht vermittelt.

Der Weg in die Software – ohne klassischen Programmierhintergrund

Gerald Hahn beschreibt seinen Werdegang als technisch fundiert und praxisnah:

Ausbildung an der HTL Elektrotechnik
anschließend die FH für Mechatronik und Wirtschaft – berufsbegleitend
frühzeitig Einstieg in das Projektmanagement
rund zwei Jahrzehnte Berufserfahrung im Projektmanagement, das letzte Jahrzehnt bei DS Automotion
vor etwa zwei Jahren Wechsel in die Softwareentwicklungsabteilung des Unternehmens

Er betont, dass dieser Schritt für ihn besonders interessant war – gerade weil er keinen klassischen Programmierhintergrund mitgebracht hat. Seine Aussage adressiert einen verbreiteten Mythos, den wir in vielen Tech-Karrieren beobachten: Nicht jede Schlüsselrolle in der Softwareorganisation erfordert das tägliche Schreiben von Code. In Hahns Fall ist es die methodische, analytische und kommunikative Schnittstellenarbeit, die den Unterschied macht.

„Ich habe jetzt vor zwei Jahren dann auch die Chance und die Möglichkeit bekommen, innerhalb der Firma in die Softwareentwicklungsabteilung zu wechseln. Und das ist speziell für mich sehr interessant, weil ich keine programmierte Ergebnisse habe.“

Dass er die Sprache der Technik beherrscht, liegt auf der Hand – Elektrotechnik, Mechatronik und Wirtschaft bilden ein solides Fundament, um Anforderungen in Maschinen- und Anlagenbauprojekten mit Software-Teams und Kund:innen auf Augenhöhe zu diskutieren. Aber sein Fokus ist nicht der Editor, sondern die Anforderungsdefinition und das methodische Vorgehen am Beginn des Softwareprozesses.

Was DS Automotion baut – und warum jede Software anders ist

DS Automotion plant, baut, produziert und nimmt fahrerlose Transportsysteme in Betrieb. Für diese FTS braucht es eine „Kopfsteuerung“, also eine übergeordnete Software, die Ablaufsteuerung und Logistik der Fahrzeuge orchestriert. Hahn formuliert das klar und ohne Buzzwords:

„…wir planen, bauen, produzieren und nehmen in Betrieb fahrerlose Transportsysteme. Und für diese fahrerlosen Transportsysteme brauchen wir quasi eine Kopfsteuerung, die quasi die ganze Ablaufsteuerung, die Logistik der Fahrzeuge quasi steuert.“

Entscheidend ist sein zweiter Punkt: Die Software ist kein Produkt „von der Stange“. Zwar setzt man auf Standardbausteine – die Lösung selbst wird aber für jedes Projekt neu zusammengesetzt und neu ausgeliefert.

„…kein eigentliches Produkt, das man einfach nur ausrollen und konfigurieren [kann]. Sondern das ist eine … entwickelte Software, die sich auf Standardbausteine stützt. Aber es ist immer wieder ein kompletter neuer Code, der dann zum Kunden ausgerollt wird.“

Genau hier liegt die Besonderheit des Projektgeschäfts im FTS-Bereich: Jede Anlage, jeder Materialfluss, jede Schnittstelle hat Eigenheiten. Standardisierbare Komponenten helfen – aber sie ersetzen nicht die maßgeschneiderte Spezifikation. Für das Requirements Engineering bedeutet das: Präzision am Anfang ist die beste Investition für alles, was folgt.

„Programmable Engineering“ am Anfang des Prozesses

Hahn verortet das, was er tut, „genau am Beginn“ der Softwareentwicklung. Er spricht von „Programmable Engineering“ – gemeint ist der Prozess, in dem die Anforderungen spezifiziert und solide verankert werden, bevor Entwicklung, Test und Inbetriebnahme loslaufen.

„…dieses Programmable Engineering, das genau am Beginn dieser Phase stattfindet, vom Softwareentwicklungsprozess, wo wir die Anforderungen spezifizieren, ist extrem wichtig, weil am Ende dieses Prozesses Schnittstelle in die nachgelagerten Bereiche wie Softwareentwicklung, Test, die Inbetriebnahme etc. stattfinden.“

Der Satz verdichtet die Verantwortung dieser frühen Phase: Wer hier sauber arbeitet, sorgt dafür, dass die Downstream-Teams ein klares Zielbild bekommen. Anforderungsdefinition ist nicht „Paperwork“, sondern die technische und organisatorische Weichenstellung, damit Entwicklung, Test und Inbetriebnahme nicht in Schleifen oder Missverständnisse laufen.

Warum Requirements Engineering in FTS-Projekten so kritisch ist

Hahn benennt eine zentrale Realität des Projektgeschäfts: Zum Zeitpunkt von Ausschreibung oder Auftragsvergabe wissen Kund:innen oft nicht bis ins Detail, wie die Anlage später funktionieren soll. Deshalb braucht es ein validierbares Softwarekonzept, das Erwartungshaltungen abgleicht und die Lösung gemeinsam schärft.

„Die Anforderungsdefinition ist auch deshalb extrem wichtig, weil der Kunde zum Zeitpunkt einer Ausschreibung, einer Auftragsvergabe nun nicht immer genau weiß, wie die Anlage später mal funktionieren soll. Und wir wollen mit dem Konzept, was wir dann als Softwarekonzept für den Kunden auch beschreiben, die endgültige Lösung validieren und die Erwartungshaltung vollständig erfüllen.“

Das ist kein theoretischer Luxus, sondern ein praktisches Risikomanagement: Abweichungen zwischen Sales-Versprechen und realer Spezifikation gehören zum Alltag – das „Nachtragsmanagement“ ist daher integraler Bestandteil der frühen Phase.

„…auch dieses Thema Nachtragsmanagement fällt in diese Bereiche hin.“

Mit anderen Worten: Requirements Engineering ist hier sowohl technische Moderation als auch Komplexitätskontrolle. Es stellt sicher, dass Änderungen sichtbar, begründet und geordnet abgewickelt werden können.

Wie die Spezifikation entsteht: Remote, vor Ort – aber immer dialogorientiert

Hahn beschreibt die konkrete Praxis, wie Spezifikationen mit Kund:innen entstehen: überwiegend per Telefon- bzw. Videokonferenz, bei Bedarf auch vor Ort in Form von Workshops oder mehrtägigen Arbeitstreffen. Das Ergebnis ist ein Pflichtenheft – mit eindeutigen Beschreibungen der Materialflüsse, Transportabläufe und Schnittstellen.

„…wenn wir Spezifikationen mit Kunden durchführen, dann passiert das meistens über Telefonkonferenzen, in seltenen Fällen auch wirklich vor Ort beim Kunden. Wir machen Workshops, Jahrtage etc. Und das Ergebnis soll sein, dass wir den Materialfluss, den Transportablauf und auch die Schnittstellen, die der Kunde benötigt, in einem Pflichtenheft exakt spezifizieren. Der Kunde sagt sein Ja dazu, und dann erfolgt erst der nachgelagerte Schritt mit der Softwareimplementierung.“

Aus unserer Perspektive steckt in diesem Abschnitt eine klare Checkliste:

Dialog und Iteration vor Spezifikation: Erst sprechen, dann schreiben.
Materialfluss, Ablauflogik und Schnittstellen sind die drei tragenden Säulen der Softwarebeschreibung.
Formale Abnahme („Ja“ des Kunden) ist mehr als ein Ritual – sie ist die Übergabe in die Umsetzung.

Gerade in FTS-Projekten macht diese Reihenfolge den Unterschied, weil die richtige Modellierung von Flüssen und Schnittstellen die spätere Stabilität der Lösung bestimmt.

Aktive Kommunikation als Arbeitsprinzip

Hahn betont, dass aktive Kommunikation nicht nur essenziell ist, sondern auch Freude macht: Es gibt immer wieder neue Kund:innen, viele Ansprechpartner, und man geht „aktiv hinein“ in das Gespräch, um die richtige Lösung zu definieren.

„Die aktive Kommunikation ist in dem Fall ganz wichtig bei uns. Das ist ja das, was besonders Spaß macht, weil der Kunde ist immer wieder ein neuer, sehr viele Ansprechpartner. Und man versucht, aktiv hineinzugehen in das Gespräch, in die Diskussion, um hier die endgültige Lösung zu definieren…“

Dieser Punkt wird unmittelbar pragmatisch, wenn Hahn die Konsequenzen unklarer Anfänge adressiert:

„…alles, was man am Anfang definiert – wenn man weiß, hinten raus matcht das dann nicht genau, wird es extrem aufwendig und teuer und auch zeitkritisch.“

Für uns ist das die vielleicht wertvollste Erinnerung: Frühzeitig klären, hartnäckig nachfragen, Lücken benennen – und Entscheidungen herbeiführen. Wer diese Gespräche scheut, verschiebt Kosten und Stress nur nach hinten.

Welche Skills zählen – und welche man später lernt

Klare Aussage: Programmierkenntnisse sind für Hahns Rolle nicht zwingend. Wichtiger sind methodisches Vorgehen, analytisches Denken und die Fähigkeit, gemeinsam mit Kund:innen zu analysieren. Dazu kommt die Persönlichkeit: aktiv sein, proaktiv kommunizieren.

„Ich glaube, die grundsätzlichen Anforderungen sind nicht unbedingt, dass man Programmierkenntnis hat, sondern es ist vielmehr wichtig, dass man auf der methodischen, analytischen Seite sich daheim fühlt, methodisch vorgeht, Sachen gemeinsam mit den Kunden analysieren kann… Man soll eine aktive Persönlichkeit sein, man soll proaktive Kommunikation mit den Kunden anstoßen…“

Und er ordnet das Marktsegment ein: FTS ist eine Nische. Learings entstehen über Jahre in der Firma und im Projektalltag. Das ist kein Hindernis, sondern der Ansporn.

„…gerade dieses Marktsegment des fahrerlosen Transportsystems [ist] nicht ein standardes Segment, sondern eher eine Nischenbranche. Wenn man viele Jahre in der Firma ist, wird man immer besser – und das ist der Ansporn. Die Projekte sind alle neu, die Projekte fordern immer aufs Neue, und das macht die Arbeit so kurzweilig.“

Für Tech-Talente und Entwickler:innen lässt sich daraus ein realistisches Profil ableiten: Wer strukturiert denkt, Komplexität sortiert und Freude daran hat, offene Fragen in klare Vereinbarungen zu überführen, kann in diesem Feld viel bewegen – mit oder ohne tägliches Coden.

Vom Pflichtenheft in die Umsetzung – was auf dem Spiel steht

Die Klammer seiner Aussagen ist eindeutig: Das Pflichtenheft ist der Moment der Verbindlichkeit. Es übersetzt Gespräch, Workshop und Analyse in eine Basis, auf der Softwareentwicklung, Test und Inbetriebnahme planbar werden. In einer Welt, in der jede Lösung projektspezifisch ist, schafft das Pflichtenheft die eindeutige Referenz.

Was steht auf dem Spiel, wenn diese Phase schwach ist?

Späte Korrekturen infolge unpräziser Materialfluss- oder Schnittstellenbeschreibung
Nachträge ohne klaren Ursprung und ohne saubere Entscheidungsgrundlage
Engpässe in Test und Inbetriebnahme, weil Erwartung und Implementierung nicht zusammenpassen

Die Antwort darauf ist das, was Hahn durchgängig beschreibt: methodisches Arbeiten, proaktive Kommunikation und Validierung mit einem tragfähigen Softwarekonzept vor der Implementierung.

Leitplanken für gute Anforderungen in FTS-Projekten

Aus Hahns Punkten lässt sich ein Set an Leitplanken kondensieren, das im FTS-Projektgeschäft Orientierung gibt:

Früh validieren statt spät korrigieren: Ein Softwarekonzept ist nicht Deko, sondern der verlässliche Rahmen für Erwartung und Umsetzung.
Materialfluss, Transportablauf, Schnittstellen: Diese Dreifaltigkeit trägt die Spezifikation – vollständig, eindeutig, abnahmefähig.
Nachträge gehören dazu: Wichtig ist, sie frühzeitig zu sehen und geregelt zu managen.
Kommunikation ist ein aktiver Sport: Fragen stellen, divergierende Sichtweisen auflösen, Entscheidungen herbeiführen.
Methodik vor Tooling: Analytisches Denken und sauberes Vorgehen schlagen jede Toolliste.
Lernen im Projekt: Das Nischenumfeld FTS belohnt Erfahrung – jedes Projekt macht besser und hält die Arbeit kurzweilig.

Diese Liste ist kein Ersatz für die tägliche Arbeit am Anforderungsdokument – aber sie fokussiert den Blick auf das, was in Hahns Praxis den Unterschied macht.

Karriereperspektive: Vom Projektmanagement ins Requirements Engineering

Hahns Werdegang zeigt eine Anschlussfähigkeit, die wir in vielen Unternehmen mit Engineering-Fokus wiederfinden: Projektmanagement-Erfahrung ist ein starkes Sprungbrett ins Requirements Engineering – besonders dort, wo technische Systeme im realen Betrieb bestehen müssen. Die Überlappung ist offensichtlich:

Stakeholder koordinieren, Erwartungen ausbalancieren, Verbindlichkeit herstellen
Risiken früh erkennen und adressieren (hier: durch Konzept, Pflichtenheft, Nachtragsmanagement)
Entscheidungen dokumentieren, damit Umsetzung, Test und Inbetriebnahme reibungslos anschließen

Dazu passt seine klare Aussage, dass Programmierkenntnisse nicht zwingend sind. Für Quereinsteiger:innen mit technischem Verständnis und methodischer Stärke ist das ein ermutigendes Signal.

Unsere wichtigsten Zitate – als Merksätze übersetzt

„Die Anforderungsdefinition ist extrem wichtig.“ – Ohne klare Anforderungen keine robuste Umsetzung.
„Der Kunde weiß zum Zeitpunkt einer Ausschreibung nicht immer genau, wie die Anlage funktionieren soll.“ – Darum zuerst validieren, dann implementieren.
„Wir spezifizieren Materialfluss, Transportablauf und Schnittstellen im Pflichtenheft.“ – Die drei Fixpunkte der Spezifikation.
„Alles, was man am Anfang definiert… wenn es hinten nicht matcht, wird es extrem aufwendig, teuer und zeitkritisch.“ – Früh klären spart massiv Aufwand.
„Man soll eine aktive Persönlichkeit sein und proaktive Kommunikation mit den Kunden anstoßen.“ – Anforderungen entstehen im Dialog, nicht im stillen Kämmerlein.

Was wir als DevJobs.at aus dieser Session mitnehmen

Wir haben eine klare, praxisnahe Skizze einer Rolle gesehen, die im Schatten der reinen Entwicklung gern unterschätzt wird, in Projekten wie denen von DS Automotion aber erfolgskritisch ist. Aus „Gerald Hahn, Requirements Engineer bei DS Automotion“ (Speaker: Gerald Hahn, Company: DS Automotion GmbH) nehmen wir drei Kerneinsichten mit:

Maßgeschneiderte Software braucht maßgeschneiderte Anforderungen: Wer nicht „ausrollt“, sondern projektindividuell liefert, muss am Anfang umso präziser sein.
Validierung ist Verantwortung: Ein Softwarekonzept ist die Brücke zwischen „verkauft“ und „gebaut“ – und schützt Kund:innen wie Teams vor teuren Überraschungen.
Kommunikation ist eine technische Fähigkeit: In komplexen, vernetzten Systemen ist die Qualität der Gespräche eine direkte Vorstufe zur Qualität der Implementierung.

Hahns Werdegang – vom Projektmanagement in die Softwareentwicklung, ohne klassischen Programmierhintergrund – zeigt zudem, dass in technischen Organisationen viele Wege in die Wirkung führen. Wer methodisch stark ist, analytisch denkt und gern die Moderation zwischen Erwartung und Umsetzung übernimmt, findet im Requirements Engineering ein Feld, in dem die eigene Arbeit unmittelbar Wirkung zeigt: in robusten Pflichtenheften, in klaren Entscheidungen – und am Ende in FTS-Anlagen, die laufen.

Fazit: Die erste Phase entscheidet

Dieser Erfahrungsbericht ist weniger eine romantische Story als eine nüchterne Handlungsanweisung: In einem Nischensegment wie fahrerlosen Transportsystemen, in dem jede Lösung Eigenheiten hat, entscheidet die Qualität der Anforderungsarbeit über Tempo, Kosten und Zufriedenheit. Hahn hat das ohne Umschweife umrissen – von der ersten Telefonkonferenz über den Workshop bis zur Abnahme des Pflichtenhefts. Requirements Engineering ist hier nicht Beiwerk, sondern die Startbahn, auf der Entwicklung, Test und Inbetriebnahme überhaupt erst abheben können.

Wer diesen Gedanken ernst nimmt, wird in FTS-Projekten seltener von späten „Mismatch“-Momenten überrascht. Und er wird die Arbeit – so wie Hahn – als herausfordernd und kurzweilig erleben: jedes Projekt neu, jedes Mal mit dem Ansporn, noch präziser zu werden.

Weitere Dev Stories