ReqIF Tools v0.9.0 Labs

Added in version 0.9.0.

Syside Automator provides a ReqIF module for converting requirements between ReqIF and SysMLv2 models.

Note

The ReqIF module ships as an optional [reqif] extra and is not installed by default. Add it with pip install 'syside[reqif]' (or, with uv, uv pip install 'syside[reqif]'); see Install Automator for the surrounding install steps. Running syside reqif <subcmd> without the extra exits with a message pointing back to the same install command, so the failure mode is self-healing.

The module is accessible through syside reqif CLI and contains the following commands:

• init: Initialise the current workspace by extracting the SysideReqIF.sysml library required for ReqIF interoperability.

• import: Import a ReqIF exchange document into a SysML v2 model. Either creates new elements or merges changes into existing ones.

• lock: Assign stable identifiers and last_change timestamps to newly-authored ReqIF elements so they survive the round-trip back to ReqIF.

• check: Run validation checks against a ReqIF document or the current SysML v2 workspace without producing any output.

• export: Write the workspace’s ReqIF-tagged elements out as a ReqIF or ReqIFz exchange document.

Learn about:

• Requirements Workflow: Suggested way of working with ReqIF imports and exports

• ReqIF and SysML v2 Mapping: How ReqIF concepts map to SysML v2

• Preconditions: What the module expects for a successful import or export

• Known Limitations: What is still missing from the functionality

---

Requirements Workflow

The ReqIF specification frames its use around two exchange scenarios between exchange partners — typically two different requirement authoring tools, possibly at two different organisations:

• One-way exchange — partner A exports a specification from their authoring tool, transmits it to partner B, and partner B imports it into their authoring tool.

• Roundtrip exchange — same as one-way, but partner B then modifies the specification, exports it back to partner A, and partner A re-imports it on top of the original.

The Syside ReqIF CLI plays the role of the “ReqIF tool” on the SysML v2 side of either scenario. The current workspace (the directory you run the CLI in) is the SysML v2 authoring tool’s storage. The remote partner is whatever requirements management tool produced or will consume the .reqif / .reqifz exchange document.

The rest of this section walks through the full roundtrip — setup, import, edit, lock, and export — and points out where one-way exchanges deviate.

Set Up the Workspace

Before any ReqIF document can be imported or exported, the workspace needs the SysideReqIF.sysml library. This library defines the metadata used to mark SysML v2 elements as ReqIF carriers — the @reqif / @reqif_* tags that pin a stable ReqIF identity onto every imported element, and the #reqif_*_type prefixes used on the four ReqIF *Type templates.

From the directory you intend to use as the workspace, run:

syside reqif init

This drops lib/SysideReqIF.sysml into the workspace. Pass --lib-dir to put it somewhere else. The library is plain SysML v2 and is intended to be checked in alongside the rest of the model.

init is idempotent — re-running it against a workspace that already contains the library is a safe no-op (Found existing SysideReqIF.sysml library. No action needed.). The other commands also produce a clear error pointing back to init when the library is missing, so it is hard to forget.

Step 1 — Import a ReqIF Document

This step covers the ReqIF specification’s UC2: Import New Requirement Specifications and UC3: Update Requirement Specifications. From the SysML v2 side they are the same command — the CLI decides whether to create new elements or merge changes into existing ones based on what the workspace already contains.

Receive a .reqif or .reqifz from the upstream partner and place it anywhere on disk, then run:

syside reqif import path/to/incoming.reqif

The command parses the exchange document, runs the Preconditions against both the incoming document and the workspace, and writes a fixed package layout into the workspace (ReqIF_Import_Enums, ReqIF_Import_Types, ReqIF_Import_Objects, ReqIF_Import_Specifications, ReqIF_Import_Relations). Binary attachments referenced from XHTML attribute values are extracted into attachments_reqif/ (or the directory passed to --attachments-dir).

Imported elements are already locked: each carries an @reqif (or @reqif_*) metadata tag with the original ReqIF identifier and last_change timestamp, so they will round-trip back out without losing their identity.

