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:
• Select New Project from the Codebeamer Projects menu.
• Select Create a new project.
• Attach the ReqIF file (*.reqif) or archive (*.reqifz) to import.
On the next screen, the name of the new project can be added, the ReqIF data can be mapped to import to target trackers in the new project. The object model found in the ReqIF file to import is displayed.
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 Specifications:
• If a Specification Type is used exclusively by one Specification, the Specification 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. 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. 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 (For example, 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, for example 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: > > > , 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, for example 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, for example 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, for example,. Heading , Information, Requirementetc.
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.
For example, 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, for example Actor.
These separate Item Types should typically be mapped to appropriate config item trackers, for example, Actor.
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.