SysMLv1: "Should" the 'subject' of a top-level UseCase be a System or (a particular) SystemContext? Answer: Which one would you like to be correct!? [WITH EXTERNAL LINKS]

Icon class
icon_class
far fa-sticky-note
icon_class_computed
far fa-sticky-note
Note kind
MODELLING
Specification keywords
SysML-1.6
SysML-1.7
UML keywords
UseCase
UseCase::subject
SysMLv1.x keywords
SysML Use Case Diagram
System
SystemContext
Keywords

Prove any claim you like to anyone you like about this 'subject' (oops pun), with these External links (please see grouped below right at the bottom of this page).

Visit also here on this Webel site:

Webel: SysMLv1: Overview of annotated Diagram Slides and Note pages related to UseCases and their combination with a System (of interest), SystemContext, and drill-down to scenario Sequence Diagrams (Interactions) and Activity Diagrams.
SysMLv1: MagicDraw/Cameo: Having a SystemContext as the 'subject' of each main UseCase plays nicely with the feature for automated creation of usage-level allocation swimlanes in SysML Activity Diagrams for part properties. But it's not the only way.
Webel: SysML for MBSE: The frequent recommendation that each UseCase have at least one "primary" scenario is a very useful and highly recommended CONVENTION (only). But it is not actually enforced by the SysML1.7 or UML2.5.1 metamodels or specifications.
SysMLv1: UseCase scenario representations: On use of Activity Diagrams with swimlanes and/or Sequence Diagrams (Interactions): Actor or block-based custom «actor» on 1st (typically left) Lifeline/Swimlane, System/Subsystem on 2nd Lifeline/Swimlane
SysMLv1: MagicDraw/Cameo: Synchronising ItemFlows on Connectors with ObjectFlows in Activities using the Item Flow Manager. Nice!
SysMLv1: MagicDraw/Cameo: INTRINSIC GOTCHA: Care must be taken with ownership of Activities used as UseCase scenarios vs the ‘subject’ of the UseCase. Make sure you don’t get an Activity ‘context’ mismatch! It's up to you to manage it as intended.
Webel: MBSE: SysMLv1: Prefer a custom «actor» extension of a Block (such as the non-normative External) over UML-style Actor for use as parts in IBDs and on allocation swimlanes. You can also have a Trace from a block-based «actor» to a UML-style Actor.
And remember always:
SysMLv1: A common misunderstanding: Just because a UseCase symbol appears inside the rectangle of a subject Classifier does NOT mean that it is owned by that Classifier and can only have that one Classifier as 'subject', and it does not imply ownership!
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.
Relates to
SysML/MBSE: Cameo/MagicDraw: MagicGrid® and the MagicGrid® Book of Knowledge: A pragmatic review of some selected aspects by Dr Darren of Webel IT Australia
Related notes
[MODELLING, TIP]{INFORMATIVE} 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.
[MODELLING]{INFORMATIVE} SysMLv1: A common misunderstanding: Just because a UseCase symbol appears inside the rectangle of a subject Classifier does NOT mean that it is owned by that Classifier and can only have that one Classifier as 'subject', and it does not imply ownership!
[MODELLING, OPTION, TIP]{INFORMATIVE} SysMLv1: MagicDraw/Cameo: Automated creation of usage-level allocation swimlanes in SysML Activity Diagrams for part properties of a Block. EXAMPLE: A UseCase scenario within a SystemContext as UseCase ‘subject’.
[CONVENTION, FEATURE, MODELLING, OPTION, TIP, TOOL]{INFORMATIVE} SysMLv1: MagicDraw/Cameo: Having a SystemContext as the 'subject' of each main UseCase plays nicely with the feature for automated creation of usage-level allocation swimlanes in SysML Activity Diagrams for part properties. But it's not the only way.
[GOTCHA, MODELLING, OPTION, TIP, WARNING]{INFORMATIVE} SysMLv1: MagicDraw/Cameo: INTRINSIC GOTCHA: Care must be taken with ownership of Activities used as UseCase scenarios vs the ‘subject’ of the UseCase. Make sure you don’t get an Activity ‘context’ mismatch! It's up to you to manage it as intended.
[MODELLING, TIP, TOOL]{INFORMATIVE} SysMLv1: MagicDraw/Cameo: Synchronising ItemFlows on Connectors with ObjectFlows in Activities using the Item Flow Manager. Nice!
[CONVENTION, MODELLING, OPTION, TIP]{INFORMATIVE} SysMLv1: UseCase scenario representations: On use of Activity Diagrams with swimlanes and/or Sequence Diagrams (Interactions): Actor or block-based custom «actor» on 1st (typically left) Lifeline/Swimlane, System/Subsystem on 2nd Lifeline/Swimlane
[CONVENTION, MODELLING, TIP]{RECOMMENDED} Webel: MBSE: SysMLv1: Prefer a custom «actor» extension of a Block (such as the non-normative External) over UML-style Actor for use as parts in IBDs and on allocation swimlanes. You can also have a Trace from a block-based «actor» to a UML-style Actor.
[CONVENTION, MODELLING, TIP] Webel: SysML for MBSE: The frequent recommendation that each UseCase have at least one "primary" scenario is a very useful and highly recommended CONVENTION (only). But it is not actually enforced by the SysML1.7 or UML2.5.1 metamodels or specifications.
Related notes (backlinks)
Related snippets (extracts)
  [UML-2.5.1] UseCase::subject : Classifier [0..*] ... The subjects to which this UseCase applies. Each subject or its parts realize all the UseCases that apply to it.
  [UML-2.5.1] A subject for a set of UseCases (sometimes called a system boundary) may be shown as a rectangle with its name in the top-left corner, with the UseCase ellipses visually located inside this rectangle.
  [UML-2.5.1] A UseCase may apply to any number of subjects. When a UseCase applies to a subject, it specifies a set of behaviors performed by that subject, which yields an observable result that is of value for Actors or other stakeholders of the subject.
  [UML-2.5.1] UseCases need not be owned by their subject.
  [UML-2.5.1] A UseCase may be owned either by a Package or by a Classifier. Although the owning Classifier typically represents a subject to which the owned UseCases apply, this is not necessarily the case ...
  [UML-2.5.1] Note that this notation for the subject classifier differs from the normal Classifier notation – it has no header or compartments.
  [UML-2.5.1] Note also that the subject rectangle does not imply that the subject classifier owns the contained UseCases, but merely that the UseCases apply to that classifier.
Visit also
UseCases - UML subject vs SysML Block
GOTCHA: UML Component «subsystem» vs non-normative SysML «subsystem»
Package, Model, or SysML Block as UseCase owner
Section: SysML-1.6 specification diagrams: 14 UseCases
Figure D.5 - Establishing Top Level Use Cases for the Hybrid SUV
Figure D.6 - Establishing Operational Use Cases for Drive the Vehicle
Visit also (backlinks)
External links
UML Profile: Use Case Specification for SysML Version 1.0 (2017), Raiiv Murali …