Note

Re-running syside reqif import against a workspace that already contains a prior import applies only the delta. Elements that had a ReqIF identifier but are no longer present in the incoming document are reported as orphaned and left in place — review and delete them by hand if they should be removed. See Known Limitations for the cases that the delta path does not yet handle and that require a fresh workspace.

Tip

Run syside reqif import from a clean Git working tree (or whichever VCS you use). import rewrites the ReqIF_Import_*.sysml files in place, and on a delta run also rewrites any other files that hold ReqIF elements, so committing first lets you review git diff afterwards to see exactly what the partner changed — or, on a fresh import, to sanity-check the generated layout before building on it.

If the workflow ends here — partner A sent the document for information only — the SysML v2 model is now ready to be browsed, analysed, or fed into downstream tooling. This is the one-way scenario from the ReqIF specification.

Step 2 — Edit the Requirements in SysML v2

Once the document is in the workspace, edit it as ordinary SysML v2: rename requirements, change attribute values, attach SysML v2 constructs that ReqIF cannot express (parts, actions, analyses), or add new requirements under existing Specifications.

Two practical points:

• Anything written in SysML v2 that is not annotated with an @reqif / @reqif_* metadata tag stays SysML-only and will not appear in any future ReqIF export. This is the intended way to enrich an imported document with model content that has no ReqIF counterpart.

• Anything that is annotated with such a tag and that you want to round-trip back out must end up with a stable identifier. Imported elements already have one; newly authored elements do not until the next step runs.

See ReqIF and SysML v2 Mapping for the table of equivalent constructs to use when authoring on the SysML v2 side.

Reorganising the Imported Files

The five ReqIF_Import_*.sysml files written by import are a starting point, not a fixed layout. export and the import delta path key off the @reqif metadata, not the file or package the element happens to live in, so any def-shaped element — DatatypeDefinitionEnumeration, SpecificationType, SpecObjectType, SpecRelationType, RelationGroupType, Specification, SpecObject, and RelationGroup itself — can be moved into a different file or SysML v2 package once you fix up the private import lines so cross-references still resolve. A subsequent syside reqif export writes out exactly the same ReqIF content as before the move, and a subsequent delta syside reqif import recognises the moved elements as already-present and reports No changes detected.

The exception is usage-shaped elements that depend on their enclosing context:

• A SpecRelation (a connection) must stay inside the occurrence def for its RelationGroup. The export resolves a relation’s source and target endpoints through the source_specification / target_specification features of the enclosing group, and the precondition that “every ReqIF tag must be an owned feature of a ReqIF-annotated type” rejects a relation hoisted into a top-level package. Move the whole RelationGroup occurrence def instead — the contained connections travel with it.

• A nested SpecHierarchy (a requirement usage indexed as '1', '2', …) is owned by the parent SpecObject def and moves with that def; it cannot be hoisted on its own.

A practical layout is to break the imported model up by subsystem or document — for example, one file per Specification plus a shared types file — instead of keeping the four flat ReqIF_Import_Objects / …Specifications / …Relations / …Types files generated by import. Subdirectories are fine: the workspace is scanned recursively, so files under specs/, types/, etc. are picked up just like top-level ones.

Step 3 — Lock Newly-Authored Elements

Run:

syside reqif lock

lock walks every @reqif_*-tagged element in the workspace, fills in a fresh UUID identifier and a last_change timestamp on any element that does not already have them, and leaves elements that were imported (or locked previously) alone. Locking is idempotent — re-running it on an already-locked workspace is a no-op.

Without this step, freshly-authored ReqIF elements would be exported with regenerated identifiers each time, defeating the round-trip identity promise.

Tip

syside reqif export re-runs the SysML v2 preconditions before writing, and one of those preconditions is that every ReqIF-tagged element is locked. You do not have to remember to call lock — the export will fail with a clear message if you forget. lock is also safe to run as a pre-commit hook.

Note

