Icon class icon_class fas fa-quote-left icon_class_computed fas fa-quote-left Related content Figure D.11 - Establishing HSUV Requirements Hierarchy (containment) 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. SysML-1.6: 'Figure 16-2: Requirements Derivation' indeed shows DeriveReqt but spec text refers to it only as 'an example of a compound requirement' Figure 16-2: Requirements Derivation Figure 16-5: Use of the copy dependency to facilitate reuse SysML-1.6: Refers to both 'composite requirements' and 'compound requirements' (clearly as identical concepts) Composite (a.k.a. "compound") Requirements MagicDraw/Cameo does not explictly support tracking of satisfaction and verification of composite/compound requirements, but the "implied relations" facility can help. Source OMG Systems Modeling Language (SysML) 1.6 Copyright information About Object Management Group copyright in text extracts quoted from OMG specifications for educational purposes Snippet kind INFO UML keywords Class SysML keywords Requirement «system» AbstractRequirement composite (compound) requirement Keywords requirements engineering Previous snippet A requirement is a stereotype of both Class and Abstract Requirement. Full quote Compound requirements can be created by using the nesting capability of the class definition mechanism. Next snippet 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. Related snippets A requirement specifies a capability or condition that must (or should) be satisfied. Related snippets (backlinks) 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. 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 An entire specification can be decomposed into children requirements, which can be further decomposed into their children to define the requirements hierarchy. The use of namespace containment to specify requirements hierarchies precludes reusing requirements in different contexts since a given model element can only exist in one namespace. Visit also Visit also (backlinks) Flags
