A most basic Requirement with a 'name', an 'id', and 'text'

"It's important when teaching real Requirements Engineering to real engineers to use really real examples from real world projects, so I've chosen one here from the mockumentary film 'This is Spinal Tap'.

From Wikipedia:

'"Up to eleven", also phrased as "these go to eleven", is an idiom from popular culture, coined in the 1984 movie This Is Spinal Tap, where guitarist Nigel Tufnel proudly demonstrates an amplifier whose volume knobs are marked from zero to eleven, instead of the usual zero to ten.'

Before jumping straight in and using that 'text' field on all of your Requirements, please consider this recommendation:

Webel Best Practice: Webel suggests using a verbose 'name' for leaf (child) Requirements but NO 'text' to prevent Single Source of Truth issues and for improved callout vs relationships (but this might not always work when syncing with external requirements management tools)

The reality is, the Requirements system in SysML works brilliantly together with model-based engineering (other technologies don't) and the tool support for it is excellent.

You can't callout the 'text' of a Requirement into the compartments for the relevant relationships anyway (and you don't even really need it in query tables if you use a verbose 'name').

If you use a verbose 'name' and a long 'text' sooner or later it will break, because it is WET not DRY.

But if you use a short Requirement 'name' and a long 'text', the short 'name' won't be useful enough in callouts or even as a mental prod as soon as you have lots of requirements on a real project. So you might as well just use no 'text' at all if you can get away with it.

One possibly good excuse for rejecting this recommendation here is that you wish to use this nice feature of MagicDraw SysML Plugin and Magic Cyber-Systems Engineer ^® (Cameo Systems Modeler^®):

MagicDraw/Cameo can parse the 'text' field of some mathematical Requirements and populate the constraint (and also then the constraint parameters) of a ConstraintBlock that refines a Requirement (your mileage varies).

But you'll need to check them anyway, the language and maths parsing is pretty good, but not perfect.

And just in case you are tempted to "document" your requirements:

MagicDraw/Cameo: If you must use the Documentation field in the specification dialog for a Requirement element DO NOT use it to state the Requirement because that is WET not DRY. Instead just use the Requirement 'name' and/or the 'text'.

So, with all necessary caveats concerning the 'text' field behind us, the rest of this tutorial trail will in fact use the 'text' field anyway. We'll see next that the 'text' in fact lives in the AbstractRequirement along with some other essential requirements engineering goodies.

Up next

A basic Requirement is an AbstractRequirement

Notes

[NAMING, POLICY]{SUGGESTED} Webel suggests using a verbose 'name' for leaf (child) Requirements but NO 'text' to prevent Single Source of Truth issues and for improved callout vs relationships (but this might not always work when syncing with external requirements management tools)

[POLICY]{STRONG} About the Single Source of Truth (SSOT) and Don't Repeat Yourself (DRY) principles

[TOOL, WARNING] MagicDraw/Cameo: If you must use the Documentation field in the specification dialog for a Requirement element DO NOT use it to state the Requirement because that is WET not DRY. Instead just use the Requirement 'name' and/or the 'text'.

[CAPABILITY, FEATURE, TOOL] MagicDraw/Cameo can parse the 'text' field of some mathematical Requirements and populate the constraint (and also then the constraint parameters) of a ConstraintBlock that refines a Requirement (your mileage varies).

Snippets (quotes/extracts)

[SysML-1.6] A requirement specifies a capability or condition that must (or should) be satisfied.

[SysML-1.6] A requirement may specify a function that a system must perform or a performance condition that a system must satisfy.

[SysML-1.6] Requirements are used to establish a contract between the customer (or other stakeholder) and those responsible for designing and implementing the system.

[SysML-1.6] A standard requirement includes properties to specify its unique identifier and text requirement. Additional properties such as verification status, can be specified by the user.