syside reqif lock does not track when the element was last modified, only gives the initial date. If you care about tracking which element was modified precisely when, set up a review process that every modified requirement also needs to have its last_change updated before a Git (or equivalent) branch can be merged.

Step 4 — Validate (Optional)

The same checks that import and export run automatically can be invoked on their own:

syside reqif check reqif path/to/incoming.reqif
syside reqif check sysml

Use the first form to vet a .reqif from a new partner before committing to an import; use the second to confirm the workspace is export-ready without producing an output file. The full list of checks is documented in Preconditions.

Tip

Wire syside reqif check sysml into your CI/CD pipeline as a gating step. It exits non-zero on any precondition failure, so a green build means the workspace is ready for an export or a delta import at any time — no last-minute surprises about an unlocked element or a stray top-level package when a partner actually asks for the next round-trip.

Step 5 — Export Back to ReqIF

This step covers the ReqIF specification’s UC1: Export Requirement Specifications. Run:

syside reqif export --title "Brake System Requirements, rev. 3" outgoing.reqif

The --title flag is required and ends up in the exchange document’s REQ-IF-HEADER as the human-readable name partner A will see. Useful additional flags:

• --comment "<text>" — free-form description that goes into the header alongside the title.

• --repository-id <id> — identifier (UUID, URL, …) of the repository this export was produced from. Recommended for any roundtrip workflow so the receiver can correlate exports. The Git remote URL of the repository where the SysML v2 model lives is usually the best choice — it identifies the workspace unambiguously and gives a recipient looking at a stale .reqif somewhere to look it up.

• --reqifz — emit a zipped archive that bundles the XML and any attachments_reqif/ files into a single file. Use this whenever the document references binary attachments. The flag controls the format of the bytes written; the output filename is whatever you pass as the positional file argument, unchanged. The extension must agree with the flag — --reqifz outgoing.reqif (or outgoing.reqifz without --reqifz) is rejected before any model work runs, so pick the matching .reqifz / .reqif name to start with.

• --attachments-dir <dir> — read attachments from a directory other than attachments_reqif/.

Transmit the resulting file to partner A through the channel of your choice (email, shared drive, ticket attachment, …). The transmission itself is out of scope of the ReqIF specification and of this CLI.

Note

The body of an exported document (the CORE-CONTENT) is deterministic — running export twice against an unchanged workspace produces byte-identical CORE-CONTENT. The REQ-IF-HEADER, however, gets a fresh IDENTIFIER (a random UUID) and a fresh CREATION-TIME (the current wall-clock time) on every run. If you intend to commit exported .reqif files to version control alongside the SysML v2 sources, expect a two-line diff in the header on every re-export even when nothing in the model has changed.

Authoring from Scratch on the SysML v2 Side

The workflow above starts from an incoming .reqif, but the SysML v2 side can also be the originator of a one-way exchange. In that case the steps reduce to:

1. syside reqif init to drop in the library.

2. Author the model directly in SysML v2 using the constructs listed in ReqIF and SysML v2 Mapping. Use #reqif_*_type stereotypes on the abstract *Type template defs, and @reqif metadata blocks on the instance-side elements (specifications, spec objects, relation groups, spec relations) that should round-trip through ReqIF.

3. syside reqif lock to assign identifiers.

4. syside reqif export --title "<title>" outgoing.reqif to produce the exchange document.

From there the receiving partner imports outgoing.reqif into their tool exactly as in the inbound case above — the format is symmetric.

Starter Model

A small ready-to-go model is shipped with these docs. Drop it into an empty workspace, run the four-step recipe above, and you have a complete round-trip — a working example that exercises every ReqIF concept (an enum datatype, all four *Type templates, five SpecObjects arranged into two Specifications with nested hierarchies, and a RelationGroup containing two SpecRelation connections):

BrakeSystem.sysml

// Starter SysML v2 model for the Syside ReqIF tooling.
//
// This file is unlocked: every @reqif tag is bare. Run the workflow
// from this directory:
//
// syside reqif init                          (drops in SysideReqIF.sysml)
// syside reqif lock                          (populates UUIDs and timestamps)
// syside reqif export --title "..." out.reqif

