Hi everyone – we’re Stefan and Matthias, and we’re excited to launch a brand-new format from our Digital Lifecycle Lab — DLL Talks.
Why DLL Talks?
DLL Talks stands for Digital Lifecycle Lab Talks. In this format, we explore engineering challenges and ideas — drawing from our experiences, inviting experts from industry and academia, and sharing insights on topics that shape product development today and tomorrow.
Let’s Start with… Requirements
Our first topic? Requirements in engineering — the foundation of every successful system.
Matthias: “In my experience, requirements can be managed very differently. Some projects use structured, formal methods. Others rely on informal conversations — and hope nothing gets lost. Over time, I’ve seen both strong and weak approaches.”
Requirements ≠ Just Text
When we talk about requirements, we actually mean Requirements Engineering, which consists of:
Elicitation, Analysis, Specification, Validation: capturing, refining, and approving what’s needed.
Management: tracking requirements throughout the lifecycle, understanding dependencies, and maintaining traceability.
Document-Based vs. Model-Based Requirements
Traditional (Document-Based):
Requirements are written in Word, Excel, or PDFs.
Good for human readability, but hard for machines to process.
Limits automation, traceability, and collaboration across disciplines.
Model-Based Requirements:
Requirements are stored as structured objects in a model.
Machines can analyze, trace, and link them with other elements — like CAD models, code, or simulations.
Encourages cross-disciplinary collaboration (mechanical, electrical, software) and creates a shared target vision.
Why This Matters in Today’s Engineering
Modern systems are complex. No longer purely mechanical, they integrate software, electronics, and controls.
Model-based requirements allow engineers to:
Manage large sets of structured data
Automatically trace changes
Link requirements to architectures, simulations, and tests
Avoid miscommunication through better alignment
Requirements as a Starting Point
Stefan: “Requirements don’t stop at definition — they’re the starting point of development. The better we define them, the better the architecture and design can align.”
This interplay between requirements and system architecture is vital. It helps create a clear target picture early — reducing rework, errors, and misunderstandings later in the process.
What's Next?
This was just the beginning. In our next episode, we’ll dive into how architecture and requirements interact in a model-based environment.
Got questions? Want to join the discussion? Reach out!
We’re building a community around modern engineering practices in our Digital Lifecycle Lab — and we’d love to have you as part of it.
