Four Ways to Constrain an Action in SysML v2
A use case tells you whether a step happened. Constraints are how you say how well it was performed — and there are four places a constraint can read from, only one of which needs an output parameter.
Topic
Requirements
6 pieces.
Nominal, Alternate, Exception: Routes a Model Works Out for Itself
A derived state machine arrives already colored by route — green, blue and red. Only one thing in the source model was ever annotated. Here is how the other two colors are computed, and why the stamps that carry them are deliberately not semantic metadata.
Performance, Safety and Security Constraints in SysML v2
How fast, how safe, how protected — none of it comes out of a behavioral model, and it shouldn't. Here is the vocabulary for writing those constraints so they are worth having.
Modeling a Verifiable Use Case
How to write a SysML v2 use case so that requirements and verification cases can be derived from it — and so that what comes out can actually be tested at the boundary.
The Derivation Ladder
Eighteen constructs, added to a use case one at a time, and exactly what each one turns into downstream. The map nobody prints, with the real numbers attached.
From Behavior to Proof
A model can be turned into requirements automatically. Making those requirements testable is a different problem — and the answer starts by asking what you could actually see from outside the box.