ReqIF: When DOORS Attachments Vanish After Import

You export a module from IBM DOORS or DOORS Next Generation as ReqIF (.reqifz), import it into another requirements management tool, and the text comes through fine — but the embedded images and objects stay blank. This is a classic ReqIF interchange issue, and the cause is subtler than mere tool incompatibility. This article explains the cause of the problem and offers a ready-to-use utility to fix it.

In short

A .reqifz file is a ZIP archive containing Requirements.reqif plus all the attachments. DOORS stores those attachments without a file extension (their names are GUIDs such as _3dcc85d5-...). The target tool relies on the extension to know how to render a file: with none, it displays nothing. The utility presented here — change.bat + change.ps1 — detects the real type of each attachment from its binary signature, restores the correct extension, updates every reference inside Requirements.reqif, and rebuilds a re-importable .changed.reqifz archive.

The problem

ReqIF (Requirements Interchange Format) is an OMG standard designed precisely to exchange requirements between heterogeneous tools. In practice, exchanging the text works well; it is the embedded attachments — screenshots, diagrams, OLE objects from Word or Excel — that break during a DOORS ↔ other-tool round trip.

The flow is as follows: DOORS produces a .reqifz archive containing the Requirements.reqif XML document alongside the binary attachment files. Those files are named after a unique identifier (a GUID) and carry no extension whatsoever. The importing tool determines how to render a file from its extension; without one, it has no way to know the file is a PNG or a PDF, and shows nothing.

Why it breaks

Three mechanisms combine to produce this outcome.

Storage without an extension. This is the immediate cause. DOORS exports attachments under their internal name (a GUID), with no type suffix. A strict target tool will not guess the type from the content and relies solely on the extension — which does not exist.

OLE object previews. In line with the ReqIF standard, an object that is not an image (an Excel table, a Word document) is wrapped in a preview image. You therefore find pairs of files: a base file declared type="text/rtf" and its _<guid>_alternative_image.png declared type="image/png". References are made in the XML through <object data="name" type="mime/type"> tags. A DOORS export option also converts some OLE objects to .rtf, which adds further variety to the types present.

The MIME type is not trustworthy. One might be tempted to rely on the type MIME declared in the XML to rename the files. That is a trap. On a real export of 461 files, 55 (12%) were actually PNGs but labelled text/rtf by DOORS — confirmed with the file tool. Renaming those files by their MIME would have turned them into .rtf and broken their display. The binary signature (the magic bytes) is the only source of truth; MIME serves only as a fallback for exotic types the signature does not cover.

The solution

The utility comes down to two files that must sit in the same folder: change.bat, the launcher, and change.ps1, which holds all the logic. It works as follows: it extracts the archive, detects the real type of each attachment from its binary signature (falling back to MIME where needed), renames each file with the correct extension and updates all its references inside Requirements.reqif in a single pass, then rebuilds a <name>.changed.reqifz archive ready for re-import. The original file is never modified.

Two implementation details are worth highlighting. Name replacement in the XML is safe against nested names: a base file’s name is never altered inside the longer name of its _alternative_image.png preview, and the .reqif encoding is preserved through byte-for-byte read/write. Furthermore, the .bat launcher loads the PowerShell code in memory, which bypasses an ExecutionPolicy set to Restricted — so the utility runs even on a workstation locked down by group policy.

Usage

From a command prompt, in the folder containing the .reqifz:

change.bat "MyFile.reqifz"

The result is a MyFile.changed.reqifz file created next to the original. Keep the quotes if the path contains spaces.

Supported file types

Detection covers images (png, jpg, gif, bmp, tif, emf, wmf), documents (pdf, rtf), recent Office in OOXML format (docx, xlsx, pptx) and legacy Office in OLE format (doc, xls, ppt). A file whose type is not recognised is left untouched rather than being given an extension blindly. On the real validation export, the utility processed the whole set with no unrecognised type and no inconsistency introduced, updating a 15 MB .reqif in roughly 0.3 seconds.

Other approaches

The script is an effective workaround, but it is not the only path. Depending on your leeway, fixing the problem further upstream may be preferable.

One important caveat: Jama’s documentation explicitly advises against renaming attachment extensions. The script therefore owns its status as a workaround, specific to a given DOORS export / target-tool pairing. If you can act at the source or choose a compliant importer, those options are more durable.

Downloads

The two files of the utility, together with its documentation:

change.bat — the launcher (the one to run)
change.ps1 — the detection and rebuild logic
README.md — full documentation (prerequisites, troubleshooting, technical notes)

Keep change.bat and change.ps1 in the same folder. Prerequisite: Windows with PowerShell 5.0 or later (present by default on Windows 10/11).

Sources

• Why OLE object is not visible after importing ReqIF file into DOORS — jazz.net
• ReqIF roundtrip to DOORS NG — problem with images — reqif.academy
• ReqIF export without images — jazz.net
• Handling OLEs and RTF Files in DX Imports from DOORS to Jama — Jama Software
• ReqIF Import/Export — Polarion
• Import ReqIF — ReqView
• Requirements Interchange Format — Wikipedia