SysML v2 Requirement Verification: From Satisfy Claims to Automated Checks

Pull up a SysML v1 model from any mature program and count the «satisfy» dependencies. Hundreds, usually. Now ask what each one actually proves. The honest answer is nothing. A satisfy arrow in v1 is a bookkeeping entry: somebody, at some point, decided this block is responsible for that requirement. Whether the block really meets it lives in a test report, a spreadsheet, or an engineer's head. SysML v2 changes what that arrow can mean, and that change is the most underrated part of the language.

A satisfy in v2 is a claim, not a link

In SysML v1, a satisfy relationship is a dependency between two elements. It has no evaluable content. In SysML v2, a satisfy requirement usage is itself a requirement usage: it binds the requirement's subject to the enclosing part and asserts that the requirement's constraints must evaluate to true for any legal instance of that part. Sensmetry's Advent of SysML v2 series puts it plainly: a satisfy in your model is a claim that a component meets a requirement, and the point of writing requirements as formal constraints is so that claim can be checked.

That distinction matters more than it sounds. Because a v2 requirement is, at bottom, a constraint definition with a subject, and because satisfy binds a concrete subject to it, you now have three things in one place: the condition, the thing being held to it, and an assertion connecting them. A checker can walk from a part definition, find every satisfy usage inside it, resolve the subject, and evaluate the assume and require constraints against the actual attribute values in the model. Sensmetry's example script does exactly that, checks assumptions first (if they fail the requirement doesn't apply), evaluates the require constraints, then recurses down subrequirements so a parent only passes when all its children pass.

The difference from v1 is not that you couldn't write a script against a v1 model. People did. The difference is that in v1 the script had to invent the semantics: what "satisfies" means, where the values live, how decomposition rolls up. In v2 the language defines it, so different tools can agree on the answer.

What the language actually gives you

Three constructs do most of the work, and it's worth being precise about them.

• Requirement definitions and usages with constraints. A requirement carries assume constraint and require constraint bodies written in KerML expressions over the subject's attributes. "Cockpit volume shall be at least three times Santa's volume" becomes an expression, not a sentence.
• Satisfy requirement usages. These sit inside the part (or action, or item) that claims to meet the requirement and bind the subject. They can carry a doc comment explaining why the claim holds, which is useful when satisfaction isn't obvious from the numbers alone.
• Verification cases and analysis cases. A verification case is a specialization of the general case concept whose objective is to establish whether a requirement is met, with a verdict as its result. An analysis case is the same idea aimed at producing analysis results rather than a pass/fail verdict. Both are first-class language elements, not profile stereotypes.

The point of having all three is that they cover different evidence sources. Constraint evaluation works when the numbers are in the model. Analysis cases cover the situations where they aren't, where you need a simulation or an external solver to produce the value that then gets compared. Verification cases give you the container that says "this is the procedure that verifies requirement X" and the slot for the verdict, whether that verdict came from an expression, an analysis, or a physical test.

Where the tools are in 2026

Vendors have been building around exactly this loop, and the products are at different depths.

Ansys System Architecture Modeler (SAM) 2026 R1, released in March, added language support for VerificationCase and AnalysisCase, and its headline feature was tighter integration with ModelCenter: SysML v2 expressions defined on attribute usages and requirements can be evaluated automatically from the ModelCenter interface, without scripting, with results written back into SAM and displayed as requirement verification status tables. That's the "external analysis feeds the verdict" path made concrete. The same release added bidirectional requirements exchange with DOORS NG and Codebeamer, which matters because most programs still hold the authoritative requirement text outside the architecture model.

Sensmetry's Syside takes the model-native path. Its Automator scripting lets you walk the model and evaluate constraints directly, and the company positions this as something that belongs in CI: every commit re-verifies every satisfy claim and fails the pipeline on a regression.

Other tools with SysML v2 requirement support handle the pieces at varying levels of completeness. Dassault's CATIA Magic (Cameo) 2026x has v2 support alongside its established v1 requirement verification tables. Eclipse-based environments like Capella don't speak SysML v2 natively but cover the satisfy-and-verify traceability pattern through their own metamodel and the Requirements viewpoint add-on. Dalus is a SysML v2-native platform that models requirements, satisfy usages, and verification cases per the specification. The open-source SysML v2 pilot implementation from the OMG remains the reference for what the language semantics actually require, and it's still the place to check when two commercial tools disagree.

The honest summary: constraint evaluation against model values is now available in several tools. Automated round-tripping between a verification case and an external simulation or test bench is available in one or two, and in each case it's tied to that vendor's own analysis stack.

The practical workflow

Teams that have made this work tend to converge on the same pattern.

1. Write the requirement twice. Keep the prose for humans and stakeholders. Add the require constraint for the machine. The prose goes in a doc block on the same requirement so they can't drift apart without someone noticing.
2. Close parameters at the definition level. A parameterized requirement ("mass shall be under maxMass") should be specialized with concrete values before it's satisfied, so the satisfy usage only binds the subject. Otherwise the concrete numbers scatter across usages and you lose the one place to look.
3. Put satisfy usages where the design decision lives. If a cargo bay variant meets a capacity requirement, the satisfy belongs on that variant's part definition, not on the top-level system. That's what makes variant-by-variant verification possible.
4. Run verification on every model change. Not before reviews. Every change. The value is catching the cockpit-volume edit that broke a requirement three levels up, the same day it happened.
5. Use analysis cases for anything a constraint can't compute. Thermal margins, structural loads, link budgets. Model the case, connect it to the solver, and let the result flow into the verification case verdict.

What it won't solve

Now the trade-offs, because there are real ones.

It only verifies what you can formalize. "The user interface shall be intuitive" has no constraint expression. Neither do most safety requirements at the hazard level, or anything that depends on operational context. Expect a meaningful fraction of your requirements, often the ones people argue about most, to stay outside the automated loop. Verification cases can still track them, but the verdict comes from a human.

Model values are not measured values. Evaluating a constraint against cockpit.volume = 500 L proves the design intent is consistent. It doesn't prove the built cockpit is 500 liters. Closing that gap means feeding test data into the model, and while research on direct model-to-hardware verification interfaces exists, production tooling for it is thin. For now most teams record test verdicts into verification cases manually or through a custom import.

Tool interoperability at the verification layer is unproven. The language is standard. Whether a verification case authored in one tool, with results attached, opens cleanly in another with the verdicts intact is a question the community hasn't answered with much production evidence yet. The API and textual notation help, but the analysis-integration half is vendor-specific by construction.

Formal constraints cost modeling time. Someone has to write them, review them, and maintain them as requirements change. On a program with thousands of requirements, that's a staffing decision, not a checkbox. Teams that try to formalize everything at once tend to stall. Teams that formalize the quantitative, high-change requirements first tend to see payoff.

Certification credit is not automatic. A green verification table in a modeling tool is evidence, not qualification. Regulators and certification authorities will still want the argument that the tool's evaluator is trustworthy and that the model values trace to reality.

The bottom line

SysML v2 turns the satisfy relationship from a trace link into a testable assertion, and 2026 tooling has caught up enough that constraint-based requirement verification against model values is a working feature rather than a demo. Start there: formalize the quantitative requirements, put satisfy usages on the parts that actually make the design decision, and run the check on every change. Treat external analysis integration and test-data round-tripping as the next step, not the first one, and keep a clear line in your process between "the model is self-consistent" and "the system has been verified." The language finally lets you say both precisely. It doesn't let you confuse them.