New role at Hirschmann Car Communication: from Békéscsaba to Neckartenzlingen
Starting as a Systems/Requirements Engineer on radio tuner modules at Hirschmann Car Communication — a plant visit in Békéscsaba and ten days at the Neckartenzlingen headquarters.
I've started a new role at Hirschmann Car Communication as a Systems Engineer, working primarily as a Requirements Engineer on automotive radio tuner modules.
The move is a natural continuation of my previous work in the automotive industry. After working in system testing at Knorr-Bremse and Jaguar Land Rover, I moved to the other side of the V-model at Bosch. Hirschmann Car Communication stood out because of its active ASPICE implementation, giving me the opportunity to combine my background in software development, testing, systems engineering, and MBSE in a requirements-focused role.
The company
Hirschmann traces back to 1924, when Richard Hirschmann founded the Radiotechnisches Werk in Esslingen, near Stuttgart, marking over a century in communications technology for the automotive market. Today the company develops antenna, tuner, and infotainment systems alongside radio modules and M2M/telematics solutions for passenger and commercial vehicles. Headquarters and core manufacturing are located in Neckartenzlingen, Germany, with additional production in Békéscsaba, Hungary, and operations spanning Germany, Hungary, France, China, Japan, and the United States. Since October 2023 the company has been part of USI Global, after previously belonging to VOXX International since 2012.
Requirements engineering on radio tuner modules
My current work is focused on mechanical requirements, with the scope gradually expanding toward hardware and software requirements as I become familiar with the product and development process.
From a process perspective, the work is centered around the SYS.2 process area of the ASPICE model. That means taking stakeholder needs and system-level inputs and translating them into clear, structured, and verifiable requirements. The goal is not simply to document functionality, but to define requirements that can be understood consistently across engineering disciplines and traced throughout development and verification.
One of the aspects I appreciate most about requirements engineering is how it sits at the intersection of multiple disciplines. Mechanical, hardware, software, testing, and project management all depend on having specifications that are complete, unambiguous, and testable. Small improvements in requirement quality can remove uncertainty long before implementation begins, reducing unnecessary iterations later in the project.
Coming from system testing, I naturally look at requirements through the lens of verification. A requirement is only valuable if it can ultimately be demonstrated, measured, or tested. That perspective influences how I approach specification quality from the beginning.
Békéscsaba: the assembly plant
One of my first experiences in the role was visiting the manufacturing plant in Békéscsaba.
Rather than only reading documentation, I was able to follow the production workflow from assembly through quality control. Seeing how products move through manufacturing makes it much easier to understand the downstream impact of engineering decisions.
Requirements are often written long before production begins, but they directly influence the work performed on the factory floor. Seeing that connection firsthand provided useful context for the specifications I will be writing.
Ten days in Neckartenzlingen
The second stop was ten days at the Neckartenzlingen headquarters, where R&D, engineering, product management, and the SMT (surface-mount technology) lines support the same manufacturing footprint as Békéscsaba.
During those ten days I spent time with teams across product management, sales, simulation, hardware, mechanical engineering, systems engineering, system testing, and SMT production. The goal was not simply to learn the organization, but to understand how information flows between departments throughout the product lifecycle.
The SMT production area was particularly interesting. I was impressed by the level of automation in the internal logistics and by the way production issues are handled. Watching the manufacturing process makes it clear that engineering decisions have consequences far beyond the design office.
One lesson became increasingly obvious throughout the visit: a well-written requirement affects almost every engineering discipline. Mechanical design, hardware development, software implementation, testing, and ultimately manufacturing all depend on the quality of the specification. Strong requirements reduce ambiguity, reduce unnecessary development iterations, and ultimately help lower production costs by avoiding avoidable rework.
What this changes
Seeing both manufacturing sites and the engineering organization has reinforced the importance of writing requirements with downstream teams in mind. Going forward, I want to reduce ambiguity, improve specification quality through more consistent requirement formulation, strengthen traceability, and make verification and change management more measurable. Better requirements are not just better documentation. They make development more predictable for everyone involved.