Composite (a.k.a. "compound") Requirements

The composite requirement or compound requirement concept is very powerful, and something you are very likely to use on a real project. Please note first that:

SysML-1.6: Refers to both 'composite requirements' and 'compound requirements' (clearly as identical concepts)

Click on the image to view it full size

The spec explains:

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'

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.'

Concerning the tool:

MagicDraw/Cameo does not explictly support tracking of satisfaction and verification of composite/compound requirements, but the "implied relations" facility can help.

In Webel Best Practice this is formalised through an additional custom stereotype that also helps support the implied relations facility in the tool:

Webel Best Practice: 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.

One may wish to re-use a Requirement that is a child of one composite requirement in another composite requirement, but a Requirement can only have one owner. We see next how the Copy relationship can help us out.

Up next

The Copy relationship

Notes

[ISSUE] SysML-1.6: Refers to both 'composite requirements' and 'compound requirements' (clearly as identical concepts)

[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

Snippets (quotes/extracts)

[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

[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] 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.