The non-normative extended requirements

Click on the image to view it full size

The non-normative SysML ExtendedRequirement keywords are: «extendedRequirement», «functionalRequirement», «interfaceRequirement», «performanceRequirement», «physicalRequirement», «designConstraint».

For good measure the Requirements Plugin for MD SysML Plugin and Cameo Systems Modeler® throws in: «usabilityRequirement» and «businessRequirement».

If you just want to get at the verifyMethod:VerificationMethodKind and risk:RiskKind goodies, you can create an «extendedRequirement» directly in the tool.

Think that the RiskKind is not risky enough for you? Just roll your own extension of AbstractRequirement (or ExtendedRequirement). Easy!

What is not so easy, however, is creating validation rules for custom requirements. These ones with non-normative SysML rules have good tool validation support (and if you extend them, you get their validation rule support for free if they suit you):

But then there's this one:
The practical meaning of the constraint on «physicalRequirement» or how it should be validated in a tool is not so clear.
For more details see Table E-3: Additional Requirement Stereotypes in the SysML-1.6 spec.

The source:String is (just) better than nothing, you could put a URL/URI in there if you wanted, but it does not compare with the power of the  Webel Parsing Analysis recipe for SysML®.

Since the SysML-1.6 specification in its wisdom currently excludes the UML Artifact, you can't directly do the most obvious thing, which is reference an Artifact that represents a source document from which your extended requirement was gleaned. But you CAN easily do that yourself if you extend an ExtendedRequirement:

That one criticism aside, the non-normative extended requirements are definitely perfectly usable on industrial strength projects. And they can be easily extended .

Up next
Snippets (quotes/extracts)
Visit also
Visit also (backlinks)
Related slides (other tutorials)
Related slides (other tutorials, backlinks)