Figure B.11 - Establishing HSUV Requirements Hierarchy (containment)

My experience is that these kinds of containment diagrams are not graphically robust. For large numbers of requirements they become very difficult to manage. Typical graphical problems include:

If one moves a parent (owner) the children do not move with it
One has to use tedious multi-selects to move sub-trees.
The children graphically expand sideways to cover other unrelated elements or become visually
aligned under unrelated parents (see for example Braking under Eco-Friendliness)

For alternatives consider non-standard SysML strategies such as:

EITHER wrap requirements parasitically in UML Components that logically and graphically group elements
OR apply <<requirement>> stereotypes to UML Components instead of Class elements

These alternatives are illustrated in the following diagrams.

Figure B.11a HSUV Requirements: Alternative: use <<containment>> wrapper Components

In MagicDraw one can use Components as logical and graphical wrappers WITHOUT STEALING OWNERSHIP by placing a Component in the diagram and moving other elements into it. This is effective technique for organising diagrams. Since in this example the «requirement»s are organised by containment, the wrapper Components have been stereotyped as «containment» wrappers.

While this is already more graphically stable and the concepts better quarantined than the previous diagram using only containment operators, it does requires some extra work. See however next how to apply «requirement» directly to a Component (non-standard).

Figure B.11b HSUV Requirements: Alternative: stereotype UML Components as SysML <<requirement>>s (non standard)

Since a UML Component is a Class it can be stereotyped by the SysML «requirement» stereotypes. This yields very graphically robust requirements diagramming and organisation. Although not official SysML it works very well in the MagicDraw SysML Plugin. In fact this is how I use SysML requirements for all of my "feature-oriented" developments ! You can even use a «feature» stereotype, where Features «satisfy» Requirements SysML-style ! Include hyperlinks directly from your MD SysML requirements model to the entries of an issue-tracking system like JIRA and you have a very powerful requirements and feature tracing system. This really works !