Topic
8 pieces.
Every model has one containment hierarchy, chosen for one purpose. Safety, security, thermal and certification scope all cut across it — and understanding why decides what your model can actually answer.
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.
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.
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.
A keyword that implies a type relationship turns your architecture model into something you can also reason over — cross-cutting classifications that inherit, and queries you could not otherwise write.
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.
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.
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.