I am working for more than 10 years in the Automotive industry with the main focus on building software components in the middle of an ever-increasing technology stack on wheels.

During that time, I mainly focussed on defining what to build, how to build it, and overseeing the progress.

The name of the role changed from Software Engineer and Software Architect to Product Owner and Solution Architect.

Even if it sounds weird, the problems I encounter are not the complexity of the technology itself, but the overall structure and organization of knowledge that complicates the created software systems.

Propagate intent about what to build is very complex when the actual user - drivers, passengers, or other operators of a vehicle in case of the Automotive industry - is basically unreachable and 95% of the functionality is under the hood and not really experienceable.

Fundamental agile methodologies like the creation of user stories and personas do not work in such an environment.

A piece of this puzzle is proper requirements engineering in combination with the definition of a functional architecture (what is the intent) that is traceable to a logical architecture (how it is realized).

Most issues arise from misunderstandings between domain experts and software developers. A proper definition of what to achieve instead of writing down how to achieve it - which seems a common trait in Automotive (we will see why this is later) - will help to overcome at least some of the problems.

In upcoming posts, I will start with the fundamentals: What are requirements? How to write them? How to manage them? How do requirements and user stories relate to each other? How to define a functional architecture? Afterwards, I will share some methods and systems I find useful.

And since I don't like requirements management tools in the market and do not think that requirements management in general-purpose tools like Excel is a good approach, I will build my own tool - in public.