The non-normative extended requirements

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 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:

«physicalRequirement»: satisfied by a structural element.

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:

Dr Darren of Webel has always opposed the exclusion of the obviously useful UML Artifact from SysML (but in MagicDraw and Cameo you can sneak it in anyway). After all, systems engineers do use documents quite a bit.

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

18:01: Logical grouping with the ElementGroup extension of Comment in SysMLv1.x

Notes

[ASSERTION] The SysML non-normative extended requirements are NOT offered as the ultimate set of requirements categories or requirements fields, but they are highly usable and can be easily adapted.

[PROPOSAL]{STRONG} Dr Darren of Webel has always opposed the exclusion of the obviously useful UML Artifact from SysML (but in MagicDraw and Cameo you can sneak it in anyway). After all, systems engineers do use documents quite a bit.

Snippets (quotes/extracts)

[SysML-1.6] «functionalRequirement»: satisfied by an operation or behavior

[SysML-1.6] «interfaceRequirement»: satisfied by a port, conector, item flow, and/or constraint property.

[SysML-1.6] «performanceRequirement»: satisfied by a value property.

[SysML-1.6] «designConstraint»: satisfied by a block or part.

[SysML-1.6] «physicalRequirement»: satisfied by a structural element.

Visit also