SYSML21 — Satisfy requirement with no require constraint usages

What does it mean to satisfy a requirement if the requirement does not contain any constraints?

In the SysML 2.0 specification, 7.21.1, the statement is made that "A requirement definition is a kind of constraint definition (see 7.20 ) that specifies stakeholder-imposed constraints that a design solution must satisfy to be a valid solution. A requirement definition contains one or more features that are constraint usages designated as the required constraints." However, a requirement that does not own any required constraints can be legally created since the multiplicity of requiredConstraint specified in 8.3.21.8 is 0..*, rather than 1..*. Is the description in 7.21.1 incorrect? Or is the multiplicity in 8.3.21.8 incorrect?

Furthermore, 7.21.1 later states that, "A satisfy requirement usage is a kind of assert constraint usage (see 7.20 ) that asserts that a requirement is satisfied when a given feature is bound to the subject parameter of the requirement." What does this statement mean when the requirement element does not have any owned required constraints? E.g., the requirement element has no owned features other than: doc /* The system shall comply with all applicable certification regulations.*/ What does it mean to "assert that the requirement is satisfied" in this situation?

Essentially, the questions this issue seeks to address are:

1) Is a requirement definition or usage allowed to have no required constraints? (7.21.1 says no but 8.3.21.8 says yes.)

2) If so, what does the satisfy requirement usage mean when the requirement has no required constraints? Is it an assertion that the requirement has, indeed, been complied with? Or is it an assertion of intent, i.e., allocation?

3) If a requirement has no required constraints, should the allocation of the requirement to another element (e.g., part, action, etc.) intended to realize that requirement be modeled by an allocation usage rather than a satisfy requirement usage, or are both approaches legitimate but have different (or the same) semantics at M0? 7.15 does not provide any discussion or example of the use of allocation for requirements, and 7.21 does not indicate that allocation should be used to express intent rather than compliance. If allocation should be used for this purpose, some discussion of this and an example should be provided in 7.15 and it should also be mentioned in 7.21.

While SysML v2 has mainstreamed the property-based requirements paradigm, many real-world requirements will be needed that cannot really be modeled by mathematical constraints or evaluated in the model and will not have any explicitly defined require constraint usages unless this is mandatory for the model to be valid.

A consistent mechanism for modeling the allocation of these requirements to other elements and for interpreting the distinction between "satisfy" and "allocate" in this requirement context is a critical need for the SysML v2 user community.