Reasserting the Role of Requirements Engineering in Advanced Systems Engineering

Conversation with our experts #2

Requirements Engineering and Systems Engineering have always been closely interlinked throughout the engineering lifecycle. It’s also well established that effective requirements management is a prerequisite for success. Yet, for decades, teams have often struggled with inadequate tools and inefficient handovers, resulting in neglected requirements and serious issues only discovered during testing phases.  

As systems grow in complexity and regulatory demands increase, the time has come for Requirements Engineering to be seen as a fundamental practice, not just an ancillary activity. More than ever, it must be recognized as a cornerstone of sound engineering practice. In fact, REConf 2026 will tackle this very challenge under the theme: Requirements Engineering as the conductor of Systems Engineering.  

To explore how to move from theory to action, we spoke with Renate Stücka, one of our consultants and Requirements Engineering experts at SodiusWillert. Renate has over 20 years of experience helping teams align tools, methods, and processes with real-world challenges. In this conversation, she explains why Requirements Engineering matters to integrate regulatory, safety, and contractual constraints early in the process and where organizations still stumble. Through clear examples and grounded advice, she reminds us of the strategic role of Requirements Engineering in maintaining alignment, avoiding costly rework, and supporting delivery on time within scope. 

Enjoy this second episode of our series, "Conversation with our experts"! 

1) Why is it so important today to think of Requirements Engineering as one of the cornerstones of Systems Engineering? 

Requirements Management has a long history as a key prerequisite in any successful Systems Engineering project. For decades, engineers have applied various tools and notations to implement usable mechanisms to identify, document, and manage requirements. Most often, teams were dealing with tools that were not really intended to be used for requirements management, and there were no means of smoothly handing over requirements to systems engineers without a great deal of manual routines and communication. As a result, this combination of imperfect tools and guidelines for team collaboration often led to misunderstood or overlooked requirements, gold-plating or scope creep, and serious issues only discovered during system integration tests. 

So, the need for having requirements management closely interlocked with systems engineering across the lifecycle was somehow always present, and today we have a tested and proven response to that need: Requirements Engineering.  

Which areas are typically involved in Requirements Engineering? 

Requirements Engineering includes requirements management PLUS a number of additional capabilities. Among those, verification, validation, tracking, and adaptation of requirements are particularly important: these capabilities help provide some sort of navigation context for Systems Engineering. With Model-based Systems Engineering (MBSE), a certain degree of formalism for describing systems engineering artifacts has been adopted. In an MBSE environment, those artifacts can be addressed and retrieved on a granular level. And this is where Requirements Engineering and Systems Engineering come together: the ability to link requirements with engineering artifacts facilitates verification and tracking of requirements and how these are implemented. Across the lifecycle, across engineering domains, and across versions and variants. 

Having Requirements Engineering and Systems Engineering closely interlocked across the lifecycle is essential for delivering high-quality systems. 

2) How can binding commitments (contractual, regulatory, safety, etc.) be integrated into the RE and SE loop from the very beginning of a project, in a structured and reliable way?  

The “how” is the second question. The “why” is what everybody involved in a Systems Engineering Project must understand. If the need is clear, engineers will begin to think of RE and SE as activity streams that go hand in hand. As an example, one of our Automotive customers began to introduce MBSE a couple of years ago. They were driven by the need to control costs induced by functional verification with prototypes and test cars. And right from the start, they took three fundamental decisions: 

• A cross-domain approach spanning software, hardware, electronics, and mechanical components, plus platforms and construction series 
• Full transparency of requirements for all teams involved, at any time: the single source of truth for contractual, regulatory, safety, client, and any other requirements. 
• Implementing a function-based view on features instead of a BOM-based view  

(Fig. 1) shows the principles of the combined RE and SE processes. RE and SE are closely interlinked to ensure that requirements are available in the required level of detail and are linked to the corresponding stage in the SE process. Carefully selected KPIs and reports provide a real-time overview of the status and potential bottlenecks, always with reference to the requirements. Being able to manage relationships between the requirements and engineering artifacts is key to transparency, traceability, impact analysis, trade studies, and many more benefits.  

Fig. 1 - Alignment of RE and SE Across the Engineering Lifecycle

So, how can this be technically accomplished?  

What’s needed is an artifact-centric view on requirements and engineering assets. Being able to address and access an individual requirement on any level of refinement and being able to connect this requirement with a corresponding systems engineering artifact is the starting point. Next, you’ll want to expand the link relationships step by step to all artifacts along the lifecycle that respond to the requirement, including the ability to navigate along those links from one artifact to another, even across tools. In fact, transparency on artifacts and their relationships is considered one of the most critical success factors. Full end-to-end data consistency, horizontally and vertically, across the product lifecycle, is the foundation for a cross-functional MBSE process. 

These traceability chains give us the data we need for assessing whether the requirement was correctly implemented and successfully tested. Furthermore, these traceability views precisely reveal the current status of project progress in many dimensions. And because those links connect the original artifacts in their native environment, the data remains unambiguous and consistently up to date. Many more insights can be derived from those traceability chains, e.g., impact analysis, change management, failure rates, to name but a few. 

3) What common mistakes do organizations frequently make when it comes to handling requirements?  

For decades, various studies have revealed that issues resulting from poor requirements handling are a major source of projects exceeding budget and schedules. While the importance of proper RE seems undisputed, the conclusions and resulting measures are often limited or affected by the tools selected, missing workflow instructions, legacy issues, and so forth. A fairly common obstacle can also arise from long-standing habits in performing certain tasks that are difficult to replace. I am convinced that the necessity of good RE is well understood in every company involved in system and software development. The challenge is to thoroughly identify the capabilities that the RE process and supporting tools should provide, and then select and deploy tools and processes in a way that enables sustainable use and real value for engineering teams. 

