Notice how the it gets messy when the owner is shown because the spec sample has the HSUV acronym repeated within the Package hierarchy? For the tidier Webel approach please visit: "Trust the Namespace!"

Up next

Figure D.14 - Requirements Relationships Expressed in Tabular Format (Table)

Notes

[ASSERTION, TOOL] SysML: The «system», «subsystem», «external», «domain» and «system context» keywords are for "user defined" block Stereotypes (they are not part of core SysML); they are supported in MagicDraw/Cameo as Non-Normative Extensions.

[NAMING, POLICY]{STRONG} "Trust the Namespace" - DO NOT repeat information in names of owned elements that can be gleaned from the owner or ancestor (and is usually easily shown using display options). It is WET, it breaks the DRY principle!

Snippets (quotes/extracts)

[SysML-1.6] Figure D.13 focuses on the Acceleration requirement, and relates it to other requirements and model elements.

[SysML-1.6] The “refine” relation, introduced in Figure D.12, shows how the Acceleration requirement is refined by a similarly named use case.

[SysML-1.6] The Power requirement is satisfied by the PowerSubsystem, and a Max Acceleration test case verifies the Acceleration requirement.

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

[UML-2.5.1] «Refine» Abstraction Specifies a refinement relationship between model elements at different semantic levels, such as analysis and design. The mapping specifies the relationship between the two elements or sets of elements. The mapping ...

[SysML-1.6] The Refine stereotype specializes UML4SysML Refine and DirectedRelationshipPropertyPath to enable refinements to identify their sources and targets by a multi-level path of accessible properties from context blocks for the sources and targets.

[SysML-1.6] A DeriveReqt relationship is a dependency between two requirements in which a client requirement can be derived from the supplier requirement.

[SysML-1.6] For example, a system requirement may be derived from a business need, or lower-level requirements may be derived from a system requirement.

[SysML-1.6] As with other dependencies, the arrow direction points from the derived (client) requirement to the (supplier) requirement from which it is derived.

Related slides (includes other tutorials)

Related slides (backlinks, includes other tutorials)

Derived requirements and the DeriveReqt relationship

Derived requirements and the DeriveReqt relationship - compartment styles

Refining requirements

Satisfying Requirements and the Satisfy relationship

Requirements and the Trace relationship - metamodel

Trace used for model element elicitation - callout style

Trace used for model element elicitation - tagged value and element property styles

TestCase and Verify metamodel

TestCase and Verify example - callout style

Composite (a.k.a. "compound") Requirements

The Copy relationship

MagicDraw/Cameo: Satisfy Requirement Matrix: Hybrid SUV vs Block (all)

MagicDraw/Cameo: Satisfy Requirement Matrix: Hybrid SUV vs Block and PartProperty (relations only)

Useful "user-defined" stereotypes for Blocks: «system context», «system», «subsystem», «external», «domain»

Visit also

Visit also (backlinks)

Flags