Syside Update for Requirements Engineers: 0.9.0

Syside 0.9.0: requirements management, editable table views, and more productivity features

Requirements engineers tend to live in tables.

That is not a stylistic preference, it is how the discipline has worked for decades. A requirement has an ID, text, priority, verification method, allocated subsystem, status, and parent. The natural way to view hundreds together is in a grid. That is how reviews are run, sign-off recorded, and supplier exchanges handled.

Meanwhile, SysML v2's textual notation has been a quiet revolution for architects. System-as-Code is a comfortable home for anyone who already thinks in code, packages, and version control. For the requirements crowd, however, the textual notation has been a hard sell. Asking a requirements engineer to work in .sysml files is asking them to leave the medium they have used to communicate with stakeholders for thirty years.

Fortunately, with Syside 0.9.0, released on May 10th, 2026, that changes. This release focuses on bringing requirements engineers into the system-as-code world without asking them to give up the table. Syside 0.9.0 introduces editable Table and Matrix views inside the editor, ReqIF round-trip with the requirements management tools teams already use, and the ability to actually evaluate whether a requirement is satisfied, rather than just declare that it should be.

The full technical changelog is available on our community forum.

Grid views: the requirements engineer's home, inside Syside

In Syside 0.9.0, you can open a Grid view – a Table or a Matrix – of any collection of model elements directly inside Syside Modeler. Requirements, parts, actions, attributes, allocations, anything you can select with a SysML v2 view definition can be rendered as a Table or Matrix, with columns of your choosing, filterable and sortable in place. Both views are fully editable, and you can export any Grid view to CSV from the Modeler CLI and UI for downstream use.

For requirements work specifically, this means you can finally do in Syside the things requirements engineers have always done in their tools of record:

See a flat list of requirements across packages, with ID, text, and the metadata that matters to your project.
Sort by priority, filter by status, group by allocated subsystem.
Edit values directly in the cells and have the underlying SysML v2 source update with you.
Export the view to CSV for sharing with stakeholders who do not (yet) live in Syside.
Use the same view as a review surface in design reviews, instead of scrolling through code.

A new SysMLv2 Views pane lists every view defined in your model, so you can jump between them without remembering names or hunting through packages.

Moreover, the design intent of Grid views is wider than requirements. Any team that thinks in rows or cross-tabs benefits, from BOM-style part lists to action catalogs to traceability matrices. Requirements engineering in particular is the use case that has been waiting for this the most.

Try it yourself here.

For the technically curious, Grid views are built on SysML v2's view and rendering concepts. The same view definition that drives a tabular or matrix rendering can be reused to drive other rendering targets, meaning a Grid view is not a separate artifact. It is one projection of a model your team already maintains.

ReqIF round-trip: meet teams where their requirements live

Most organizations adopting SysML v2 are not adopting it into a vacuum. They have years (sometimes decades) of requirements stored in Codebeamer, Polarion, DOORS, or Jama, and the workflows that surround those repositories are not going to disappear because a new modeling notation is in town.

To bridge this gap, Syside 0.9.0 adds ReqIF import and export. ReqIF (Requirements Interchange Format) is the OMG standard for exchanging requirements between tools, and it is supported by every major requirements management product. The round-trip in 0.9.0 looks like this:

1. Export a ReqIF file from your requirements tool of record (Codebeamer, Polarion, etc.).

2. Import it into Syside Modeler. Upon import, the requirements appear as SysML v2 requirement elements, with their IDs, text, attributes, and hierarchy preserved. Open them in a Grid view and they look familiar.

3. Work on them alongside the rest of your model. Refine text, link them to parts, allocate them, evaluate them, version-control them with the rest of your .sysml sources.

4. Export back to ReqIF and re-import into the source tool, with changes preserved.

This unlocks a workflow we have been hearing demand for from enterprise users for over a year. Requirements teams can keep their system of record, architects can keep their model, and the two stay in sync without anyone copy-pasting across tools.

Try it yourself here.

The ReqIF support is conformant to the ReqIF version 1.2. We have tested the round-trip against Codebeamer. If you are using a tool we have not yet tested against, your feedback on the community forum is exactly what we need.

Not a Syside user yet? Get your free trial here.

Requirement evaluation: from declared to checked

Crucially, listing requirements is not the same as satisfying them.

A requirement document tells you what should be true. Until now, the link between that should and what your model actually says has, in most tools, been a manual or paper-based exercise. Someone reads the requirement, looks at the design, and asserts in a review that it is met.

SysML v2 makes the satisfaction relationship a first-class element of the language: a requirement defines a constraint, a part claims to satisfy it, and the model can be asked whether the claim holds. To achieve this, Syside 0.9.0 builds on the expression evaluation capabilities that we introduced in earlier releases (Compiler.evaluate_feature, calculation evaluation, unit conversion) and adds requirement evaluation taking into account the declared assumptions.

In practical terms, this means:

Given a requirement with a constraint such as "mass shall be no more than 1.5 kg", and a part with a calculated mass attribute, Syside can compute whether the constraint is satisfied, across mixed units, propagated through value rollups.
A requirements satisfaction matrix becomes verifiable, not declarative.
Failing requirements can be reported in CI, in a CLI workflow, or in an interactive review session.

This is where system-as-code starts paying off concretely for requirements work. Traceability is no longer a static artifact you need to maintain by hand. It is a property of the model that can be re-evaluated whenever the model changes.

See how it works here.

Also in this release

A few more changes worth flagging, briefly.

SysML v2 standard library updated to the 2026-03 version. Syside 0.9.0 tracks the latest published standard library, so your models inherit the most current definitions without manual intervention.

Inlay hints in the editor. On the UI front, inferred types, implicit subsettings, and other implicit SysML v2 information is now rendered inline in the editor as inlay hints. They are enabled by default VS Code user settings, but you can update them to show only when needed (for example, when keyboard command is pressed). You can also customize which hints exactly are shown in the Syside configuration settings. Find out more in our documentation.

Inline filters on diagram views. Diagram views now support namespace filtering through inline filters, so narrowing a busy diagram down to the elements that matter for the current conversation takes seconds. Try it yourself here.

User-wide and per-project configuration. Syside now reads a user-wide syside.toml and a non-version-controlled project-local syside.user.toml in addition to the existing project config. Personal preferences no longer have to live in shared repositories.

Breaking changes ahead of v1.0. This release contains a number of breaking changes – in the Automator CLI, the interpreter's scalar value handling, validation diagnostics, and elsewhere – that we needed to land before v1.0. Full details are in the changelog; we heavily recommend reading it before upgrading production projects. Important: we expect more breaking changes in the upcoming months as we get closer to v1.0

Looking ahead

Ultimately, Syside 0.9.0 is among the final feature releases on the path to Syside v1.0. Version 1.0 will mark a stable Syside Automator API, full Sysand integration into Syside Modeler, and the foundation of stability that production projects require.

The themes in this release – meeting requirements engineers where they work, making traceability verifiable, and integrating with the requirements management tools enterprises already run – are the same themes that will guide the months after v1.0. The Syside Derisker public beta, also on the 2026 roadmap, will extend that same logic into safety, reliability, and security analysis: an environment in which the artifacts of every engineering discipline live alongside the architecture, in code, and stay in sync with it.

Not a user of Syside yet? Get your free trial here.

As always, thank you to everyone who has reported issues, pushed back on early designs, and shared what their day-to-day requirements work actually looks like. The shape of this release is largely your work.
Questions or feedback? Join the conversation on our Community Forum or reach out at syside.support@sensmetry.com.