ReqIF support (again)

[mumbricht]

An important feature of requirements managers is the interchange of requirements documents, between teams, companies, and programs. ReqIF is the standard interchange format for this class of products, and I suggest that it may be worthwhile to integrate ReqIF support into Doorstop to improve interchange capability.

Reading #361 , apparently the earlier issue was the lack of a parsing tool. That now exists : https://github.com/strictdoc-project/reqif

Looking through both doorstop and the ReqIF spec, most of the functionality maps 1:1. The major issues are, as I see them, the handling of UUIDs and the preservation of extraneous data for round-trips.

ReqIF requires that all objects have a UUID that is preserved across time. This should in principle be stored in the file, same as links currently are, and global objects like SpecAttribute UUID's stored in the .doorstop.yml file.

Finally, ReqIF is an extensible standard, supporting ReqIFToolExtension data which could be literally anything. This data could be stored in a compressed format in the .doorstop.yml file, to be incorporated when unparsing back out into ReqIF.

I'm happy to take the lead in this, as we would like to integrate Doorstop into our toolchain, which requires ReqIF functionality for the Requirements : MBSE interface.

[stanislaw]

Reading #361 , apparently the earlier issue was the lack of a parsing tool. That now exists : https://github.com/strictdoc-project/reqif

Author of this library here. Thanks for considering it for your implementation. I have put in a considerable time to make it robust and wish I could do even more in the future.

If you would need any support, I am happy to help. Note that reqif is a satellite project of StrictDoc which used to be a fork of Doorstop several years ago but is now an independent project.

If you are going to implement a ReqIF interface for Doorstop, we could ensure that both Doorstop and StrictDoc can talk the same ReqIF language. You probably know at this point that ReqIF does not provide a single schema recommendation, so there is a zoo / "wild west" of several schemas possible, and I collected them over time in the reqif's integration tests. I would be great to gather enough people someone seriously interested in this and agree on a good single ReqIF schema that would scale across several tools.

And finally, note that https://github.com/DSD-DBS are working on integrating Capella MBSE with StrictDoc, and independently from StrictDoc's reqif, their tools are ReqIF-aware. Which MBSE tool are you working with?

If answering this gets too detailed, feel free to write me an email.

cc @vik378

[mumbricht]

Happy to hear that you're willing to help. I think I have a handle on what needs to be done, but I'll get in touch if I have questions.

We are indeed using Capella MBSE, although Doorstop's atomized approach is interesting for downstream engineering purposes (linking requirements directly to individual parts/systems without the need to parse a large document). I will look into StrictDoc more in depth to see if its a good fit.

Finally, I am 100% on board for standardizing the format across tools. I think these loosely defined interchange formats (like STEP) cause more problems than they solve, when compared to strictly defined formats. That said, it's worth avoiding format wars.

[salvioli]

Just to touch base on this, is this extension still being worked on or there is not enough bandwidth to work on ReqIF support? I am considering to propose the adoption of doorstop within our workflow to replace IBM DOORS but we still need to have interoperability towards it. We could do with CSV/XSLX but supporting this would make the workflow smoother.
I am available to support in the implementation if you (@mumbricht @stanislaw) are still working on this.

[mumbricht]

Hi @salvioli,
I never got feedback on this, so I was waiting to do this when I had the need. If you need this done, I'll make it a priority.
That said, I'm not part of the doorstop team so all I can do is make a PR when its ready.

[salvioli]

Thanks for the quick feedback, makes total sense. An implementation on a fork would be more than sufficient for me to demo this. As I mentioned I am available to support.

[mumbricht]

@stanislaw
I'm finally getting around to implementing reqif in doorstop, and I had a question as to your use of UUID's.
ReqIF standard section 10.2, "Identifiers", talks about "global unique identifiers", which is not strictly UUID's. UUID's is probably a good approach though, so that's the direction I'm going in (see https://github.com/Mumbri-systems/doorstop/blob/develop/reqs/REQ021.yml).
Do you have an opinion on the use of UUID's vs local UID definitions?

[stanislaw]

Hi @mumbricht,

The UUID is not the same as UID. To recognize this, StrictDoc supports a concept of MID (machine identifier) which maps directly to the UUID of ReqIF.

Note that some ReqIFs produced can maintain both UID and UUIDs separately but also there are cases when only UUID is used for linking as this ticket demonstrates: strictdoc-project/strictdoc#1935. In that case, there are documents with non-unique UID but they are still part of the same ReqIF because their UUIDs are different.

I don't know whereto you would map ReqIF UUID in Doorstop. In StrictDoc, I map UUID to MID because that's what I made StrictDoc to support to handle this.

[mumbricht]

@stanislaw
So in strictdoc, MID + UID guarantees uniqueness, as opposed to a UUID? My basic idea was to add an item attribute to store the UUID, potentially as a compressed string. If the string is compressed, I can add some mapping information without cluttering the .yml