Overview, use case:

We want to exchange requirements with a customer who uses DOORS Next, too. We have already set up a project area with the same requirements i.e. same artifacts and same attributes as our customer.

Our customer modifies some of those attribute values of some artifacts. Then we want to synchronize our databases (between customer and us). For this, our customer exports his modules in ReqIf format, sends it to us, and we export it into our existing modules/project area.

Then the other way round, back and forth. We modify, export ReqIf, customer imports it, our changes are reflected in his system. He modifies, exports ReqIf, we import it, his changes are reflected in our system. Etc.

Current behavior:

It is possible to mess up our project area for subsequent ReqIf imports with no possibility to fix it with the following steps:

- Customer exports ReqIf; his ReqIf export contains attributes with the same names as in our module, but it does not contain URIs assigned to those attributes (he should not do this, but it can happen accidentally)

- When we import, the attributes are being "duplicated", i.e. for every attribute, a second attribute is created with an automatically generated, similar name, and the value from the ReqIf is assigned to that duplicated one

- We tell our customer that he shall provide a better ReqIf with properly assigned URIs to all attributes, which match the attributes and URIs of our project area. He does so, we try to import this "proper, fixed" ReqIf export

- Attributes are being "duplicated" again, even though everything is properly defined this time (only because we had imported one faulty ReqIf export once in the past)

--> More details can be found in support case TS011937760 https://www.ibm.com/mysupport/s/case/5003p00002m1CDNAA2/issues-with-reqif-import-for-20p?language=en_US

Expected behavior:

- It is NOT possible to mess up a project area like this. If an import with a properly defined ReqIf with attributes with properly assigned URIs is done, it works properly without duplications, independent of what had been imported before, independent of whether there had ever been a faulty ReqIf import before or not. Nothing exists, hidden from users (here: that "ReqIf mapping table"), which has any influence on the behavior of subsequent ReqIf imports (or on anything else)

- Or: Users have a possibility to delete or reset that mapping table in order to be able to do subsequent ReqIf imports properly, as if they were doing those import for the first time, without any influence from prior (potentially faulty) ReqIf imports