ReqIF Exchange with a Client or Supplier

What an exchange is

ReqIF is the format an OEM or client and their supplier pass back and forth: the client sends a requirements specification, the supplier answers it, the client merges the answers, and the loop repeats. That loop, not the single file, is what the format exists for, so ReqTwin models it as an exchange: one named conversation with one partner over one project, carrying an ordered series of revisions in both directions.

Every import belongs to an exchange. Dropping a file creates one automatically, named from the file's own header, with the partner editable afterwards. There is no separate "just import this once" path, because a file imported that way turns out later to be unable to round-trip.

Reading a file is free

Drop a .reqif or .reqifz on Exchanges under a project. The file becomes a page of its own showing everything it contains: the specifications and how many rows each holds, the object types and what they become, the attribute mapping, and everything carried but not modelled.

Nothing is written to your register at this point, on any plan. You can open a file a client emailed you, read what is in it, and see exactly what would change, before deciding anything. Applying it to the register needs a Professional or Team plan.

Where each field comes from

The largest question on the way in is which of the external attributes is your requirement text, which is its status, and so on. One file might declare a hundred and six attributes across fourteen object types, so ReqTwin resolves it down a fixed ladder, first hit wins, per field and per object type:

1. An exact standard name. ReqIF.Text is the body, ReqIF.ChapterName is a heading's body, ReqIF.ForeignID is the id the partner's team quotes in an email. Case is ignored. A file ReqTwin itself wrote comes back through the same rung on its ReqTwin.* names. 2. A published meaning. IBM tools annotate each attribute with an OSLC URI. It settles exactly one real conflict: DNG emits both ReqIF.Text and ReqIF.Description, and nothing else can say which is the body. 3. The same name as the internal field. Status, Priority, Owner, Rationale, ignoring case, spaces, underscores and hyphens. 4. The datatype, as a filter. Only rich text or a string can be the body; only an enumeration or a string can be a status. A date can be none of them. This rung never picks anything, it only rules things out, which is why an attribute genuinely called Priority is refused when it holds a number rather than a list. 5. The only one left. If exactly one attribute survives the filter for a field, it is taken. 6. Otherwise you are asked.

There is deliberately no fuzzy matching. Letting Object Text match "text" also lets Text Colour match it, and a body field bound to the wrong attribute is wrong silently: it flows into search, into the AI Insights answers and into the handover pack, and is noticed much later if at all. An empty row you fill in is better, and reaching that last rung is normal rather than a failure.

The mapping belongs to the exchange, and every revision freezes the one it used. Correcting it applies to the next file that arrives and never to files already read. That is what keeps a correction from looking like the partner rewrote the whole specification.

Answering these questions changes what the file means, so the file has to be read again to answer them, and on a specification of several thousand rows that takes a while. Your answers are therefore held until you ask for them: bind as many attributes, dispositions and headings as you like, each marked Not read yet where you gave it, and Read again spends a single read on all of them. Until then the counts on the page are the ones the last read produced, which is why a review cannot be opened with answers still waiting.

What becomes a heading

Heading-ness is a property of the partner's object types, shown in the Object types table before anything is imported, so you can disagree with it while it is still cheap. ReqTwin proposes one by reading what the file states rather than guessing from shape: an object type actually named "Heading" or "Chapter" is one; an object with a chapter name and no body text is one, but only in files where no type says so by name.

It never infers a heading from a row simply having children under it. Real exports put requirements under requirements routinely, and scored against the real answer that rule both misses and invents headings by the dozen. A file with no heading signal at all imports flat, and there is a single toggle to override that, off by default.

Section numbers are always ReqTwin's own, computed from position. They may disagree with a number printed inside the body text, exactly as they already do for anything imported from Word or PDF.

What happens on a second file

Requirements are matched on the identifier the standard requires a tool never to change. Matching is scoped to the exchange, so one requirement can carry a different identity with your client and with your subcontractor at the same time.

Three rules matter more than the rest:

A requirement missing from a file has not been deleted. ReqIF has no way to say "this file is everything", so absence is genuinely ambiguous between deleted, moved out of scope, and a partial export. DOORS ignores absence for the same reason. Those rows are counted and left alone. A deletion only ever arrives as an explicit marker on an object that is still in the file, and even then it is a proposal you accept or decline.

A change is measured against the last external value received, not against what the register now holds. ReqTwin stores those last-seen values, so "changed externally" and "changed internally" are separate questions with separate answers. When both are true, that field is a conflict, and Apply is refused until every conflict is decided.

Nothing reaches the register until you press Apply. Decisions are saved as you make them, so a review can span days and survive a closed tab, and abandoning one costs nothing at all.

Reviewing

A revision is not read as one queue. A file with thousands of rows is a number nobody finishes, so the review screen cuts it at its own joints and works a heading at a time: one requirement on screen, that heading's own progress above it, and the file's total kept small because it is context rather than the job in hand. Reaching the end of a heading stops on a card that says so, rather than rolling straight into the next one and hiding the moment worth marking. The Headings button opens every heading in the file, decided-count and all, to jump to any of them directly.

Changed fields are decided in place and the unchanged ones stay visible under them, so a status move is judged against the text it belongs to rather than in isolation.

Apply is one transaction. The audit trail records the change as coming from the exchange rather than from whoever pressed the button, so an Audit Trail sheet sent back to a client does not claim your engineer wrote the client's text.

Replying

An export is the full state of every document in the exchange. There is no scope control, deliberately: ReqIF has no notion of a delta, so a narrowed file is a full file with rows missing, and whether the receiving tool treats those as deletions is a convention rather than a rule.

The reply sends the external model back, not an internal one. It re-declares the partner's own object types under the partner's own identifiers and returns every attribute that arrived, including the ones ReqTwin does not model, so the partner's tool merges it field by field into the model it already has. A field you have not touched is returned byte-for-byte as it arrived, which means the original formatting, tables and images survive the round trip untouched.

ReqTwin writes the file. It does not send it. You download it and send it yourself. The note you type when writing a reply is not a message ReqTwin delivers: it rides inside the file, and the partner reads it on opening the file in DOORS or Polarion. That is why an outbound revision reads as *Written* rather than *Sent*.

Outbound files are validated against the ReqIF schema before you get them, and a file that fails is not handed over. Inbound files are deliberately not held to the same standard, because real exports from real tools routinely fail strict validation and refusing them would refuse most of the files clients actually send.

Limits

A file can be up to 20 MB of XML and 12,000 requirements, or 50 MB as a .reqifz archive. Attachments inside an archive are carried through untouched and put back into the reply, so images keep working, but they are not unpacked into ReqTwin and there is nowhere to view them.

Stored files stay for the life of the project. A ReqIF file is the only record of what a partner actually sent, so nothing expires it and no single revision can be removed.

Deleting an exchange is the one exception, and it is deliberately blunt: it removes the whole conversation, every revision and both directions' files with it. Requirements already applied stay in the register, but nothing then remembers which of the partner's identifiers those rows came from, so that partner's next file arrives as an entirely new specification. It is there for a file dropped on the wrong partner, not for tidying up.