SysML: Webel recommends use of an additional custom «requirementGroup» stereotype for compound Requirements that serve as owning Namespaces and are subject to the satisfaction policy that all child requirements must be satisfied.

Icon class
icon_class
far fa-sticky-note
icon_class_computed
far fa-sticky-note
Note kind
TIP
Policy level
SUGGESTED
UML keywords
Stereotype
«keyword»
SysMLv1.x keywords
Requirement
composite (compound) requirement
A Stereotype RequirementGroup with a keyword «requirementGroup» can be introduced to formalise:
UML-2.5.1: 'The default interpretation of a compound requirement, unless stated differently by the compound requirement itself, is that all its subrequirements shall be satisfied for the compound requirement to be satisfied.'
Amongst other things, this can help you search for such elements and helps you leverage the implied relations facility.
UML-2.5.1: 'MagicDraw/Cameo does not explictly support tracking of satisfaction and verification of composite/compound requirements, but the "implied relations" facility can help.'
Relates to
Figure D.11 - Establishing HSUV Requirements Hierarchy (containment)
Figure 16-2: Requirements Derivation
Composite (a.k.a. "compound") Requirements
Related notes
[TIP, TOOL] MagicDraw/Cameo does not explictly support tracking of satisfaction and verification of composite/compound requirements, but the "implied relations" facility can help.
[CAPABILITY, FEATURE, TOOL] Magicdraw/Cameo has a powerful "implied relation" facility for use in query tables, dependency matrices, and as element properties
[NAMING, POLICY]{SUGGESTED} Webel suggests using a verbose 'name' for leaf (child) Requirements but NO 'text' to prevent Single Source of Truth issues and for improved callout vs relationships (but this might not always work when syncing with external requirements management tools)
Related notes (backlinks)
Related snippets (extracts)
  [SysML-1.6] Compound requirements can be created by using the nesting capability of the class definition mechanism.
  [SysML-1.6] The default interpretation of a compound requirement, unless stated differently by the compound requirement itself, is that all its subrequirements shall be satisfied for the compound requirement to be satisfied.
  [SysML-1.6] When a requirement has nested requirements, all the nested requirements apply as part of the container requirement. Deleting the container requirement deleted [deletes] the nested requirements, a functionality inherited from UML.
  [SysML-1.6] A composite requirement can contain subrequirements in terms of a requirements hierarchy, specified using the UML namespace containment mechanism. This relationship enables a complex requirement to be decomposed into its containing child requirements.
  [SysML-1.6] A composite requirement may state that the system shall do A and B and C, which can be decomposed into the child requirements that the system shall do A, the system shall do B, and the system shall do C
Visit also
Visit also (backlinks)