ReqIF and SysML v2 Mapping

In ReqIF exchange documents, all elements have unique identifiers. SysML v2 currently does not have a standard way to assign unique identifiers to SysML v2 elements in textual notation that do not rely on qualified names and thus survive element renames or moves to another parent.

To preserve these unique ReqIF identifiers for round-trip conversions, the ReqIF module relies on SysML v2’s metadata for persistence. Every imported element carries a @reqif metadata tag with its original ReqIF IDENTIFIER and LAST-CHANGE; some attributes also carry @reqif_* markers for tracking datatype references. This metadata comes from SysideReqIF.sysml library that syside reqif init drops into the workspace.

Note

SysML v2 is a significantly more expressive language and exchange format than ReqIF, which can lead to some semantic data loss when exporting SysML v2 content to ReqIF.

The mapping breaks down into three groups: datatypes and attributes, type templates, and the specifications/objects/relations authored against those templates.

Datatypes and Attributes

ReqIF	SysML v2	Notes
Scalar DatatypeDefinition (String, Integer, Real, Boolean, Date, XHTML)	No standalone element. Carried as an @reqif_string / @reqif_integer / @reqif_real / @reqif_boolean / @reqif_date / @reqif_xhtml tag on every AttributeDefinition that uses it.	SysML v2 has no ergonomic way to define custom scalar datatypes, so the datatype’s identity and per-kind props (min / max, max_length, accuracy, …) live on the metadata tag. The corresponding AttributeDefinition is typed by ScalarValues::String/Integer/Real/Boolean.
DatatypeDefinitionEnumeration	enum def
EnumValue	enum under that enum def	Tagged with @reqif_enum_value to carry the ReqIF KEY and OTHER-CONTENT.
AttributeDefinition	attribute usage on the *Type-equivalent	A default value is written as attribute X : T default v. The binding form = v is reserved for AttributeValue overrides.
AttributeValue	attribute usage redefining the corresponding AttributeDefinition- equivalent	Uses the binding form = v.

Type Templates

ReqIF *Type elements act as templates for the specifications, objects, relations and groups that reference them. Each becomes a SysML v2 definition tagged with the kind-specific prefix from the SysideReqIF library.

ReqIF	SysML v2	Notes
SpecificationType	abstract #reqif_specification_type requirement def	Document template.
SpecObjectType	abstract #reqif_spec_object_type requirement def	Requirement template.
SpecRelationType	#reqif_spec_relation_type connection def	Traceability-relation template. Concrete (not abstract) because it is used directly as the type of connection usages.
RelationGroupType	abstract #reqif_relation_group_type occurrence def	Traceability-context template.

Specifications, Objects and Relations

These are the elements actually authored against the templates above.

ReqIF	SysML v2	Notes
Specification	requirement def specializing the SpecificationType-equivalent	Hosts the top-level SpecHierarchy-equivalent nodes. Top-level nodes are named <prefix>-N if the ReqIF.Prefix attribute is set, otherwise just N (1-based).
SpecObject	requirement def specializing the SpecObjectType-equivalent	Hosts any nested SpecHierarchy-equivalent nodes whose ReqIF parent is this SpecObject.
SpecHierarchy	requirement usage typed by the SpecObject-equivalent	Distributing the nodes across their parent SpecObjects (rather than nesting them all under the Specification) keeps the tree splittable across multiple SysML v2 packages and files.
RelationGroup	occurrence def specializing the RelationGroupType-equivalent	Owns the SpecRelation connections and references its source/target Specifications through source_specification / target_specification reference usages.
SpecRelation	connection usage typed by the SpecRelationType-equivalent	Source/target SpecObjects must live in one of the Specifications referenced on the parent RelationGroup. Since these are usages, they cannot be package-level and are therefore stored in the RelationGroup which is a definition.