Ask ten systems engineers whether their requirements are traced to their model, and most will say yes. Ask how the trace stays current, and you'll hear about a spreadsheet, a column of requirement IDs pasted into model comments, or an export somebody runs before design reviews. It's traceability by ritual.
That gap isn't a discipline problem. SodiusWillert describes it as structural: requirements tools and modeling tools keep separate repositories, data structures and workflows, they serve different activities, and they're owned by different teams who change things at different speeds. SysML v2 doesn't remove that split, but it does change what you can build across it.
Why the manual trace goes stale
The failure mode is boring and expensive. A requirement changes in the requirements tool, the modeling team never hears about it, and the mismatch surfaces days or weeks later at a design review or during verification. Manual matrices, in SodiusWillert's words, go stale as soon as a requirement or model element changes, and they stop being workable past a few hundred requirements.
Then there's the audit problem. A manual coverage check leaves no repeatable trail. If a certification audit turns up gaps, you may be re-establishing trace links and re-justifying design decisions you thought were closed. Tracing only to a top-level block doesn't help either, since auditors usually want the specific sub-element that realizes a requirement. And for software work under DO-178C, the expectation runs both ways: every requirement needs a realizing element, and every design element needs a requirement that justifies it.
OSLC and ReqIF: what you're probably using now
Today's integrations mostly run on one of two mechanisms, and both have known weak spots.
- OSLC gives you live, linked-data connections, so a change in one tool is visible in the other without copying data. The cost is infrastructure. SodiusWillert points out, for example, that connecting Rhapsody to DOORS or DOORS Next requires IBM Rhapsody Model Manager, and some tool pairs have limited or no OSLC support.
- ReqIF is a vendor-neutral exchange format for requirements, attributes and relationships, supported by IBM DOORS, DOORS Next and Siemens Polarion. It's periodic, not live. It defines the data format but not the process, so something else still has to handle change detection and linking to model elements.
Michael Jastram, writing in June 2025, was blunter: with both paths, links break, versions diverge and reviews are frustrating. Traceability is promised more than it's practiced. His point is that value only appears when changes flow in both directions without anyone synchronizing by hand, and he argues SysML v1 failed at this, partly because of its XMI exchange format.
What SysML v2 changes
Three things matter here, and none of them is magic.
First, the standard Systems Modeling API. OMG adopted SysML v2.0, KerML 1.0 and the API and services specification in July 2025, and the API is the piece that lets a requirements tool or script read and write model data without a proprietary adapter. That's the foundation for real two-way sync rather than periodic file swaps.
Second, requirements are first-class elements with a textual form. A "shall" statement and its constraint can live in a file that diffs cleanly. Jastram notes that changes to requirements can show up in the same pull request as the design change that caused them, though he also cautions that SysML v2 text shouldn't be committed to Git without thought.
Third, the language semantics allow consistency rules, such as checking whether a model change is covered by a valid requirement. That moves traceability from something documented afterward to something enforced.
The loop above is the pattern SodiusWillert recommends in spirit: detect changes on every sync and mark affected links as suspect so engineers know exactly what needs a second look. A sync that silently overwrites is worse than no sync at all.
What tools are doing about it
Vendors are shipping pieces of this, with uneven maturity. Ansys SAM 2026 R1 lists bidirectional requirements exchange with DOORS Next and Codebeamer, plus an extended SysML v2 REST API, though the release post is promotional and doesn't spell out limitations. The 2026 releases of Cameo and CATIA Magic added SysML v2 in specific bundles, and the Cameo line has long had its own requirements integration plugins from the v1 era. Dalus is a SysML v2-native, browser-based platform that, like the others, exposes the model to outside tools. On the integration-service side, Itemis has described an AI4MBSE prototype for DOORS Next and Jama that maps requirement templates to SysML v2 elements, though Jastram notes its results are described in the white paper "at least in theory."
Ask any vendor the same questions: which requirements tools, which directions, how are deletions and renames handled, and what happens to a link when the requirement text changes.
What it won't solve
Synchronization moves data. It doesn't make the data good. A badly written requirement synced instantly in both directions is still a badly written requirement. Jastram himself doesn't expect most stakeholders to author requirements in SysML v2 text notation, so the requirements tool stays where it is, and the integration has to be good enough that people tolerate two systems.
Other trade-offs are worth planning for:
- Depth costs effort. Tracing below block level means someone decides which element types and how deep. Too shallow and auditors object. Too deep and coverage reports drown in noise.
- Formalization has upfront cost. Jastram is candid that the cost-benefit of formal modeling isn't always clear, and consistency rules only pay off if you invest in writing them.
- The REST API isn't universally loved. Opinions differ on whether it suits complex integrations, so test with your actual volumes.
- Suspect links create work. If every wording tweak flags twenty links, reviewers will start clicking "accept all." Tune what counts as a meaningful change.
A practical way to start
Pick one subsystem with a few hundred requirements, not the whole program. Sync it in both directions for a full change cycle, then audit what happened: how many links went suspect, how many were real, how long review took, and whether anyone could tell you why a given element exists. Script the sync on a schedule so it runs without a human remembering to do it.
Bottom line
The old integrations failed because they were periodic, one-directional or brittle. SysML v2's standard API and text form make a better design possible, but the proof is in your change cycle, not the datasheet. Test the sync with deletions, renames and edits, because that's where trace links usually die.