What’s new in SysML 1.5 – Requirements modeling

This post is the second part of the blog post series about the changes of SysML 1.5.

The biggest novelty in SysML 1.5 is only visible on the second view. If you do not use the new feature, you will not recognize it. Since version 1.0 SysML provides the model element Requirement to model text-based requirements, it has only two properties: one to specify the ID of the requirement and another one for the requirement text. SysML intends that modelers can define additional requirement properties and taxonomies by subclassing the SysML

SysML intends that modelers can define additional requirement properties and taxonomies by subclassing the SysML Requirement stereotype. For example, the requirement taxonomy of the SYSMOD MBSE methodology depicted in the following figure:

SYSMOD Profile: Requirements Taxonomy

SYSMOD already has defined what is now part of the new SysML 1.5. Any model element that has a name (=NamedElement) could represent a requirement. For example, a constraint, a block with value properties, or a behavior element like a state machine or activity, or parts of them. In SYSMOD the stereotype ExtendedRequirement redefines the extension of the metaclass Class by the SysML Requirement stereotype and extends the metaclass NamedElement.

The following figure depicts the old SysML 1.4 definition of the Requirement model element:

SysML 1.4 Requirement Definition

The next figure depicts the new definition of the Requirement model element in SysML 1.5

SysML 1.5 Requirement Definition

The Requirement model element is still the same as in SysML 1.4. Although all features are now inherited from the new abstract stereotype AbstractRequirement, if you do not want to use the new feature or if you have already modeled requirements with SysML 1.4 or older versions, nothing changes for you as a model user or builder. Of course, the tool vendors of SysML modeling tools must update to the new requirement definition.

However, if you define your subclassed requirement stereotypes, as shown above, you can now subclass the new abstract stereotype AbstractRequirement instead of the stereotype Requirement. The AbstractRequirement has all features of the SysML 1.4 Requirement, but it now extends the metaclass NamedElement instead of Class and it does not have any constraints. All the requirement constraints like that a requirement shall have no properties or generalization relationships are defined at the old and still existing concrete stereotype Requirement. It is one (standardized) example of how to define a requirement model element. You can now create your subclasses of the stereotype AbstractRequirement without being limited by the strong SysML 1.4 requirement constraints. For example, a performance requirement element that can define value properties for the requested performance conditions like maximum weight or duration.

For the next version of the SYSMOD profile, I will update the requirement taxonomy accordingly.

This was the second part of blog post series about changes in SysML 1.5. Soon I will publish the third and final part about some minor miscellaneous changes in SysML 1.5.