Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ReqIF support (again) #646

Open
mumbricht opened this issue Apr 4, 2024 · 2 comments
Open

ReqIF support (again) #646

mumbricht opened this issue Apr 4, 2024 · 2 comments

Comments

@mumbricht
Copy link

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
Copy link
Member

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
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants