SYSML21 — Requirement constraint members should not be composite

In 8.3.21.7 RequirementConstraintMembership, the constraint validateRequirementConstraintMembershipIsComposite requires that the ownedConstraint of a RequirementConstraintMembership be composite. However, consider the following:

part p {
    constraint c;
}
requirement r {
    subject :> p;
    require p.c;
}

In this case, the constraint c is composite in p, but the required constraint referencing p.c is composite in r. Further, checkConstraintUsageCheckedConstraintSpecialization requires that c subset Part::checkedConstraints, which indirectly specializes Object::ownedPerformances, and, therefore, so does the required constraint referencing p.c. But checkConstraintUsageRequirementConstraintSpecialization requires the required constraint to specialize RequirementCheck::constraints, which (as a composite constraint usage) indirectly specializes Performance::subperformances. Thus, the required constraint inherits from both ownedPerformances and subperformances, which is inconsistent (in particular, this is bound differently in the two features).