From Requirements to Commissioning in AGV Projects: Our Take on “Gerald Hahn, Requirements Engineer bei DS Automotion”

Why this story matters

When software runs real machinery, clarity upfront beats heroics later. In “Gerald Hahn, Requirements Engineer bei DS Automotion” (Speaker: Gerald Hahn, Company: DS Automotion GmbH), we heard a crisp, experience-driven view of exactly that early phase: requirements engineering for automated guided vehicle (AGV) systems. Hahn’s path spans a technical-leaning education, two decades in project management, a decade at DS Automotion, and—about two years ago—a move into the company’s software development department. The throughline in his account: in this project-driven environment, getting requirements right is the decisive move.

We recap his milestones and the specificities of DS Automotion’s software approach for AGV fleets, and we highlight why methodical, analytical, and communicative strength is often more critical than coding in this role. Above all, we translate his remarks into practical guidance for engineers and tech talent who want to operate where software meets complex real-world systems.

A move into software—without the classic coding background

Hahn frames his journey as grounded and pragmatic:

• HTL in electrical engineering
• followed by a university of applied sciences program in mechatronics and business, pursued part-time
• an early start in project management
• roughly two decades of project management experience, with the last decade at DS Automotion
• a move into the company’s software development department about two years ago

He points out that this transition was especially interesting for him because he did not come from a coding-first background. That resonates with what we often see across engineering organizations: not every critical role in software is about writing code day in, day out. In Hahn’s case, the leverage is in the methodical, analytical, and communicative work of shaping requirements at the very beginning of the process.

With electrical engineering and mechatronics/business as anchors, Hahn clearly speaks the language of technical systems. But his focus is not the editor; it’s the structures, decisions, and validations that turn discussion into a specification that downstream teams can execute on.

What DS Automotion builds—and why every software delivery is different

DS Automotion plans, builds, produces, and commissions automated guided vehicle systems. These systems require a “head control” layer that orchestrates overall sequence control and the logistics of vehicle movements. Hahn puts it plainly:

The second part is the kicker: this is not an off-the-shelf software product. While standard building blocks exist, the delivered solution is newly composed and rolled out per project.

That’s the essence of project business in this domain: each site, material flow, and interface has distinct characteristics. Standardization helps, but it does not replace tailored specification. For requirements engineering, that means precision up front is the best investment in everything that follows.

“Programmable engineering” at the start of the process

Hahn describes his work as happening “exactly at the beginning” of the software development lifecycle. He calls it “programmable engineering”—the phase where requirements are specified and anchored before development, testing, and commissioning.

The implication: do this well and you give downstream teams a usable target. Requirements definition is not paperwork—it’s the technical and organizational alignment that prevents rework and misunderstandings later.

Why requirements engineering is critical in AGV projects

Hahn articulates a familiar reality of project-driven work: at tender or contract award time, customers do not always know in detail how the system should ultimately work. That’s why a software concept is needed—to validate the intended solution and align expectations fully before implementation starts.

This is not a theoretical nicety but practical risk management. Deviations between what was sold and what is actually specified happen; “change management” (Nachtragsmanagement) is therefore part of the early phase by design.

In other words, requirements engineering here is both technical facilitation and complexity control. It makes sure changes are visible, justified, and handled in an orderly way.

How the specification emerges: remotely, on-site—but always through dialogue

Hahn outlines the practicalities: specifications are typically developed with customers via teleconferences; sometimes there are on-site workshops or multi-day working sessions. The outcome is a system requirements document (Pflichtenheft) that precisely describes material flow, transport processes, and the interfaces the customer needs. Only after the customer’s formal “yes” does implementation begin.

From our vantage point, this implies a simple operating system for the early phase:

• Talk, iterate, then write: discussion precedes specification.
• Material flow, transport sequence, and interfaces are the three anchor points of the software description.
• Formal approval is not a rubber stamp; it’s the handover to execution.

In AGV projects, this sequence is decisive because the modeling of flows and interfaces sets the stage for the stability of the delivered solution.

Active communication as a working principle

Hahn emphasizes that active communication is both essential and enjoyable: every customer is new, stakeholders are many, and the team goes into discussions proactively to arrive at the right definition.

He also names the cost of not doing this early enough:

For us, this is the central reminder: ask early, ask persistently, surface gaps—and force decisions. If you avoid these conversations, you’re only deferring cost and stress.

The skills that matter—and those you grow into on the job

Hahn is unambiguous: programming skills are not a prerequisite for his role. What matters is being at home methodologically and analytically—and being able to analyze together with customers. Add to that an active personality and a proactive communication stance.

He describes the segment as a niche, one where you become better over the years. That learning curve is not a blocker—it’s the motivation.

For engineers and tech talent, this sketches a realistic profile: if you organize complexity, think clearly, and enjoy turning open questions into clear agreements, you can create substantial impact in this field—with or without daily coding.

From Pflichtenheft to implementation—what’s at stake