package BrakeSystem {
    private import SysideReqIF::*;

    // ---------------------------------------------------------------
    // Datatypes
    //
    // Enumerations carry @reqif on the def and @reqif_enum_value on
    // each member. The 'key' attribute is the ReqIF integer key for
    // the enum value.
    // ---------------------------------------------------------------

    enum def Priority_Enum {
        @reqif;
        enum Low {
            @reqif_enum_value {
                :>> reqif_enum_value::key = 0;
            }
        }
        enum Medium {
            @reqif_enum_value {
                :>> reqif_enum_value::key = 1;
            }
        }
        enum Critical {
            @reqif_enum_value {
                :>> reqif_enum_value::key = 2;
            }
        }
    }

    // ---------------------------------------------------------------
    // Type templates (ReqIF *Type elements)
    //
    // The four ReqIF type kinds map to abstract SysML defs carrying a
    // #reqif_*_type stereotype. Concrete SpecObjects, Specifications
    // and RelationGroups subclassify these.
    //
    // Refines is a connection def, not abstract, because its concrete
    // SpecRelation usages type by it directly.
    // ---------------------------------------------------------------

    abstract #reqif_specification_type requirement def Document {
        @reqif;
    }

    abstract #reqif_spec_object_type requirement def Requirement {
        @reqif;
        attribute priority : Priority_Enum default Priority_Enum::Medium {
            @reqif;
        }
    }

    #reqif_spec_relation_type connection def Refines {
        @reqif;
        end source_requirement;
        end target_requirement;
    }

    abstract #reqif_relation_group_type occurrence def Traceability {
        @reqif;
    }

    // ---------------------------------------------------------------
    // Spec objects (the requirement defs themselves)
    //
    // Each one specialises Requirement and overrides priority.
    //
    // The nested 'requirement 1 : X' usages are the SpecHierarchy
    // nodes — their indexed names ('1', '2', ...) become ReqIF
    // SpecHierarchy children.
    // ---------------------------------------------------------------

    requirement def BrakingSystem :> Requirement {
        @reqif;
        attribute :>> priority = Priority_Enum::Critical;

        requirement '1' : EmergencyBrake {
            @reqif;
        }
        requirement '2' : PedalForce {
            @reqif;
        }
    }

    requirement def EmergencyBrake :> Requirement {
        @reqif;
        attribute :>> priority = Priority_Enum::Critical;
    }

    requirement def PedalForce :> Requirement {
        @reqif;
    }

    requirement def HydraulicCircuit :> Requirement {
        @reqif;

        requirement '1' : ABSController {
            @reqif;
        }
    }

    requirement def ABSController :> Requirement {
        @reqif;
        attribute :>> priority = Priority_Enum::Critical;
    }

    // ---------------------------------------------------------------
    // Specifications and their hierarchies
    //
    // Each Specification specialises Document. The nested 'requirement
    // 1 : X' usages are the SpecHierarchy nodes — their indexed names
    // ('1', '2', ...) become ReqIF SpecHierarchy children.
    // ---------------------------------------------------------------

    requirement def SystemRequirements :> Document {
        @reqif;

        requirement '1' : BrakingSystem {
            @reqif;
        }
    }

    requirement def SubsystemRequirements :> Document {
        @reqif;

        requirement '1' : HydraulicCircuit {
            @reqif;
        }
    }

    // ---------------------------------------------------------------
    // Traceability between System and Subsystem requirements
    //
    // The RelationGroup names the two specifications as
    // source_specification / target_specification, and its connection
    // usages (typed by Refines) link individual SpecObjects across the
    // two documents.
    // ---------------------------------------------------------------

    occurrence def SystemTracesSubsystem :> Traceability {
        @reqif;
        source_specification : SystemRequirements;
        target_specification : SubsystemRequirements;

        connection HydraulicRefinesBraking : Refines {
            @reqif;
            end :>> Refines::source_requirement ::> source_specification.'1';
            end :>> Refines::target_requirement ::> target_specification.'1';
        }

        connection ABSRefinesEmergency : Refines {
            @reqif;
            end :>> Refines::source_requirement ::> source_specification.'1'.'1';
            end :>> Refines::target_requirement ::> target_specification.'1'.'1';
        }
    }
} // package BrakeSystem

