Tags and keywords
The non-normative SysML ExtendedRequirement keywords are: «extendedRequirement», «functionalRequirement», «interfaceRequirement», «performanceRequirement», «physicalRequirement», «designConstraint».For good measure the Requirements Plugin for MagicDraw SysML Plugin and Magic Cyber-Systems Engineer ® (Cameo Systems Modeler®) throws in: «usabilityRequirement» and «businessRequirement».
If you just want to get at the
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):
- «functionalRequirement»: satisfied by an operation or behavior
- «interfaceRequirement»: satisfied by a port, conector, item flow, and/or constraint property.
- «performanceRequirement»: satisfied by a value property.
- «designConstraint»: satisfied by a block or part.
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 .