SysML v2: Text notation as a bridge to requirements?

The text notation of SysML v2 creates enthusiasm. People who like to work with code will immediately feel at home. Models can be read linearly or processed automatically. Nevertheless, we do not want to formulate requirements in SysML v2 text notation, as the majority of stakeholders would reject this.

Nevertheless, there is potential at precisely this point. The following is about:

• Text notationSysML v2 turns models into code, but most stakeholders still want requirements in plain text.
• Requirements ↔ ModelsOSLC and ReqIF create links, but real bidirectionality is missing.
• Text templatesEARS & INCOSE offered precision, but failed in terms of usability; modern tools shine with UX, not with formal semantics.
• AI4MBSEOne result of this project is the coupling of RE tools via AI to SysML v2 with almost automatic traceability.
• Added value SysML v2DevOps-capable text notation, REST API for open integrations, KerML semantics for consistent checks.
• OutlookSysML v2 can close silos, but only with AI, open API and better UI will MBSE be suitable for mass use.

Requirements and models - still two worlds apart

It is astonishing how wide the gap between requirements management and MBSE still is. The most common integration paths are OSLC or ReqIF. Both have their weaknesses and neither scales particularly well: links break, versions diverge, reviews are frustrating. In practice, it is clear that traceability is promised but rarely practiced.

A common misconception is that "integration" is enough. In fact, added value is only created when changes flow in both directions: Requirement changes model, model changes requirement - and preferably without manual synchronization. This is precisely where SysML v1 failed, especially the XMI format, which was supposed to ensure secure data exchange.

Text templates as a bridge to models?

In the 2010s, it was hoped that EARS- or INCOSE stencils precision. The idea was good, but acceptance was mixed: too rigid, too theoretical, too little immediate benefit. Usability was a major problem. Modern tools like Flow Engineering or Valispace solved by a better UI. However, they deliberately do without a formal language such as SysML. This becomes a problem at the moment when internal stakeholders would like to fall back on a standardized, semi-formal notation.

A new approach comes from Itemis. In the context of AI4MBSE the company has established an end-to-end tool chain: An extension in the RE tool makes pattern templates and AI auto-completion visible, while a SysML v2 service transforms the sentences into model elements in the background. A second service reconciles model changes and proposes new requirements.

The result is largely automated traceability virtually in real time. A controlled vocabulary is clearly mapped to SysML v2. This means that every record template ends up directly as a formalized requirement in the model and vice versa. At least in theory, as presented in the white paper. A prototype implementation is available for DOORS Next and Jama.

What else SysML v2 could offer

There are three further aspects of SysML v2 that affect the linking of requirements and models:

DevOps workflow: Text notation places models in the same workflow as source code: Models can be merged and diffed in textual form. This applies not only to block or interface definitions, but also explicitly to the underlying requirements if these are part of the model. If a "shall" formulation changes, the difference immediately appears in the Git diff; a pull request therefore combines model and requirements review in one step.

Reservation: SysML v2 in text form should not be committed to a git repository without further ado.

REST-API: The standardized REST API ensures that both traditional RM tools and AI services can tap into the model without proprietary adapters. This allows requirements from DOORS Next or Jama to be synchronized bidirectionally, while an LLM simultaneously closes semantic gaps or suggests new requirement candidates.

Reservation: Here too, opinions differ as to whether a REST API is the right way to go for complex integration.

Formal KerML: SysML v2 is based on consistent, formal semantics, enabling formal analyses of model and requirements in a single metamodel. Consistency rules now not only check whether ports are connected, but also whether each model change is covered by a valid requirement. In this way, traceability is not documented retrospectively, but is continuously enforced and made visible.

Reservation: In practice, the cost-benefit ratio of formal modeling is not always given and requires a high up-front investment.

One foot in two worlds

SysML v2 could become an important tool for reducing the separation of model and requirements. The success of AI in particular, combined with the attention that SysML v2. is currently receiving, could result in interesting new solutions. And for teams with an established tool landscape in particular, this could open up a step-by-step path.

But: As far as usability is concerned, SysML v2 tools have so far lacked the usability that we see in modern SaaS tools of the 2020s (apart perhaps from Dalus) It will be some time before native SysML v2 editors offer the same ease of use. Only time will tell whether SysML v2 will prevail or whether a startup will conquer the market with a completely new model.

What does this mean at the end of the day? Text notation is only half the battle. Only the interplay of bidirectional traceability, open API and AI assistance will make MBSE suitable for everyday use. Those who take this to heart will transform model and requirements engineering from two silos into a continuous, adaptive engineering flow and bring SysML v2 from an expert tool to the heart of the team.

Photo by Manuel Mnvx on Unsplash