Download BrakeSystem.sysml

Save it into an empty directory, then run syside reqif init followed by syside reqif lock and syside reqif export --title "Brake System Requirements" out.reqif. The resulting out.reqif will contain five SpecObjects, two Specifications with hierarchies, and a RelationGroup with two refines relations — ready to send to a partner.

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 specialising 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 specialising 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 specialising 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.

Preconditions

There are a couple of preconditions your ReqIF files and SysML v2 models need to satisfy to use this tool. Most of these preconditions should be met by default if your requirements management tool follows the ReqIF specification.

Precondition satisfaction can be checked using the syside reqif check CLI command. syside reqif check reqif <file.reqif> runs the ReqIF preconditions against an exchange document; syside reqif check sysml runs the SysML v2 preconditions against the current workspace. The same checks also run automatically as part of syside reqif import and syside reqif export.

ReqIF Preconditions

These checks run against the ReqIF exchange document (after parsing it into the IR).

Structural Integrity

• Every cross-element reference must resolve to an element in the document of the right kind: a Spec* element’s type to its corresponding *Type definition; a SpecHierarchy’s object and a SpecRelation’s source and target to an existing SpecObject; a RelationGroup’s source and target to an existing Specification; and every AttributeDefinition’s datatype to an existing DatatypeDefinition.

• If the document contains any SpecRelation, it must also contain at least one RelationGroup. SysML v2 maps SpecRelation to a connection inside a RelationGroup, so an unhomed relation has no parent namespace.

• Every SpecRelation must be referenced by exactly one RelationGroup. References must resolve (no dangling ids), no relation may be claimed by more than one group, and no relation may be left unclaimed.

• For each RelationGroup, every SpecRelation it contains must reference SpecObjects that live inside one of the Specifications named on the group’s source and target.

• Each SpecObject may appear in at most one Specification.

• The SpecHierarchy must contain no cycles — no SpecObject may appear as its own descendant.

• A given SpecObject may parent nested hierarchy nodes in at most one position across the model. Two distinct hierarchy nodes that parent the same SpecObject would emit colliding indexed-name siblings ('1', '2', …) under one RequirementDefinition.

Name Uniqueness Within a Parent

• EnumValues within an enumeration DatatypeDef must have unique names.

• AttributeDefs within a SpecType must have unique names.

• SpecRelations within the same RelationGroup must have unique names.

Names That Must Not Shadow Other Names

The SysML v2 embedding emits a fixed package layout (ReqIF_Import_Enums, ReqIF_Import_Objects, ReqIF_Import_Specifications, ReqIF_Import_Relations, ReqIF_Import_Types) with a fixed set of imports between them. The following name collisions would shadow those imports and break re-parsing of the emitted SysML v2:

• No element name may match a reserved SysideReqIF metadata name (the names defined by the SysideReqIF.sysml library).

• No SpecObject may share a name with an enumeration DatatypeDef.

• No Specification may share a name with an enumeration DatatypeDef.

• No RelationGroup or SpecRelation may share a name with any Specification.

• An enumeration DatatypeDef must not share its name with the AttributeDef it types. Otherwise SysML v2 emits an ambiguous attribute Priority typed by Priority; rename the enum (e.g. to Priority_enum) to fix.

• A SpecType must not carry both a magic ReqIF.Text / ReqIF.Description AttributeDef and a free-form AttributeDef named Text / Description. The magic attributes are emitted as doc Text / doc Description blocks on the parent and would shadow the free-form sibling.

Warnings (Non-Fatal)

• A DatatypeDef referenced by no AttributeDef is reported as a warning. Such a DatatypeDef has no carrier on the SysML v2 side (the embedding only emits DatatypeDefs reached through @reqif_* annotations on AttributeDefs) and is dropped on import.

