Why Requirements Engineers Hesitate to Commit to Full MBSE – Securing Future-Proof Architecture in Requirements Engineering
Navigate the rational fears of disruption and complexity, and learn how to reduce risk before rolling out full Model-Based Systems Engineering.
In Part 6 of this mini-series by Iain Cunningham, we uncover the valid reasons why teams hesitate to fully adopt Model-Based Systems Engineering (MBSE).
You build complex systems to solve the challenges of tomorrow. When intent fades, the promise of full MBSE can seem like the perfect fix – yet the fear of disruption, complexity, and broken coverage holds many back. We believe that engineering demands clarity, not guesswork. Discover why this hesitation is a rational response to previous experience, and learn how to navigate the risks to build a future-proof architecture.
When You Think About Improving Traceability, What Concerns You Most: Disruption, Complexity, or Loss of Control?
In the previous article in this series, we looked at what a robust traceability approach actually requires in practice, across structure, coverage, verification evidence, and continuity over time. The natural next step is to act on that insight. However, in practice, many organizations and requirements engineers hesitate.
This is not unintended. It is typically based on experience.
Traceability spans multiple dimensions at once. Requirements need to remain structured, coverage needs to stay visible, and verification evidence needs to be trustworthy across versions and iterations. At the same time, many teams work across multiple tools, making it harder to connect requirements, design, test cases, and execution results.
This creates a tension between the potential for improvement and the risk of making things harder in three ways:
The Three Risks of Rushed Traceability Adoption
- The risk of disrupting structure and ownership: Requirements engineers are the custodians of intent. They know large changes can introduce complexity before the organization is ready. What begins as an improvement quickly becomes overhead.
- The risk of breaking coverage and verification clarity: In fragmented environments, introducing new tools too early can make interpreting coverage worse. When the chain from requirement to test case to execution result is unclear, confidence drops, and teams fall back on manual workarounds.
- The risk of losing continuity across versions and workflows: If traceability does not behave consistently across parallel branches and evolving requirements, teams lose trust. Effort then shifts into reconstructing what was verified, under immense time pressure.
If these risks are not addressed early, the outcome is familiar. Adoption slows, stakeholders disengage, and traceability exists more in theory than in practice. Requirements engineers end up carrying the burden again, maintaining structure and reconstructing evidence across systems.
At a deeper level, this hesitation is not resistance to change. It is a rational response to previous experience. Most organizations have already tried to improve traceability and have seen more complexity than clarity. To be successful, improvement needs to reduce risk before it reduces effort.
If you are seeing similar challenges in your environment, it may be worth stepping back and looking at where those risks are most visible today. A small, targeted change is often more effective than a large transformation.
In the final article in this series, we will move from hesitation to action. We will look at a practical approach that aims to strengthen structure, improve visibility, and maintain continuity, without requiring a full transformation from day one.
Looking at your own experience, what has been the biggest barrier to improving traceability so far, and why? Join the conversation and help shape the future of system design. Follow Iain Cunningham on LinkedIn and share your experiences in the comments of his original article.