It is not enough to refer simply to (p.180):
'The «system» and «external» stereotypes are user defined, not specified in SysML,'
Although already raised as Issue 12257, this new Issue submission (by a different submitter) makes the constructive suggestion that the 'user defined' stereotypes by defined in non-normative extension Section in the Annex C.
It is not acceptable that a specification dedicated to systems engineering does not even have at least a well-defined non-normative definition of a <<system>> and <<system context>> ! These need to be upgraded to a non-normative Annex, and then introduced properly through the example.
I see no reason why the figures should not use non-normative stereotypes as long as they are defined in an Annex and clearly. This is not the case for:
<<system context>>, <<system>>, <<external>>, <<domain>>, <<subsystem>>,
yet these are truly crucial for even basic systems engineering, and the examples (which use them well) make little sense without them.
There is a very nice summary of C.2 Requirements Diagram Extensions. and those requirement categories have proved very useful already.
I have made a small summary and guide here:
Block extensions (non-normative)
As recommended through SysML1.0 examples:
- «system» top-level block to be used in a system context
- «subsystem» grouping (usually physical) within a system
- «external» outside the top-level system (yet affecting it)
- «domain» provides a common context for a system and externals
- «system context» a particular context for a system and externals
Note my definitions for <<domain>> vs. <<system context>>.
I suggest that at least «system context» should have an attribute:
system:<<system>>[1]
<<domain>> could then extend <<system context>>.