ReqIF2Excel

Tool notes — what ReqIF2Excel expects from each source tool

ReqIF2Excel never keys on a tool name. It matches XML by local name, so any XHTML prefix works, and it resolves an attachment by trying, in order: the path relative to the .reqif that references it, the same path from the archive root, then a unique file-name match anywhere in the archive. If all of that fails the reference becomes a visible MISSING marker plus an error — never a silent drop.

The notes below record the shapes each tool is known to produce and where they land in the workbook. A shape that is not listed still converts: it falls back to “extracted, linked, listed on the Attachments sheet”.

IBM DOORS classic (9.x ReqIF export)

Export shape Where it lands
REQ-IF-TOOL-ID = IBM Rational DOORS Summary sheet, “Source tool”
reqif-xhtml: prefixed rich text,   spaces Flattened text; non-breaking spaces normalised
ReqIF.ForeignID (absolute number) Foreign ID column
ReqIF.ChapterName (object heading), ReqIF.Text (object text) First attribute columns
ReqIF.ForeignCreatedBy / On / Thru, ReqIF.ForeignModifiedBy / On Their own columns
Module attributes on the SPECIFICATION (…_CREATEDBY-DOORS-MODULE ids) Specifications sheet
<reqif-xhtml:object data="x.png" type="image/png"> Picture on the row + [IMG n: x.png]
OLE object: an outer object (application/…) wrapping a preview object Outer = [ATT n] saved file, inner = [IMG n.1] shown picture, both traced, Preview of filled
DOORS tables: nested SPEC-HIERARCHY with IS-TABLE-INTERNAL="true" Rows kept, Table row = yes, indentation preserved
One SPEC-OBJECT-TYPE per DOORS object type (a module can hold a dozen) Columns are the union of the attributes used in that specification
Link modules: SPEC-RELATION + RELATION-GROUP Relations sheet (Group = link module name) + Links out / Links in
Attachments at the archive root Resolved by name
A picture nested deeper in an object’s fallback content (inside a <p>, or as an <img>) Collected as well: no depth of nesting hides a file

Sample reproducing all of it: sample_data/doors_classic_like.reqifz.

Measured against real DOORS 9 exports

Two real module exports (about 1,000 and 1,800 objects, hierarchies six and seven levels deep, 17 and 87 attached files) convert in about two seconds each with every file traced to its object. They showed six further shapes, all handled:

Real-world shape What the converter does  
Indentation written as nested <blockquote> elements, up to four deep Each level indents its lines by four spaces  
Table cells whose content is wrapped in <div>/<p> blocks Each row stays on one line, cells joined by ` `; without this every cell landed on a line of its own
The SPEC-OBJECT-TYPE carries no LONG-NAME The Type column is left blank instead of repeating an internal identifier on every row; DOORS’s own Object Type attribute is a column of its own  
A module declaring dozens of attributes its objects never fill Those columns are hidden (never removed) and listed on the Summary sheet  
An embedded BMP carrying its own PNG preview The BMP is shown; the preview is saved and traced but not shown a second time  
Several drawings of one kind in one object See below  

The duplicate-reference defect. DOORS names the native files of an object’s embedded drawings <module>_O<n>_inline.wmf, …_inline_1.wmf, …_inline_2.wmf, and their previews …_inline.png, …_inline_1.png, … — but it can write the first drawing’s file name into the rich text of each later one, and leave the correct file in the archive with nothing pointing at it. Taken literally, the later drawing would be traced to the first drawing’s file. This was confirmed by rendering the drawings: the orphaned file is the one that matches the later preview.

When a later object of the same requirement references a file an earlier object already used, the converter looks for an orphaned sibling, <same name>_<n><same extension> in the same folder, and uses it only if no rich text anywhere in the archive references that sibling and no requirement has used it. The repair is reported as a warning and noted on the Attachments row. If no such orphan exists, the two objects simply share the file, as a genuinely repeated picture would.

Layout columns (Exported_Layout_DXL_…) arrive as ordinary attributes and become ordinary columns; in one export such a column carried each requirement’s human-readable key.

Codebeamer (tracker / document ReqIF export)

Export shape Where it lands
REQ-IF-TOOL-ID containing “codeBeamer” / “Intland” Summary sheet
xhtml: or reqif-xhtml: prefixed rich text Flattened text (the prefix is irrelevant, matching is by local name)
An embedded Office document: an outer object (.docx, .xlsx, .pptx, .emf, .wmf) wrapping a preview object (.png) Outer = [ATT n] saved file, inner = [IMG n.1] picture shown on the row, both traced, Preview of filled
An empty LONG-NAME, with the readable key in ReqIF.Name The Name column falls back to it (name_attribute_preference)
A machine token in an object’s fallback text (name.WyJkb2N4Ii…) Stripped from the Alt text column
One SPEC-OBJECT per work item; fields under their tracker labels (ID, Summary, Description, Status, Priority, Assigned to) Attribute columns; ID becomes Foreign ID through id_attribute_preference
ReqIF.ForeignID / ReqIF.ChapterName / ReqIF.Text when the requirement mapping is used Same columns as DOORS
<xhtml:img src="attachments/…" alt width height>, including nested sub-folders Picture on the row, path resolved relative to the .reqif
Inline base64 data: images Decoded, saved as inline_<n>.png, shown and traced
Wiki tables → xhtml:table, code blocks → xhtml:pre cell | cell lines, code kept verbatim
Item cross-references <xhtml:a href> text (href) in the flattened text; if the link points at a file inside the archive, that file becomes an attachment of the linking requirement
Parent/child items in a document The specification hierarchy: Outline, Level, row grouping
Associations (depends on, derived from, verifies …) Relations sheet with the association name
Multiple-choice fields Multi-valued enumerations joined with ;

Sample reproducing all of it: sample_data/codebeamer_like.reqifz.

Measured against a real export

A genuine Codebeamer 2.2.1.3.1 export (a system design document, 664 requirements, 4 MB of XML, 384 attachment files, 34 MB) converts in about one second with no error and no warning: 386 embedded references resolved, 193 Office/vector documents saved and linked, 193 preview images placed on their requirement rows, every marker present in the requirement text it belongs to, and every extracted file byte-identical to the archive member it came from. That export is flat (one level, no SPEC-RELATIONS), which the workbook reproduces faithfully — an empty Relations sheet there means the source carries no links, not that any were dropped.

Note on picture proportions: some tools export a preview whose own shape differs from the document it previews. ReqIF2Excel never reshapes anything — files land on disk exactly as they were stored, and the picture shown in the sheet keeps the file’s own proportions to within a fraction of a percent. If a preview looks squashed, open the extracted file: the same shape there means the source stored it that way.

Other tools seen in the regression corpus

sample_data/public_fixtures/ holds real exports from DOORS, Polarion, Sparx Enterprise Architect and the Eclipse RMF conformance suite (including a .reqifz that splits requirements and relations across two .reqif files, and archives carrying an unreferenced attachment). All of them are converted by the test suite on every run, and each one’s embedded-object count must match the workbook exactly.

Polarion exports use the xhtml: prefix with ReqIF.* attribute names and are covered by the same paths as Codebeamer.

Adding a real export

Drop any .reqif / .reqifz into sample_data/real/. The test suite picks it up automatically and requires it to convert with no exception and with an attachment count identical to the number of embedded references in its XML.