Disposition: Resolved OMG Issue No Clause Samples

Disposition: Resolved OMG Issue No. 11652 Title: Relax constraints on verify relationship

Disposition: Resolved OMG Issue No. 11490 Title: Requirements are abstract 1. Do SysML requirement construct need to be abstract? 2. Do SysML requirement constructs need subclasses? SysML does not currently support any form of sub-classing of requirements. 3. How robustly do SysML requirement constructs need to support properties? Are static properties necessary? One philosophy considers that if SysML requirements constructs 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 (sub- classing) 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. 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 sub-classing or properties in this revision of SysML. Separate issues could be raised for future revisions of SysML to consider adding requirements sub-classing or properties, ...