SYSML11 — Requirements are abstract

Requirements are abstract (isAbstract must be true). However name of the requirement are not displayed in italic as defined in UML notation

(This discussion is elaborated from RTF Telecon Minutes 2008-02-13 &
2008-02-13)
This issue asks that the name of a requirement be in italics, in keeping with the rules on UML classes when isAbstract is True. This raises the following questions:
1. Do requirements need to be abstract? In order to answer this, we need to address the following.
2. Do requirements need subclasses? SysML does not currently support any form of subclassing of requirements.
3. How robustly do requirements need to support properties? Are static properties necessary?
One philosophy considers that if requirements had any features such as properties, they could be only static features that applied to the entire requirement class and not to any instance, which was part of the rationale for the isAbstract = True constraint.
If static properties were supported on SysML requirements, along with adding specialization (subclassing) relationships between requirements, they could support a more complete form of property-based requirements in addition to their current support for text-based requirements. This would more closely parallel the requirements capability in STEP AP233, which has support for both text- and property-based requirements. It would also allow performance requirements to be stated by defined property values that could participate in parametrics or other analysis.
In the original submission, however, the SysML model of requirements has been left deliberately simple without further detail for modeling the system itself, in part so SysML would more closely match the scope and structure of typical requirements specifications which have simple containment models of text-based statements. Associating properties with requirements relied on linking requirements to highly abstract models of system structure, built using SysML blocks, and providing a skeleton model of system structure to which properties would belong. This is appropriate because the properties are typically of the system, rather than of the requirement, e.g. "the car shall weigh less than 3000lb" implies that weight is a property of the car. This approach also provides a more extensive means to capture properties and other details of an evolving system very early in its specification process. This option remains available in SysML to model greater detail about requirements that need to go to a greater level of detail or precision.
This remains a clear and consistent approach to SysML requirements, and should not be reconsidered at this time. The decision of this resolution is not to add any additional support for requirements subclassing or properties in this revision of SysML. Separate issues could be raised for future revisions of SysML to consider adding requirements subclassing or properties, but such an addition is outside the scope of this issue, which seeks only to make the font of requirement names consistent with the isAbstract attribute.
Given the lack of subclassing for SysML requirements, the constraint on isAbstract has no added semantics and could be constrained either way. The main issue at this point is simply whether the names of requirements should be in italics or not. Forcing the names into italics, to be consistent with the current constraint, would change the notation defined by the current specification and used in all the current requirements examples. Removing the current constraint will allow tools to keep the name consistent with the setting of the isAbstract attribute. The same resolution should apply to Viewpoint in Chapter 7, which has the same constraint on the isAbstract attribute.