You are not logged in. Click here to log in.

codebeamer Application Lifecycle Management (ALM)

Search In Project

Search inClear

Tags:  ReqIF

Requirements Interchange Format (ReqIF)

Since codebeamer 7.6.0, it is possible to exchange data between codebeamer and other systems, for example, with IBM Rational DOORS, via Requirements Interchange Format (ReqIF).
Codebeamer only supports the ReqIF standard from version 1.0.1 and above; the non-standardized RIF formats are not supported.
More Information about ReqIF can also be found in Wikipedia or the ProSTEP iViP ReqIF implementor forum.


ReqIF is an XML file based data exchange, with the following file extensions:

  • .reqif for a single ReqIF XML file (instead of the usual .xml extension)
  • .reqifz for ZIP archives containing ReqIF files and additional files, e.g. images (instead of the usual .zip extension)


Other than the name suggests, the Requirements Interchange Format is not restricted to exchanging requirements only.

ReqIF is a generic semantic data model, that allows to define arbitrary types of

  • Items,
  • Relations and
  • Specifications.


Item types are similar to classes in object orientated programming, tables in a relational database model or trackers in codebeamer.

There can be any number of item types in a ReqIF file, each having a different set of attributes, e.g. User Story, Use Case, Requirement, Test Case, etc.


Relation types are similar to codebeamer association types. They define a specific type of relation between two items, e.g. Depends On, Derived From, etc.

Relation types can also define attributes for relations, e.g. the equivalent to Suspected.


Specifications aggregate items into a tree hierarchy.

Specifications can include items of different types and the same item can be included in multiple specifications or in the same specification multiple times.

Specifications are more like tables of content or document outlines than real documents, because they cannot carry any extra information, except the tree hierarchy.

The best equivalent to a Specification in codebeamer is a tracker document view (although trackers can only contain items of the same type).



Example ReqIF schema:





ReqIF does not have a concept of reference fields or foreign keys, but codebeamer is able to convert reference fields into Relations upon export and bind Relation types to tracker reference fields upon import.


ReqIF does also not have a concept for exchanging a history of changes or comments about changes. A ReqIF file/archive only contains the current/head revision of the data to exchange.


Exchanging data via ReqIF

There are four use cases in a ReqIF exchange process:

  1. Initial import of ReqIF data
  2. Export data as ReqIF
  3. Re-Export of previously imported (and possibly modified) data back to origin
  4. Re-Import (modifications of) previously imported ReqIF data from the same origin





The scenario depicted above is only an example. codebeamer can be also at the begin or at the end of a ReqIF exchange chain.

There can be any number of iterations between two exchange partners.



Exchanging work/config items of the following types are not supported:

  • Teams
  • Work Log (Time recordings)
  • Reviews
  • Test Runs
  • Source code Commits/Pushes
  • Pull Requests



Import of ReqIF data

ReqIF data can be imported

  • into a new project
  • or into an existing project (only since codebeamer 9.3 and newer).