SysML v2 Preconditions

These checks run against the .sysml documents in the current workspace.

• Each .sysml document may declare at most one top-level Package or LibraryPackage. Incremental ReqIF import overwrites the document with one top-level package, so any extras would be dropped. Both kinds count toward the limit; a file that mixes one of each still fails.

• Every ReqIF tag (every element annotated with a @reqif_* metadata tag) must be “locked” — must carry both a stable identifier and a last_change value. Unlocked tags lose their identity across ReqIF round-trips. Run syside reqif lock to populate fresh UUIDs and last_change timestamps for any element flagged here.

• A @reqif-annotated def may subclassify (:>) another @reqif-annotated def only when the parent carries a #reqif_*_type prefix tag and the child does not. This is the instance-to-type pattern that import emits — a SpecObject / Specification / RelationGroup def specialising its corresponding SpecObjectType / SpecificationType / RelationGroupType. Any other @reqif :> @reqif chain — type extending type, or instance extending instance — has no ReqIF analogue and would be dropped on the next export. attribute usages that redefine (:>>) a type’s AttributeDef are unaffected; redefinition is not subclassification.

Known Limitations

As of 0.9.0, the following ReqIF features are not preserved across syside reqif import and syside reqif export. Documents using them can still be imported, but the listed fields will be missing from any ReqIF written back out.

Fields Dropped on Import

The following ReqIF fields are not imported to SysML:

• ALTERNATIVE-ID on any element.

• IS-TABLE-INTERNAL on SpecHierarchy nodes.

• EDITABLE-ATTS on SpecHierarchy nodes.

• IS-SIMPLIFIED on XHTML attribute values, and the original (non-simplified) side of those values.

• AttributeValues on RelationGroup and SpecRelations.

Fields Lost on Export

• Attribute default values authored in the binding form attribute X : T = v are not recognised as default values on export. Imported defaults use the attribute X : T default v form, which round-trips correctly; only defaults that are written or edited into the = form on the SysML v2 side after import are lost.

Attachment Bundling on Export

• syside reqif export collects every file under --attachments-dir (default attachments_reqif/) recursively, regardless of whether the file is referenced from any XHTML attribute value in the exported document. Stale files left over from a previous import, build artefacts, scratch notes, or anything else that happens to sit in that directory tree will be shipped alongside the export — and bundled into the .reqifz archive when --reqifz is used. Curate the directory before exporting, or point --attachments-dir at a folder that contains only the attachments you intend to ship.

Authoring Metadata

• syside reqif export does not generate any provenance / authoring attributes. ReqIF authoring tools conventionally populate ReqIF.ForeignCreatedBy, ReqIF.ForeignCreatedOn and the rest of the ReqIF.Foreign* family (see the prostep ivip ReqIF Implementation Guide) so a recipient can see who authored or last touched each requirement in the source tool. Syside emits nothing for these attributes — partner A opening a SysML v2-originated .reqif will not be able to tell who authored a given requirement from the document alone.

• If an incoming .reqif carries those attributes, they are imported as ordinary string attribute values on the corresponding SysML v2 element and round-trip back out verbatim. Once a SysML-side user edits the requirement, the imported values become stale relative to the actual edit history. Update them by hand if the recipient relies on them, or strip them from the source ReqIF before import to avoid the misleading attribution.

XHTML Rich-Text Round-trip

Rich-text (XHTML) attribute values are converted to SysML v2 doc blocks that are written in Markdown. Some text shapes do not round-trip unchanged:

• Runs of two or more spaces inside text content collapse to a single space.

• A heading whose only content is a non-breaking space (or any other Unicode whitespace character outside ASCII space) becomes empty.

• Two adjacent bullet lists that use different bullet characters (- and *) merge into a single list.

• Colored text in HTML cannot be represented in Markdown as colored.

Other Data

• Arbitrary accuracy real numbers, as Syside currenltly stores all floating point numbers as Python floats.