Webel: SysMLv1: Functional analysis (isolation of white-box Activities identified via «blackbox» scenario Activities of UseCases). Recommend custom stereotype them. Candidate: «whitebox» (or a recommended SE methodology stereotype).

The umbrella term functional analysis is rather over-loaded, and different terms are used in various formal SE methodologies. Here it means simply the identification of white-box Activities as usages (the 'behavior') in CallBehaviorActions in higher level black-box scenario Activities related to UseCases.

Webel recommends custom stereotyping the Activities that are identified as white-box (as opposed to black-box) as soon as possible. There are many candidates, just «whitebox» as a keyword is fine. Some formal SE methodologies already have a recommended stereotype for them, if you are using one of those, by all means use that. And, due to the wonders of SSoT, you can always change it later and it propagates throughout your SysML model. The main thing is that you do it all.

In the Webel approach to SysML modelling, we try to use more forgiving logical strategies, and not rely on ownership structure too much. Yes, you can group your white-box Activities under a Package hierarchy whitebox the functional-analysis or such, and then you could show the 'owner' of an Activity on a supporting Diagram (in SysMLv1 one can show an Activity symbol on a BDD), but that's not alone very flexible.

Just query on «whitebox» in a query view table for Activities! Easy peasy.

If you have ever been tempted to ignore the formal SE recommendation of using at least one intermediary logical handler Block (aka logical subsystem or conceptual subsystem) with complex scenarios and want to just "jump" straight straight down to your design layer, please do read this:

HOWTO "cheat" with two-level white-boxing and tracking stereotypes because you just don't want that darn "extra" logical subsystem (conceptual subsystem) Block the systems engineers reckon you are supposed to use (and why it's easier to actually use one)

The Webel recipe for pragmatic SE with SysML use special terminology for «whitebox» logical drill-down:

[STUB] TRAIL: Webel's ultimate guide to simplified yet adequate pragmatic systems engineering with functional analysis in SysMLv1 for smaller scale MBSE projects in the MagicDraw/Cameo/CATIA Magic tools

Webel Best Practice: Webel: SysML: SE: Stereotype keyword convention: BY DEFINITION HERE «blackbox» and «whitebox» refer specifically to the 'problem' zone and NEVER the 'solution' zone (as opposed to more general uses of the terms 'black-box' and 'white-box').

Webel Best Practice: Webel: SysML: SE: Naming convention: «whitebox»: A '$' prefix indicates a «logical» system, «logical» subsystem (aka conceptual subsystem) or «logical» handler Block (which is a more specific form of «logical» subsystems Block).

Webel Best Practice: Webel: SysML: SE: Terminology: '«logical» handler' is used for a specific kind of «logical» subsystem (aka 'conceptual subsystem') that is a SPECIFIC collaboration of parts that handle one Activity usage in a higher level «whitebox» Activity.

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

Webel SE: pragmatic tool-friendly functional analysis: 2-level drill-down from a single Use Case via a «scenario» Activity with allocation to «logical» subsystems first then crossing to the «design» Blocks zone.

Related notes