Caution: ReqIF imports
  • will not trigger any notifications or workflow actions on import target trackers.
  • will update the status of existing tracker items (only if a ReqIF attribute is mapped to the target tracker's status), even if such a status change is not allowed by the tracker workflow.
  • will import ReqIF relations, that are mapped to target tracker reference fields, even if the referenced item does not match the reference field filter
  • See also ReqIF Limitations

This is not a bug, but intentional, in order for the ReqIF import to succeed.

If required, ReqIF.ImportStatus (see below) can be used, typically in conjunction with a special tracker view, to review all items, that were imported, updated or marked for deletion by a ReqIF import, in a subsequent process step.


Create a new project from ReqIF data

Creating a new project for the ReqIF data to import is preferable, if these are customer requirements, that should only be qualified, commented and referred to within codebeamer and should otherwise be kept unchanged. Write access to the imported data should be restricted and larger structural changes of the imported data model (tracker configuration) should be avoided, if continuous/iterative exchange of modifications/updates between the origin/customer and codebeamer is required. Adding new fields to imported trackers is no problem in that respect. Of course, these are only recommendations.

To import new requirements via ReqIF:

  • Choose New Project from the codebeamer Projects menu
  • Choose Create a new project from a template and
  • Attach the ReqIF file (*.reqif) or archive (*.reqifz) to import

On the Next screen, the name of the new project can be added, map the ReqIF data can be mapped to import to target trackers in the new project. presented the object model found in the ReqIF file to import.

Since codebeamer 9.4 and newer, either a name can be chosen for the Source of the ReqIF data, or the default name Origin can be accepted.



Since codebeamer 9.4 and newer, a drop-down list is added to the Source field to see the header of the ReqIF file(s) to import:




codebeamer 8.2 and newer, tries to group the ReqIF meta data by Specification:

  • If a Specification Type is used exclusively by one Specification, the Specification Type will be shown as a child named Tracker of the Specification.
  • If items of a specific Item Type are used exclusively by one Specification, then the Item Type will be shown as a child of the Specification, and it will be automatically associated with the same target tracker than the Specification.
    • If there is only one type of items in a Specification, then the name Items will be used for the Item Type
      e.g. Example 2: IBM Rational DOORS.
    • If there are multiple types of items in a Specification, each Item Type will be shown with its own name, and a unique set of qualifiers also needs to be specified that identifies items of this type in the target tracker
      e.g. Example 3: IBM Rational Requirements.


The following screenshots are only examples. They may look completely different, depending on the data model of the ReqIF file to import:



Example 1: SparxSystems Enterprise Architect




This example ReqIF file contains one Specification with an exclusive Specification Type (Tracker) and 2 Items.


Special about the Items is:

  • There is no extra attribute (ReqIF.Name or ReqIF.ChapterName) for the item name/summary, so the LONG-NAME of the SpecObject (item) will be used as the item name/summary.
  • There is an extra attribute for the item description, although its name is not the proposed name (ReqIF.Text).
    • If there is also no attribute for the item description (e.g. Scalability Requirement), the DESC of the SpecObject (item) will be used as the item description.


There are also additional Item Types, that are not related to any Specification, e.g. User Story.

The User Story could be mapped to the default User Stories tracker, but in the current example these are not mapped/imported (--Ignore--) as there are no items of this type.


Ignoring empty Specifications, Item Types or Relations, as well as empty attributes may not be appropriate if the imported data is intended to be edited.

For example:

  • Add new tracker items
  • Set values for (empty) fields
  • Add new item associations

and then re-export the modified data.



Example 2: IBM Rational DOORS




In ReqIF files produced by IBM Rational DOORS, typically each Specification has its own Type and only contains Items of a single type.


Because the association between Specification and Item Type is only defined indirectly via: Specification ► SpecHierarchy ► SpecObject ► SpecObjectType, the Item Type of an empty Specification is undefined, and will be listed under the non-exclusive/shared Item Types.


DOORS requirements also have (along with lots of other attributes), each a

  • ReqIF.ChapterName
  • ReqIF.Name
  • ReqIF.Text

But whether the attribute actually has a value, depends upon the type of the requirement:

  • A DOORS Heading has a value for the ReqIF.ChapterName, but ReqIF.Name and ReqIF.Text are typically empty.
  • Non-Heading types, e.g Requirement have a value for ReqIF.Text, but both, ReqIF.ChapterName and ReqIF.Name are typically empty.


If the mapping of ReqIF attribute to target field is ambiguous, e.g. both ReqIF.ChapterName and ReqIF.Name could be mapped to Summary, then the number of items can be used, where the field has a value, and the list of the first 10 field values, to find the best match.

In the example above, only 1 item has a ReqIF.Name, but 9 items have a ReqIF.ChapterName: So use ReqIF.ChapterName for Summary.



Example 3: IBM Rational Requirements





In ReqIF files produced by IBM Rational Requirements, Specifications typically contain items of different types, e.g. Heading, Information, Requirement etc.


Because all these items are mapped to the same target tracker, each item type must have a unique set of qualifiers, to identify items of this type in the tracker.

E.g. Heading items are those items in the target tracker, where Type == Folder


Specifications can also refer to (config) items, that are not part of the Specification itself, e.g. Actor.

These separate Item Types should typically be mapped to appropriate config item trackers, e.g. Actors.


In IBM Rational Requirements, all item types have a ReqIF.Name and a ReqIF.Text, that should be mapped to item Summary and Description.

The item type Heading also has a ReqIF.ChapterName, but the value of this attribute is the same than ReqIF.Name, so it can be safely ignored.



Target Tracker

For each Specification and standalone Item Type to import, this type of items needs to be mapped to a target codebeamer Tracker.
Options:

  • not importing this Specification or items of this Item Type (-- Ignore --)
  • choosing a pre-defined tracker from the dropdown list
  • creating a new custom tracker, via -- New Tracker -- at the bottom of the dropdown list.

Ignoring empty Specifications and Item Types may not be appropriate. To edit the imported data,

  • add new tracker items
  • set values for (empty) fields
  • add new item associations

and then re-export the modified data.


Depending on the type of the selected target tracker, additional mappings for the chosen target may be necessary.



Target Table

For trackers with embedded tables like Test Cases or Test Sets, there is an optional embedded Table selector.

This allows to map input items not to main items of the target Tracker, but to rows in the selected embedded Table of a main/parent target tracker item.


From another example ReqIF import:



Mapping items to an embedded tracker item Table (e.g. Test CasesTest Steps) only works if a mapping for the main tracker items has also been created (e.g Test Cases) and there is a Specification that establishes the parent/child relation between the main tracker items (e.g. Test Cases) and their respective sub items (e.g. Test Steps) in its hierarchy tree.



Target Qualifiers

Multiple input Item Types can be mapped to the same codebeamer target tracker (table). In this case, a set of item qualifiers needs to be additionally specified that uniquely identifies this subset of items in the target tracker (table).


In our Example 1, the input Item TypesFunctional Requirement, Performance Requirement, Scalability Requirement, Security Requirement, Maintainability Requirement, Usability Requirement and Legal Requirement can all be mapped to the pre-defined tracker System Requirement Specifications, and we can use the field Type as unique item qualifier:




For each input Item Type mapped to System Requirement Specifications and using Type as item qualifier, a different type value needs to be chosen from the drop-down list.




If there is no pre-defined value matching the Item Type, a new value can be created via New Value... at the bottom of the drop-down list.


If a single qualifier field/value pair is not sufficient, to uniquely identify item sub-sets, add More qualifiers....

To remove chosen qualifiers, click on Remove behind the qualifier.

Multiple qualifiers can be re-ordered by dragging.



Target Fields

For each mapped Specification, Item Type and Relation Type, the type attributes must be either mapped to target (tracker) fields or ignored.




Ignoring empty attributes may not be appropriate. To edit the imported data, set the values of these fields and re-export the modified data.
To map empty attributes, select the including empty checkbox in the header.

Input attributes can only be mapped to compatible target fields (according to the attribute type).
If there is no pre-defined field matching the input attribute, a new field can be created via -- New Field -- at the bottom of the drop down list.

If the mapping of ReqIF attribute to target field is ambiguous, (e.g. both ReqIF.ChapterName and ReqIF.Name could be mapped to Summary), the followings can be used:

  • the number of items, where the field has a value (in the Count column),
  • and the list of the first 10 field values (Click on the number in the Count column),

to find the best match.

  • In the Example 2 above: only 1 item has a ReqIF.Name, but 9 items have a ReqIF.ChapterName:
    • So use ReqIF.ChapterName for Summary.
    • Ignore ReqIF.Name
  • In the Example 3 above: The item type Heading has a ReqIF.ChapterName and a ReqIF.Name
    • but because the values of ReqIF.ChapterName and ReqIF.Nameare the same
      • Use ReqIF.Name for Summary.
      • Ignore ReqIF.ChapterName


Only for Item Type:

  • If there is no attribute (e.g. ReqIF.Name or ReqIF.ChapterName) associated with the item Summary, then the LONG-NAME of the SpecObject (item) will be used as the item name/summary.
  • If there is no extra attribute (e.g. ReqIF.Text) associated with the item Description, then the DESC of the SpecObject (item) will be used as the item description.

Since codebeamer 7.9.1, the Ignore all or Assign all option can be chosen for attributes the name of which starts with a common prefix, e.g. ReqIF.* .

For choice attributes with discrete values, a target choice field needs to be assigned and each input attribute option must be assigned to a target choice field option.
If there is no pre-defined choice field option matching the input option, a new option can be created via -- New Option -- at the bottom of the value drop down list.

Import Status

Since codebeamer 9.5, codebeamer automatically adds the pseudo attribute ReqIF.ImportStatus to all Items to import.

Via this pseudo attribute, the ReqIF import status of an item can be mapped to a target item field, e.g. Import Status:



The ReqIF.ImportStatus to the actual item Status may also be mapped:



so that the status of all items, that become updated via ReqIF, will be set to Draft.

Using ReqIF.ImportStatus is optional, by default this pseudo attribute will be ignored.
It is used typically in conjunction with a special tracker view, to review all items, that were imported, updated or marked for deletion by a ReqIF import.

If the ReqIF.ImportStatus Deleted is mapped to a field value, then items deleted via ReqIF only have their field value set to Deleted, but the items will not be moved into trash.
codebeamer allows the user to review and decide whether to actually delete or keep these items.

If the ReqIF.ImportStatus is mapped to a target field, that target field should be cleared after completing the ReqIF import review.
If the ReqIF.ImportStatus target status of New items is not re-set, then subsequent ReqIF imports updating these items do not change the target status to Updated since the user did presumably not review the item yet, and is still regarded as New.

Remove/Restore items

In order for codebeamer, to recognize deleted objects or object deletions upon import:

  • the object (type) must have the special ReqIF.ForeignDeleted attribute,
  • and ReqIF.ForeignDeleted must be mapped to the Deleted flag/field of the target tracker.

Upon (re-)import:

  • Objects will be removed (moved to trash), if their ReqIF.ForeignDeleted is true.
  • Removed objects will be restored, if their ReqIF.ForeignDeleted is false.

Please note:

The simple absence of previously imported objects in a subsequent re-import does by default not remove the absent objects in codebeamer, to avoid unintended removals as in the following scenario:

  1. ReqIF Data is imported from peer A
  2. The imported data is forwarded to peer B
  3. Updated ReqIF data from peer A is imported, that contains new objects
  4. A response from peer B is imported
    • Since peer B does not know about any new objects, that were imported after the (last) forward to B, those objects are absent in the response


When importing ReqIF data into an existing project (see below), codebeamer 9.4 and newer allows to optionally choose, whether items in mapped target trackers, that were imported via ReqIF before, but are absent in the current ReqIF file/archive to import, should be removed (moved to trash), or not:




Consider the scenario depicted above before activating this option.



Relation type mapping

Input Relation Types must be mapped to codebeamer Association types and/or Reference fields.




Only the pre-defined Association types can be chosen from. Creating new Association types is not supported.

An input Relation type can also be bound to target Tracker Reference fields:



A Relation type can also be bound to more than one Reference field (in different types of trackers).
The actual target reference field will then be determined for each input Relation according to the actual type of the relation source/origin item.

A Relation Type can also have attributes, which must be either ignored or mapped to appropriate target Association fields.

There are 3 pre-defined Association fields:

  • Comment (Text) - Optional association comment
  • Propagate Suspects (Boolean) - Whether this association supports suspected link propagation
  • Suspected (Boolean) - Whether this association represents a suspected link


New custom Association fields can be created by right-clicking on the target field dropdown list and choosing New Field... from the popup menu.

Custom Association fields cannot be seen at the codebeamer GUI.


In order for codebeamer, to recognize deleted relations or relation deletions upon import:

  • the relation (type) must have the special ReqIF.ForeignDeleted attribute,
  • and ReqIF.ForeignDeleted must be mapped to the Deleted flag/field of the target association.

Upon (re-)import:

  • Associations will be removed (moved to trash), if ReqIF.ForeignDeleted is true.
  • Removed associations will be restored, if their ReqIF.ForeignDeleted is false.


The simple absence of previously imported relations in a subsequent re-import does not remove the absent associations in codebeamer.


Having finished the ReqIF import configuration, consider to [Save] the executed work before clicking on [Next].

Especially if there are lots of Item types and/or attributes to map (e.g. Importing from IBM Rational DOORS), several iterations may be needed until the import result is considered satisfactory.

Being able to Load (and refine) previously used input configuration can save considerable time and work.



Disable structural changes

As an OEM, that is exchanging requirements with suppliers via ReqIF, to make sure that suppliers

  • do not add new requirements to the original requirements documents,
  • do not remove some of the original requirements,
  • do not change the structure of the requirements documents,

then use the Disable structural changes option (since codebeamer 21.04 or newer) when re-importing feedback (use case 4) from the suppliers.



CB:/displayDocument/DisableStructuralChanges.png?doc_id=20608436&version=1&history=false&notification=false



Disable structural changes really only makes sense for OEMs in use case 4, when re-importing feedback (use case 4) from the suppliers, but not for suppliers, when (re-)importing requirements from OEMS (use case 1 and 4).


By selecting the Disable structural changes checkbox:

  • explicitly removed items or absent items will not be removed from the target trackers;
  • new items in the ReqIF will be ignored (not be added as new items to the target trackers);
  • structural item changes (re-ordering or re-grouping the parent child hierarchy) will be ignored;
  • the moving of items will be ignored.

All ignored structural changes will be reported in the import statistics under Failed.


If the Disable structural changes checkbox is selected and the import configuration is intended to be changed in such a way, it would result in explicit structural changes, e.g.

  • Change the target tracker of a Spec Object or Specification to a different tracker, other than - Ignore -,

then codebeamer asks whether to

  • Allow structural changes for this import (Yes), or
  • Cancel configuration change.


CB:/displayDocument/StructuralChangeConfirm.png?doc_id=20608451&version=1&history=false&notification=false



By allowing and making configuration changes, that result in structural changes, then the only way to Disable structural changes again, is to Cancel the import and start from scratch.

Import ReqIF data into an existing project


To import ReqIF data into an existing project:

  • Go to Admin ► General ► Import ► Import ReqIF...




In the upcoming File Upload dialog, choose the ReqIF file/archive to import:




In codebeamer 9.2 and older, ReqIF data can only be imported into an existing project,

  • if the project was created from a ReqIF file/archive and the specified ReqIF file/archive is a Re-Export from the same source,
  • or the project was exported as a ReqIF file/archive and the specified ReqIF file/archive is a return/response based on the original export.

Since codebeamer 9.3, ReqIF data can always be imported into an existing project,

  • even if the project was not created from ReqIF,
  • even if the ReqIF file/archive contains data from a yet unknown data source.



The data schema of the selected ReqIF file/archive is shown next, and input data needs to be mapped to target trackers:




If this is an import from a yet unknown ReqIF data source (according to the Conversation- and RepositoryId in the ReqIF Header of the ReqIF file/archive), then a unique name for the new ReqIF data source needs to be provided:




If this is an import of new or updated ReqIF data from an already known data source (according to the Conversation- and RepositoryId in the ReqIF Header of the ReqIF file/archive), information about the Last Import can also be seen from that source and the import History. Also the configuration used for that last import is automatically loaded and shown:





If there are multiple data sources for the same Conversation- and RepositoryId, then the one used for the Last Import is shown and pre-loaded, it can be switched to another one.

This import can also be stored under a -- New Source -- name.


It is not necessary, to explicitly Load the ReqIF import configuration from a file, because codebeamer will automatically load the last import configuration used for the selected Source.


It is not necessary, to explicitly Save the ReqIF import configuration to a file, because codebeamer will automatically save it to a file called Source.json in the specific ReqIF Import folder in the Project's Documents, where Source is the name the user assigned to the ReqIF data source.





When importing a ReqIF file/archive

  • that was already imported before (according to the unique Identifier in the ReqIF Header), or
  • that is older (according to the Creation Time in the ReqIF Header) than the last imported ReqIF file/archive from the selected Source

then, since codebeamer 9.5 and newer, an appropriate warning dialog is shown:





In general, it is not advised to continue here because the current project contents are most likely going to be overwritten with obsolete data.


Having a good reason (e.g. repeat the last import because the mapping of some new specifications or attributes has been forgotten), and deep knowledge and experience, the user may choose to ignore the warnings and continue, however, this is not advised.



This is visualized on the import configuration screen:





and also later in the import history:





In codebeamer 21.04 and older, ReqIF imports are executed synchronously.

After the import has finished successfully, statistics about the imported, updated or deleted items per target tracker are shown.

For target trackers, that were created by the import, only the number of Imported items will be shown, because there can be hundreds or thousands of items, and these are all items currently in the tracker. To see them, click on the tracker link.




For re-imports into tracker, that already existed before the import, see the items imported, updated or deleted, by clicking on the appropriate number:




E.g. Show the items, that were updated, including the changed field values:



codebeamer 9.2 and older used an automatically created baseline, to show the differences between the project before and after the import.

codebeamer 9.3 and newer will no longer create baselines upon ReqIF imports into an existing project.


Asynchronous ReqIF import in background

Since codebeamer 21.09, ReqIF imports will be executed asynchronously in the background.

Upon clicking on [OK] in the import configuration dialog, the import will be scheduled for execution:

CB:/displayDocument/ImportInBackgroundSubmit.png?doc_id=20608454&version=1&history=false&notification=false


asynchronous notifications are received later, as soon as the import has actually started:

CB:/displayDocument/ImportInBackgroundStarted.png?doc_id=20608433&version=1&history=false&notification=false

and finished:

CB:/displayDocument/ImportInBackgroundFinished.png?doc_id=20608427&version=1&history=false&notification=false


If outgoing email is configured, a notification email is also sent when a ReqIF import submitted by the user has finished:

CB:/displayDocument/ImportFinishedEmail.png?doc_id=20608448&version=1&history=false&notification=false


Notes:

  • Multiple imports can be submitted in parallel.
  • All imports will be executed in the order they were submitted to the queue.
  • For each project, there can be only one active ReqIF import (and export) at any time.



ReqIF Import History

Since codebeamer 9.4 and newer, the history of all ReqIF imports into a project is available, grouped by source:

Project ► Admin ► Settings ► General ► Import ► ReqIF sources





Clicking on a specific source shows the import history of that source:




To view the settings used for a specific import:

  • Expand the import
  • Click on Settings…

To view tracker items imported, updated or deleted by a specific import:

  • Expand the import
  • Click on the appropriate number of created, updated or deleted items in a specific tracker (row)

Export data as ReqIF

To export tracker items (Requirements, Use Cases, User Stories, Test Cases, etc.) from a project as a ReqIF archive:

  • Go to Project Admin page ► General tab
  • and choose Export ⯈ As ReqIF archive… .


In codebeamer 9.4 and older, Export As ReqIF archive opened a submenu where the user had to choose between

  • Forward… and
  • Back ToSource.


Since codebeamer 9.5, this submenu no longer exists.


Instead, the export Destination can be chosen in the upcoming dialog:

  • If the project has already been exported as ReqIF before,
    then the destination of the last export will be automatically pre-selected.
  • If the project has never been exported as ReqIF before, but there was already an import from a ReqIF source,
    then the source of the last import will be automatically selected as the destination for an export back to that source.
  • If there has never been a ReqIF import/export for that project before,
    then a New Destination is to be defined:



    • the Name of the destination must be unique within all ReqIF sources and destinations in the project.
    • the Type of the destination system is used to apply some destination specific logic upon export.
      • Only those destination types are listed, where codebeamer is able/required to apply some specific logic upon export.
      • If the type of the destination system is unknown, or the specific system is not listed, select Other.


Even if an existing Destination is preselected, another existing destination can always be selected, or a new one defined:

Choosing an existing destination will load the configuration used for the Last Export to that destination and also show date and time of that Last Export as well as the History of all exports to this destination:



If there has not been an export yet, the reverse configuration for an export back to the ReqIF source will be shown, because

  • A ReqIF source is also a destination for re-exports back to that source.
  • A ReqIF destination is also a source for replies from that destination.


When creating a new destination, the default configuration according to the selected destination type will be shown.


If the data has already been exported as ReqIF (from this or another project) and the export configuration saved into a file, that configuration can also be Load-ed and re-used. It is not necessary to [Save] the configuration to a file manually as codebeamer 9.5 and newer automatically remembers the export configurations for all ReqIF destinations.


To change the default value of ReqIF Export, see You must login to see this link. Register now, if you have no user account yet..

Select project baseline to export

In codebeamer 21.04 and older, only the current project data (Head Revision) can be exported.

Since codebeamer 21.09, the project baseline can be selected for export:




There is also the special -- Tracker specific -- baseline setting, that allows to choose individual baselines for each tracker to export:



codebeamer only allows the export of

  • Trackers, that exist in the selected project baseline
    • Fields, that exist in the selected tracker or project baseline

Select project contents to export

Only export data that the intended Destination system should see and can handle.


Select the tracker to export:



For each selected tracker, the user can restrict the export to items in a specific meta status or to items in a specific tracker view:



If none of the pre-defined meta status filters or tracker views is applicable, a new filter view can be created via -- New View -- from the drop-down list.


In case all tracker items are exported (Any status), the full tracker item hierarchy is exported.

When exporting only a sub-set of items, e.g. only Accepted requirements, parent items (e.g. Folders) might not be exported which result in the requirement to be exported as top-level item.


To preserve the (folder) hierarchy upon export, check Preserve hierarchy (since codebeamer 9.5 and newer):




Preserve hierarchy also exports all ancestors of the tracker items to export, even if they do not match the selected filter.


The user also needs to select, which attributes/fields of the selected tracker items should be exported:



codebeamer proposes a default set of fields based on the tracker type, however, More Fields... can be added, or the selected fields removed.

There is also the option to Select all or Remove all fields via the appropriate actions in the Fields header.


If an embedded table field is selected for export, it also needs to be selected which of the table's columns should be exported.

If codebeamer should also export information about tracker items, that have been removed, then the field Deleted must be selected.
This will include removed tracker items in the export, that will have their ReqIF.ForeignDeleted attribute set to true.
By default, codebeamer will not export tracker items, that have been removed.

Multiple trackers can be selected for export.


To export items from one tracker including related/referring items from another tracker, e.g.

  • Customer Requirements plus the derived System Requirements
  • System Requirements plus the verifying Test Cases

then use the References selector:




This way, codebeamer makes sure, that also the relations between the related/referring items are properly exported:




Additionally, the user can choose to export specific associations of the selected items, e.g. the dependencies of the Test Cases:




Only associations to other tracker items can be exported, and only, if the target items are also in the same export.


Information about associations, that have been deleted, will only be exported, if Deleted is selected under Fields.

This will include removed associations in the export, that will have their ReqIF.ForeignDeleted attribute set to true.


Since codebeamer 21.09 and newer, Trackers to export can be collapsed:




To expand/collapse all Trackers at once, right click anywhere in the Trackers column and choose Expand/Collapse All from the context menu.




Respond to a previous import

When selecting the Source of a previous ReqIF Import as the Destination for a new ReqIF Export, and there has not been a previous export to this Source/Destination yet, then the export is automatically configured to be the reverse of the last/previous import from that Source:







Previously imported data can be removed from the export, or locally added data can be added to the export.

To make sure,

then, since codebeamer 21.04 and newer, can choose to

  • Curtail (the export) to the last import

which means

  • only Trackers, Fields, References and Associations can be selected for export that were contained and not ignored in the last import.

Asynchronous ReqIF export in background

Since codebeamer 21.09 and newer, ReqIF exports are executed asynchronously in the background.

Upon clicking on [OK] in the export configuration dialog, the export is scheduled for execution:

CB:/displayDocument/ExportInBackgroundSubmit.png?doc_id=20608439&version=1&history=false&notification=false



Asynchronous notifications are received later, as soon as the export has actually started:

CB:/displayDocument/ExportInBackgroundStarted.png?doc_id=20608445&version=1&history=false&notification=false

and finished:

CB:/displayDocument/ExportInBackgroundFinished.png?doc_id=20608442&version=1&history=false&notification=false


If outgoing email is configured, then a notification email is also sent to the user when a ReqIF export submitted by the user has been finished:

CB:/displayDocument/ExportFinishedEmail.png?doc_id=20608430&version=1&history=false&notification=false


Only the user, that has started a ReqIF export, can download the exported ReqIF archive, either via

  • the link in the export has finished notification
  • the Download link in the export has finished email
  • the Download link in the destination's export history
    CB:/displayDocument/DownloadViaHistory.png?doc_id=20608424&version=1&history=false&notification=false
The exported ReqIF archive must be downloaded until the specified deadline (typically within the next two workdays) and is not longer available after that deadline!


The exported ReqIF archive must be downloaded until the specified deadline (typically within the next two workdays) and is no longer available after that deadline.



Notes:

  • Multiple exports can be submitted in parallel.
  • All exports will be executed in the order they were submitted to the queue.
  • For each project, there can be only one active ReqIF export (and import) at any time.

ReqIF Export History

Since codebeamer 9.5, there is also a history of all ReqIF exports out of a project, grouped by destination:

Project ► Admin ► Settings ► General ► Export ► ReqIF destinations …






Clicking on a specific destination, shows the export history to that destination:




To view the statistics and the settings used for a specific export:

  • Expand the export
  • Click on Settings …

The export statistics show the numbers of exported tracker items per tracker.
If also deleted tracker items were exported, their numbers are shown in a separate column.

ReqIF Export from Working-Sets

Since codebeamer release 22.10-LTS (GINA), the ReqIF export options have been extended to Working-Sets.

codebeamer allows the exportation of work items (trackers, items, fields, references) based on Working-Sets on export level.


A Working-Set selector box has been added to the Select project content to be exported as ReqIF overlay. The relevant Working-Set is to be chosen from the dropdown list:



The selected Working-Set with all its configurations and content is exported.




By clicking on the ReqIF destinations... ► Settings, the ReqIF export history indicating the latest exported Working-Set is displayed on the Export overlay in read-only mode:



This function has been developed for ReqIF exports only. For ReqIF imports, the target Working-Set is always the default Working-Set.


See also: Working-Sets

Tracker View-Based ReqIF Export

Since codebeamer release 22.04 (FELICITY), tracker contents can be filtered by applying different tracker views during exporting to ReqIF.


It is possible to select from the available

  • Default Views
  • Public Views - views shared with the user based on roles
  • Private Views owned by the user

for each tracker included in the ReqIF export.


In case of intelligent views, the export only contains the initial level of items. The hierarchy defined by the view is not included.
Selecting views with Show Children, Show Ancestor Items or Show Descendant Items options enabled, the parent/children items are also included in the ReqIF export. Each item is included once, without showing any hierarchy between them.


To choose from the tracker views available,

  1. click on the Select Tracker View link on the Select project contents to be exported as ReqIF overlay:

  2. choose the relevant view on the Select Tracker View overlay and click on [Select] to apply.


To avoid exporting wrong items, turn to the relevant Administrator for the correct write permissions of the used views.

See also: Tracker Views



Loading Saved Configurations

When loading a previously saved ReqIF export configuration with views,

  • the export is executed according to the current state of the selected view, therefore, the selected view is only a reference.
  • the selected view within the saved configuration file could be changed in the meantime. If the applied view has been changed, codebeamer warns the user to reload the view.

Configurable ReqIF Base ID

Since codebeamer 21.09 (EMMA) release, the ReqIF Base ID can be configured to ensure that valid ReqIF files are generated following a Host ID change.

This function is not supported since codebeamer release 22.10-LTS (GINA).


ID Definitions

  • ReqIF ID - A unique identifier for each and every ReqIF export and import, with the following structure: "CB-<Host ID>-<additional unique numbers>".
  • Base ID - The first part of the ReqIF ID, which can be set in the Application Configuration. If not defined, it is automatically set to "CB-<Host ID>" upon the first ReqIF import or export.
  • Host ID - It consists of the acronym of the Operating System used (WIN/LIN), and the MAC address.

Operation

Since codebeamer 21.09-SP5 (EMMA) and newer, the ReqIF instance identifier is read from the ReqIF section in the Application Configuration.

E.g.:

     "ReqIF" : {
         "identifier" : "CB-LIN-54-14-F3-67-2B-40"
     }



If there is no ReqIF section or ReqIF identifier defined in the Application Configuration, it is automatically set to "CB-<Host ID>" upon the first ReqIF import or export.

Porting

  • Porting a codebeamer 21.09-SP5 (EMMA) or newer instance to a new host preserves the existing ReqIF identifier since it is now ported with the database.
  • Porting an instance older than codebeamer 21.09-SP5 (EMMA) to a new host requires the upgrade of the codebeamer instance on the new host to codebeamer 21.09-SP5 (EMMA) or newer.
    Then, the old ReqIF identifier needs to be added to the Application Configuration of the new instance prior to executing ReqIF imports or exports.

See also: Application configuration