What misconceptions and organizational barriers remain today? 

We often observe the expectation that a new tool is the only investment needed to solve all the problems an organization has with RE. In fact, this is rarely the case. Before taking the tool decision, a careful and honest analysis is required to identify the weaknesses of the current environment and understand what capabilities are needed. Basically, you go through a requirements elicitation process to understand what’s needed. And just like requirements elicitation for any engineering project, it is mandatory to involve all stakeholders, validate if the process and methods fit the task, identify mandatory and optional features, and prioritize in case of conflicts. Don’t forget to think about new or revised workflows that may be needed. Take informed decisions and document decisions as well as the rationales behind.

Be aware that the “wishlist” can also include elements that have proven to be successful in the heritage environment, e.g., certain workflows or management systems. Once this groundwork is done, you are ready to take the next step: select the tools you would like to evaluate. 

4) Which best practices would you recommend when it comes to selecting a tool for RE and roll-out? 

It may sound like a no-brainer, but: “don’t believe the hype”. You may find that data sheets and product web pages claim to cover all the capabilities you have identified as needed to improve your RE environment. Take the time to evaluate tools carefully, and you will find that the actual implementation of the features on your checklist can make a huge difference in usability. As an example, every tool will claim that you can do test coverage reports. But how is this implemented? Is it a function you simply invoke from the user interface to see a nice graphic visualization of the share of requirements fully implemented and successfully tested, tested with failures, or not yet implemented? Or do you just get a list of test results with links back to requirements, leaving all the maths to you?  

It is worth taking a close look at such details when evaluating tools to avoid choosing a solution that theoretically covers all your requirements but in a poorly implemented way, forcing your team to perform many tasks manually. 

"For decades, various studies have revealed that issues resulting from poor requirements handling are a major source of projects exceeding budget and schedules. While the importance of proper RE seems undisputed, the conclusions and resulting measures are often limited or affected by the tools selected, missing workflow instructions, legacy issues, and so forth."

Make sure to also review whether the tool supports processes and workflows that you have defined for your engineering projects. Ideally, the tool should be able to meet your process and workflow requirements. If compromises are necessary, you should carefully examine the options, priorities, and consequences. 

Usually, you’ll want to migrate from an existing solution. Therefore, an important criterion for your tool decision should be whether it allows for a gradual migration from your existing environment. 

Finally, when you’re rolling out your new requirements engineering solution, make sure to allow sufficient time and resources for enabling and coaching all team members regarding the use of the tool and adherence to process and workflow guidelines. Stakeholders outside the engineering team should be involved to an extent that is appropriate to their contribution. Be aware that ongoing coaching may be advisable to get the most out of your investment in the environment for Requirements Engineering. Coming back to our customer: right from the start, they planned for a “unified” roll-out of their combined RE & SE approach: tool, process, method, mind. Domain teams are diverse and come with different backgrounds and expectations. This must be appreciated and responded to to create tangible results from the investment. Well-prepared, initial training and ongoing coaching are key to sustainable success. 

5) According to you, what are the best approaches to balancing conflicts between product specifications and the need to stay within reasonable time and cost constraints? 

In theory, it’s pretty simple. If the project plan indicates that the realization of all required features will result in the budget being exceeded, you’ll either try to increase the budget or remove some of the requirements to reduce costs. Most often, you’ll have to choose the second option. But how to make that tough decision? 

Mature Requirements Engineering does not solve the issue, but it will help you get to the right decision. Thanks to the traceability chains discussed above, you can perform a thorough impact analysis. You can visualize the impact of a change – in this case, removing a set of features – across the various stages of refinements until you see which system or software requirements would become obsolete. And if RE and SE are seamlessly working together, you will also have a clear view of elements of the system architecture or software modules, which are no longer needed. Based on this data, you can calculate potential savings and compare these with business revenues expected from this feature set. Identifying features that could be removed without causing too much damage is no longer guesswork. You can make an informed decision based on expenses and expected return. 

6) Renate, one last note to wrap it up? 

We’re observing that development cycle times are getting ever shorter, and the need for quick and flexible responses becomes ever more pressing. It seems to be a conflict that we should spend sufficient time with requirements elicitation prior to the beginning of what engineers often still consider as the “real” work. It seems to be even more devious to spend adequate time preparing the introduction of a new or revised RE tool/process. But when it comes to developing complex systems and software, a thorough and well-adapted requirements engineering process is the fundamental and indispensable prerequisite for successful systems engineering. It will take time to thoroughly define and implement, and the introduction should go smoothly and not be perceived as disruptive by the team members. Experience from many organizations shows that careful preparation and smooth step-by-step roll-out will show tangible and sustainable improvements for team members and for the organization. 

It is indeed very tempting and understandable to urge the elicitation phase at a time when development cycles are shrinking and when everything has to move at a pace that would have been unimaginable just a few years ago. However, Renate puts it very well: teams that take the time to carefully manage the requirements process, and above all that treat requirements as a genuine strategic investment, will be the ones that gain lasting control over quality, risks, and delivery.  

➡️ Learn more about SodiusWillert workshops & coaching for Systems & Software Engineering

➡️ And... about training courses and workshops, including our best-in-class start-up and advanced IBM Engineering Lifecycle Management training courses.