The hinge in Hahn’s narrative is the Pflichtenheft—the point where conversation and workshops become a binding basis for development, testing, and commissioning. In a world where each solution is project-specific, the Pflichtenheft is the single point of truth.

What happens when this phase is weak?

• Late corrections due to imprecise modeling of material flows or interfaces
• Change requests without a clear origin or decision trail
• Bottlenecks in testing and commissioning because expectation and implementation don’t align

Hahn’s answer throughout is consistent: methodical work, proactive communication, and validation via a robust software concept before a single line of implementation begins.

Guardrails for strong requirements in AGV projects

Distilling Hahn’s points, we see a set of guardrails that fit the AGV project business:

1. Validate early, correct rarely: the software concept is the bridge between intention and execution.
2. Anchor on three pillars: material flow, transport sequence, and interfaces—complete, unambiguous, approval-ready.
3. Treat changes as first-class citizens: detect and manage deviations early and transparently.
4. Communication is an active discipline: ask, reconcile divergent views, and drive decisions.
5. Method beats tools: analytical clarity and a structured approach outweigh any tool checklist.
6. Learn by doing: the niche nature of AGV work rewards experience—each project raises your game and keeps work engaging.

These guardrails don’t replace the daily grind of drafting and refining a specification, but they direct focus to the levers that, in Hahn’s practice, make the difference.

A career pattern: from project management into requirements engineering

Hahn’s trajectory highlights a pattern we notice across engineering-heavy companies: project management experience is a strong springboard into requirements engineering—especially where software controls real-world systems. The overlap is clear:

• Coordinate stakeholders, balance expectations, and create commitment
• Surface and address risks early (here: via concept, Pflichtenheft, and change management)
• Document decisions so implementation, testing, and commissioning can flow

Aligned with his statement that coding isn’t mandatory, it’s an encouraging message for career movers with technical understanding and methodological strength.

Quotable takeaways—compressed into working maxims

• “Requirements definition is extremely important.” → Without clear requirements there is no robust implementation.
• “At tender time the customer doesn’t always know how the plant should function later.” → Validate before you implement.
• “We specify material flow, transport sequence, and interfaces in the Pflichtenheft.” → The three anchor points of the specification.
• “If early definitions don’t match later, it becomes expensive and time-critical.” → Clarity now saves massive effort later.
• “Be an active personality and initiate proactive communication.” → Requirements emerge from dialogue, not silence.

What we, at DevJobs.at, learned from this session

From “Gerald Hahn, Requirements Engineer bei DS Automotion” (Speaker: Gerald Hahn, Company: DS Automotion GmbH), we’re taking away a sober, practical picture of a role that’s often underestimated next to coding—but is mission-critical in DS Automotion’s project reality.

1. Tailored software requires tailored requirements: if you don’t “roll out” a product but deliver project-specific solutions, precision up front becomes the lever.
2. Validation is a responsibility: a software concept aligns “what was sold” with “what will be built,” protecting both the customer and the team from costly surprises.
3. Communication is a technical skill: in complex, interconnected systems, the quality of conversations is a direct precursor to the quality of implementation.

Hahn’s transition—project management into a software department without a classic coding arc—also underscores a broader truth: methodical thinkers who like to bridge expectation and execution can have outsized impact in requirements engineering. That impact shows up in robust Pflichtenhefts, clear decisions—and, ultimately, in AGV systems that run.

Conclusion: The first phase decides

This account is not a romanticized story but a practical instruction: in a niche like AGV systems—where each solution has distinct traits—the quality of requirements work sets the pace, cost, and satisfaction of the entire project. Hahn outlines the path without ornament: teleconferences, workshops, a precise Pflichtenheft, formal approval—then development, testing, commissioning. In this environment, requirements engineering isn’t a box to tick; it’s the runway that lets everything else take off.

Take that seriously and you’ll encounter fewer late-stage mismatches. And, like Hahn, you may well find the work both challenging and refreshingly varied: every project new, every cycle a chance to get sharper.

• 

  

  Kevin Greßlehner, IT Techniker bei DS Automotion

  Kevin Greßlehner von DS Automotion spricht im Interview über seinen ursprünglichen Zugang zur IT Technik und gibt einen Überblick über seinen Job im Unternehmen sowie Tipps für Anfänger.

  Watch now
• 

  

  Klemens Pleiner, Basis Software Developer bei DS Automotion

  Klemens Pleiner von DS Automotion gibt im Interview Einblicke in seinen Weg als Developer, das Besondere an seiner aktuellen Arbeit im Unternehmen und was seiner Meinung nach wichtig für Neueinsteiger ist.

  Watch now
• 

  

  Lukas Fiel, Test Automation Engineer bei DS Automotion

  Lukas Fiel von DS Automotion erzählt im Interview von seinem Werdegang von den eigenen Projekten bis hin zum Test Automation Engineering und welche Tipps er für Neueinsteiger bereithält.

  Watch now