Changelog

0.6.0

Released:

20.11.2025

New and Improved

  • ✨ Added uuid_source for to-reqif and uuid_target for from-reqif

    These options allow users to specify the source of UUID for ReqIF Spec-Objects when converting from needs.json to ReqIF, and the target need field to store the UUID when converting from ReqIF to needs.json. More details of how to use this feature can be found in the to-reqif and from-reqif documentation.

  • 👌 Do not force the ID prefix _ for from-reqif.

    Users can now specify their desired ID prefix without an underscore being automatically added. For example, if the user specifies id_prefix = "REQ", the resulting need IDs will be formatted as REQ123 instead of REQ_123. Moreover, if an empty string is provided as the prefix, no prefix will be added to the IDs.

  • 👌 Changed the default attribute names in mapping configuration of to-reqif

    Some of the default mapping configurations have been updated to use attribute names prefixed with need_ (e.g., need_id, need_status, and need_type) instead of ReqIF.ForeignID, ReqIF.ForeignStatus, and ReqIF.ForeignType. This change aims to provide useful default mappings that are not affected by ALM tool-specific conventions. For example, the attribute names imported with the ReqIF. prefix cannot be exported from CodeBeamer.

  • 👌 Improved warning handling when fields in the mapping configuration are not in the need schema for to-reqif

    This will not interrupt the ReqIF export process anymore, but instead log a warning message for each missing field.

  • 👌 Aligned outpath with the reqifz flag configuration

    Now, when reqifz is set to true, the outpath file will have a .reqifz extension. Conversely, when reqifz is false, the outpath file will have a .reqif extension.

  • 👌 Improved warning for invalid ReqIF attribute names when using from-reqif

    ReqIF attribute names that are invalid for Sphinx-Needs option names are now logged.

  • 👌 Improved warning for missing ReqIF attributes mapped in the configuration when using from-reqif

    If a ReqIF attribute defined in the mapping configuration is not found in the ReqIF file, a warning message is logged.

Fixes

  • 🐛 Fixed the default datatype string not being applied when not given in the mapping configuration for to-reqif

0.5.0

Released:

30.10.2025

New and Improved

  • ✨ Added CLI option --config to introduce configuration file for to-reqif and from-reqif commands

    Users can now provide a configuration file in TOML format to the to-reqif and from-reqif commands. Users must specify the path to the configuration file. More details of how to use it can be found in the Configuration Overview and ReqIF to Sphinx-Needs documentation.

    For from-reqif, the CLI argument has changed from config_path to reqif_path. The config path is now specified by the option --config. The reason for this change is to provide a consistent CLI interface for both to-reqif and from-reqif commands and better integration for build systems like Bazel.

    Migration Guide:

    # Old usage (v0.4.0 and earlier)
    ubconnect reqif from-reqif ./path/to/config.toml
    
    # New usage (v0.5.0+) if ReqIF path is not specified in the config file
    ubconnect reqif from-reqif ./path/to/file.reqif --config ./path/to/config.toml
    
    # New usage (v0.5.0+) if ReqIF path is specified in the config file
    ubconnect reqif from-reqif --config ./path/to/config.toml
    
  • ✨ Added configuration for custom mapping from Sphinx-Needs fields to ReqIF attributes

    Users can now define custom mappings in the configuration file to map Sphinx-Needs fields to ReqIF attributes. This feature allows users to tailor the exported ReqIF files to meet the specific requirements of their ALM tools. More details of how to use this feature can be found in the Mapping Configuration documentation.

0.4.0

Released:

16.10.2025

New and Improved

  • ✨ Support the conversion from ReqIF SpecRelation to Sphinx-Needs link fields when using from-reqif.

    Users can now define mappings between Sphinx-Needs link fields and ReqIF SpecRelationTypes in the configuration file. This feature enables the automatic population of Sphinx-Needs link fields based on the relationships defined in the ReqIF file. More details of how to use this feature can be found in the Links Configuration documentation.

Fixes

  • 🐛 Fixed duplicate identifiers of SPEC-OBJECT and SPEC-HIERARCHY in the ReqIF XML file when using to-reqif

    This led to missing items after importing the ReqIF file into CodeBeamer.

0.3.1

Released:

02.10.2025

Fixes

  • 🐛 Fixed section hierarchy when using to-reqif

  • 🐛 Fixed missing dependency error when using from-reqif

0.3.0

Released:

18.09.2025

New and Improved

  • ✨ Added CLI command from-reqif

    This command imports requirements from a ReqIF(Z) file and converts them into a JSON file that can be imported by needimport. It supports configurable mappings between ReqIF attributes and Sphinx-Needs fields, configurable field mappings, and static values for Sphinx-Needs fields through a configuration file. More details of how to use this command can be found in the ReqIF documentation.

0.2.0

Released:

25.08.2025

