SysML/MBSE: Many videos, tutorial slides, and guides to MBSE with SysML present particular modelling recipes as though they are THE way to do something in SysML, not just ONE way of doing it in SysML. They are not necessarily enforced by the SysML spec.

Icon class
icon_class
far fa-sticky-note
icon_class_computed
far fa-sticky-note
Note kind
Policy level
Specification keywords
Keywords

One of the hardest things for those new to SysML and SysML tools is that there are so many different ways of achieving the same thing using the underlying SysML language. This is a good thing! SysML is a set of MBSE "building blocks" (only), and over-specifying "THE" way of doing everything would not permit its flexible use for so many different tasks and for so many different domains. Besides, many modellers find a pet way that works well for them.

Always check first whether some is enforced by the SysML spec, both the metamodel, and the constraints (some of which are in natural language not OCL). In the case of SysMLv1, this means often also checking whether something is enforced by the UML2.5.1 spec, and beware also that SysMLv1 extends UML2.5.1 metaclasses and stereotypes and adapts them.

Then check also whether practice shown to be THE way is associated with particular additional systems engineering methodology.

In some tools use of additional custom validation engines may give the impression that an enforced modelling practice or modelling constraint is directly part of SysML when it is not.

The Webel Best Practice go beyond SysML and the policies and modelling recipe tips carry various recommendation strength levels.

Some examples of SysML modelling choices

If you are using MagicDraw/Cameo, and especially if you are using the MagicGrid, I'd suggest indeed go with that.

But there's no reason that UseCases with the System directly as 'subject' can't handle multiple systems context descriptions at once; from the point of view of the System it can handle all scenarios thrown at it (by different SystemContext IBDs), and subsets of its UseCases may address various system contexts via its scenarios.

Compare for example with the SysMLv1 spec HSUV sample problem, which uses the System as the 'subject' of the top-level UseCases. Do you like going down rabbit holes?

Here's one that is basically the de facto, but it's no more authoritative than the English left-to-right writing systems is compared with the Arabic, Hebrew, and Persian right-to-left writing systems:

This one is definitely common sense, a UseCase without at least one scenario drill-down Diagram is not much use for MBSE, but it's not a "fact" of SysML:

Visit also:

Relates to
Related notes
Related notes (backlinks)
Related snippets (extracts)
Visit also
Visit also (backlinks)