How Legacy Tools Limit Modern MBSE

A requirement changes. The systems engineer updates the specification, but the architecture model still reflects the previous version. The test team continues working from an exported spreadsheet. By the next review, each team has a different understanding of what the system must do.

Model-based systems engineering (MBSE) depends on meaningful connections between requirements, system behavior, architecture, and verification. When legacy tools leave those connections to manual updates, teams spend more time reconciling information and have less confidence in the decisions it supports.

For systems engineering and requirements management teams, the question is whether their tools can preserve engineering context as the system evolves. A model can be technically sound and still be difficult to use across a disconnected workflow.

What makes a tool a barrier to MBSE?

Age alone does not determine whether a tool supports modern engineering workflows. An established application may remain valuable if its information is accessible, versioned, and connected to the rest of the engineering environment.

Problems arise when tools isolate data, depend on repeated exports, or make relationships difficult to maintain. Requirements in documents, architecture diagrams in separate files, and verification results in spreadsheets can each serve a purpose. However, a team must still manage the relationships among them.

 

Industry Insight

NASA’s Systems Modeling Handbook illustrates the extent of this work. It covers using system models to support stakeholder expectations, technical requirements, verification, and validation, including generating engineering work products from the model. A modeling application used by one group cannot provide that continuity on its own.

Manual traceability becomes harder to trust

Traceability helps engineers explain why a requirement exists, how the design addresses it, and what evidence demonstrates that it has been met. That explanation depends on relationships that remain valid through change.

In disconnected environments, teams may maintain those relationships through document references, spreadsheet matrices, or manually copied identifiers. These methods can support a controlled baseline, but each revision introduces maintenance work. A requirement may be split, a component replaced, or a test procedure revised without every related record being reviewed.

The result can be a traceability matrix that looks complete while concealing outdated relationships. A link to a test case does not establish that the case verifies the current requirement, or that its latest result applies to the design under review.

Consider an illustrative change to a sensor reporting interval, from once per second to ten times per second. That change may affect data throughput, processing capacity, power use, and verification procedures. If the requirement is connected only to a subsystem name in a spreadsheet, engineers must reconstruct the other dependencies themselves.

Connected systems engineering software can make established relationships available for impact analysis and flag affected records for review. Engineers must still judge whether the links are correct and whether additional impacts exist. The benefit is a more reliable starting point for that judgment.

📖 Related Reading: How to Build End-to-End Traceability

Collaboration slows when context lives in separate files

Systems engineering requires people from different disciplines to make decisions using a shared understanding of the system. Legacy tools can make that difficult when collaboration revolves around distributing files.

An emailed specification or exported diagram captures a particular moment. As work continues, reviewers may add comments to different copies, discuss decisions in separate threads, or approve an artifact without seeing changes to related information. Someone then has to reconcile the feedback and update the engineering records.

This also creates an access problem. If only modeling specialists can navigate the model, other stakeholders may rely on screenshots or presentations that omit the relationships behind a diagram. Reviews become exercises in explaining and rebuilding context.

Modern engineering workflows should give stakeholders appropriate access to relevant information, with comments, decisions, and change history tied to the items being discussed. Shared access still needs permissions and configuration control so teams can distinguish work in progress from approved baselines.

📑 Guide: Configuration Management for Data-Driven Systems Engineering (DDSE)

Disconnected tools leave gaps in the digital thread

A digital thread connects relevant engineering information across the lifecycle so teams can follow its relationships and understand its history. For an MBSE team, that may mean following a stakeholder need through requirements and architecture to verification evidence.

 

Industry Insight

NIST describes the digital thread in manufacturing as connecting information silos across lifecycle processes. Its research also identifies gaps in information flow and the need to communicate meaning and feedback between tools. The same integration challenge matters when systems engineering teams connect requirements, models, and test information.

Moving data between applications is only part of the task. An export might preserve requirement text while losing relationship types, revision history, approval status, or the baseline associated with a test result. The receiving team has the content but lacks information needed to interpret it confidently.

A connected digital thread therefore needs stable identifiers, defined relationships, version context, and clear ownership. It can span multiple tools, provided their integrations preserve the information required for engineering decisions. Collecting files in a shared folder does not establish those connections.

▶️ Webinar: Building a Digital Thread

Tooling constraints can look like MBSE limitations

When teams add modeling to an unchanged document workflow, they may have to update both the model and a separate set of deliverables by hand. Modeling becomes another maintenance task, and engineers understandably question the value of the effort.

Some perceived MBSE limitations arise from this duplication. Teams cannot fully use connected models if reviews, approvals, and verification tracking still depend on separately maintained copies. Reports generated from controlled model data can reduce duplication, while retaining documents where contracts or stakeholders require them.

Software alone will not resolve unclear requirements, incomplete models, or inconsistent review practices. Teams also need agreed modeling methods, ownership rules, and training. Effective workflow modernization addresses those practices alongside the tools.

📖 Related Reading: How to Get Your Organization to Adopt MBSE