New and Improved

  • ✨ Added CLI option name

    This option gives users the ability to specify a custom name for their ReqIfSpecification.

  • ✨ Added CLI option group-types

    This option exports the Sphinx-Needs items into multiple ReqIfSpecifications based on their Sphinx-Needs types. With this option, users can organise ReqIfRelationGroups based on the Sphinx-Needs types. For example, in the Sphinx-Needs-Demo, Peter (NeedType: person) works for ADAS (NeedType: team). After exporting with --group-types, need item PETER is in the ReqIfSpecification (Person) and ADAS in the ReqIfSpecification (Team). The representation of ReqIfRelationGroup will be the following:

    <RELATION-GROUP IDENTIFIER="c433e5bf02895edf8a0e483ccc950779-team->person" LONG-NAME="relation_group-team->person">
        <SPEC-RELATIONS>
          <SPEC-RELATION-REF>ADAS-PETER</SPEC-RELATION-REF>
          <SPEC-RELATION-REF>ADAS-ALFRED</SPEC-RELATION-REF>
          <SPEC-RELATION-REF>ADAS-ROBERT</SPEC-RELATION-REF>
          <SPEC-RELATION-REF>ADAS-STEVEN</SPEC-RELATION-REF>
          <SPEC-RELATION-REF>ADAS-THOMAS</SPEC-RELATION-REF>
        </SPEC-RELATIONS>
        <TYPE>
          <RELATION-GROUP-TYPE-REF>8a936f750fbd5da39b3b4c183f223c3a</RELATION-GROUP-TYPE-REF>
        </TYPE>
        <SOURCE-SPECIFICATION>
          <SPECIFICATION-REF>dc65b98335a655e681bb3ff0809be03f-team</SPECIFICATION-REF>
        </SOURCE-SPECIFICATION>
        <TARGET-SPECIFICATION>
          <SPECIFICATION-REF>c22fb9b694e257dba67568b7bbc0c058-person</SPECIFICATION-REF>
        </TARGET-SPECIFICATION>
    </RELATION-GROUP>
    
  • ✨ Export the name of how need items are grouped into ReqIfSpecifications to reqIf.Prefix

    For example, if group-types is enabled, the need items with the same type will be grouped into the same ReqIfSpecification. In this case, its reqIf.Prefix will be the Sphinx-Needs type name. On the other hand, if group-types is disabled, all need items will be grouped into one single ReqIfSpecification with the reqIf.Prefix being all.

  • ✨ Resolve section hierarchy of need items and convert them to ReqIFSpecHierarchy

    This feature enables users to maintain the structure of their requirements as defined in Sphinx-Needs. For example, the need item EX_REQ_001 is under section Basic Example and sub-section Sphinx-Needs objects. The representation of ReqIFSpecHierarchy will be the following:

    <SPECIFICATION IDENTIFIER="c89706e0997b5dbc973cf6a0c90a9f2f-req" LONG-NAME="Needs-req">
      <TYPE>
        <SPECIFICATION-TYPE-REF>422a5efc4d1a570ebcd9d9b2324c2b1d</SPECIFICATION-TYPE-REF>
      </TYPE>
      <CHILDREN>
        <SPEC-HIERARCHY IDENTIFIER="e591ece906565ab8bc5ce637fae314d5-Sphinx-Needs objects" IS-EDITABLE="false" IS-TABLE-INTERNAL="false">
          <OBJECT>
            <SPEC-OBJECT-REF>req-Sphinx-Needs objects</SPEC-OBJECT-REF>
          </OBJECT>
          <CHILDREN>
            <SPEC-HIERARCHY IDENTIFIER="ae377f5f988a59c6b9d85f51cf4fd262-🧰 Basic Example" IS-EDITABLE="false" IS-TABLE-INTERNAL="false">
              <OBJECT>
                <SPEC-OBJECT-REF>req-🧰 Basic Example</SPEC-OBJECT-REF>
              </OBJECT>
              <CHILDREN>
                <SPEC-HIERARCHY IDENTIFIER="ef313f7ed42258aaac671a8bbfffd6dd-EX_REQ_001" IS-EDITABLE="false" IS-TABLE-INTERNAL="false">
                  <OBJECT>
                    <SPEC-OBJECT-REF>EX_REQ_001</SPEC-OBJECT-REF>
                  </OBJECT>
                  <CHILDREN>
                  </CHILDREN>
                </SPEC-HIERARCHY>
              </CHILDREN>
            </SPEC-HIERARCHY>
          </CHILDREN>
        </SPEC-HIERARCHY>
      </CHILDREN>
    </SPECIFICATION>
    

0.1.2

Released:

09.07.2025

Fixes

  • 🐛 Fixed need title to ReqIF.Name

  • 🐛 Fixed need content to ReqIF.Text

0.1.1

Released:

03.07.2025

New and Improved

  • Significantly reduced the binary package size of ubConnect.

Fixes

  • 🐛 Fixed enum serialization in reqif

0.1.0

Released:

18.06.2025

Initial release of the ubConnect CLI.

This version features exporting ReqIF files from given needs.json files. The needs.json files need to carry schema information as is available since Sphinx-Needs 3.0.0.