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)

This recommendation departs significantly from the practice you see in most examples elsewhere.

It addresses two concerns at once:

1. Con: If you use both the Requirement element 'name' and the 'text' they can get out of sync! It breaks the Single Source of Truth (SSOT) and Don't Repeat Yourself (DRY) principles.
2. Con: When you "call-out" information on Satisfy and Verify relationships with Requirements as the target, if the Requirement does not have a verbose name it is often not informative (but if you do make it verbose enough to be informative it may "compete" with the 'text' field, breaking SSOT).

This recommendation here to use verbose Requirement names applies to "leaf" Requirements, not to composite (a.k.a. compound) requirements, noting that a Requirement may act as a Namespace and owner of other Requirements.

For a composite Requirement, a very concise name may be sufficient (and again, no 'text', unless you are using it for elicitation of the child requirements). In such cases, Webel recommends application of an explicit additional custom «requirementsGroup» stereotype.

The reality is, the Requirements system in SysML works brilliantly together with model-based engineering (other technologies don't) and the tool support for it is excellent.

The recommendation to use verbose names is not, however, without its drawbacks:

• Con: Very long element names can sometimes make dependency matrices hard to read.
• Con: Some people (who have not read this page from top to bottom) may tell you that "you are doing it the wrong way" without considering the subtle pros and cons.

Another possibly good excuse for rejecting this recommendation here is that you wish to use this nice feature of MagicDraw SysML Plugin and Magic Cyber-Systems Engineer ^® (Cameo Systems Modeler^®): But you'll need to check them anyway, the language and maths parsing is pretty good, but not perfect.