DOORS-DNG Synchronization
Accepted answer
It's actually a whole lot more complex than that in terms of setting up. Once you have it set up it's quite straightforward.
- you need to define which side will be the 'source of truth' (SoT), DOORS or DNG. Any changes to schema or to ReqIF package details need to be consistently made on the SoT side
- you need to lock the data you intend to interchange or merge, via the ReqIF package definition on the SoT side. This will not lock the data on the DNG side but locks it on the DOORS side
- when you import a ReqIF into the DOORS side, you first bring it into an empty folder, and then you need to merge it. This will unlock the data on the DOORS side, so you then need to do a fake export to re-lock the data. You won't be able to merge after an import until the data is locked again
If the SoT is going to be DOORS, then:
- you need to determine what metadata will be exchanged, and you then need to make sure any attributes, data types and enumerated values are defined EXACTLY the same way across all the modules you intend to interchange. For attributes, the data type must match exactly (text vs string is a gotcha here - they are not the same in DOORS but are in DNG). For enumerated values, you need to have exactly the same set of names, with the same numerical values, in the same order. Note that if you leave all the numerical values as zero, this will create warnings in DNG when the types are defined
- make sure you set the correct attribute level - module or object, or both. I've seen a lot of junk attributes because everything was defined at the module level as well as object level
- you need to define the attribute URI mapping out at the DOORS database level for all attributes you intend to exchange. One good thing here is that the mappings will match up as you add attributes from multiple modules - if they don't match up, then that means they are not exactly the same in that module, so I find it really useful to map one module at a time
- when you publish the mapping it will set the attribute URIs, but there's a nasty bug in DOORS and it does not set the data type URIs or the enumeration URIS, despite appearing to do so in the mapping window. You have to manually set each module's datatype and enumeration URIs. I ended up building a DXL script to do this
- in many ways it's best to create a master module with all the attributes/datatypes/enums completely defined and mapped, and then use that to create new modules in DOORS, or to make the existing attribute data consistent. You then open up an existing module, import the perfectly defined attribute types (rename any clashes first), then copy the data from the old attribute to the new. This is the only way to fix mismatches like text and string and by using DXL it is a lot faster than editing the types and enums etc.
- I find it really useful to create a view that shows all the attributes you want to exchange, and name it the same in each module. Then you can simply build the ReqIF definition by selecting the view in each module and locking the contents of that view.
- I also find it useful to create two views and two ReqIF definitions. One that contains the requirement text and all the attributes you may want to see in the other system, and a second stripped down one that contains just the attributes you will regularly exchange. Makes it much faster to import/export
3 other answers
Yes - look for REQIF.
https://www.ibm.com/docs/en/ermd/9.7.2?topic=tutorials-use-reqif-move-data-other-requirements-tools
Plus look for REQIF in the DOORS 9 and DOORS Next documentation.
Best regards,
David
David
As David mentioned, ReqIF is the "official" way to do bidirectional synchronization of requirements between DOORS Classic and ERM-DOROS Next.
There are a few things to note to avoid surprises.
1) define a type mapping in DOORS
The scope for attribute types is module in DOORS whereas the scope for attribute types is project area in ERM-DOORS-Next.
If there are attribute types of the same in different modules in DOORS, without mapping, after importing ReqIF into ERM-DOORS-Next, "duplicate" attribute types will be created.
2) Make sure you lock the data in DOORS so that you can merge the round-trip ReqIF file from ERM-DOORS-Next
Data not locked in DOORS will not be updated (via merge) by the ReqIF round-trip ReqIF file from ERM-DOORS-Next.