ros-safety / safety_working_group

ROS safety working group repository
http://www.ros2.org/safety_working_group/
36 stars 7 forks source link

Alternative to Doorstop? #33

Open fkromer opened 2 years ago

fkromer commented 2 years ago

StrictDoc could be an alternative to Doorstop for VCS based requirement management.

vmayoral commented 2 years ago

I wasn't aware of StrictDoc, good one!

I used Doorstop for a couple of projects after it was presented in the group in the past. I was looking at the docs in search for a comparison between both and found the following which might be interesting for the rest:

From https://strictdoc.readthedocs.io/en/stable/strictdoc.html#strictdoc-and-other-tools:

The first version of StrictDoc had started as a fork of the Doorstop project. However, after a while, the StrictDoc was started from scratch as a separate project. At this point, StrictDoc and Doorstop do not share any code but StrictDoc still shares with Doorstop their common underlying design principles:

Both Doorstop and StrictDoc are written using Python. Both are pip packages which are easy-to-install.

Both Doorstop and StrictDoc provide a command-line interface.

Both Doorstop and StrictDoc use text files for requirements management.

Both Doorstop and StrictDoc encourage collocation of code and documentation. When documentation is hosted close to code it has less chances of diverging from the actual implementation or becoming outdated.

As the free and open source projects, both Doorstop and StrictDoc seem to struggle to find resources for development of specialized GUI interfaces this is why both tools give a preference to supporting exporting documentation pages to HTML format as the primary export feature.

StrictDoc differs from Doorstop in a number of aspects:

Doorstop stores requirements in YAML files, one separate file per requirement (example). The document in Doorstop is assembled from the requirements files into a single logical document during the document generation process. StrictDoc’s documentation unit is one document stored in an .sdoc file. Such a document can have multiple requirements grouped by sections.

In YAML files, Doorstop stores requirements properties such as normative: true or level: 2.3 for which Doorstop provides validations. Such a design decision, in fact, assumes an existence of implicitly-defined grammar which is encoded “ad-hoc” in the parsing and validation rules of Doorstop. StrictDoc takes a different approach and defines its grammar explicitly using a tool for creating Domain-Specific Languages called textX. TextX support allows StrictDoc to encode a strict type-safe grammar in a single grammar file that StrictDoc uses to parse the documentation files using the parsing capabilities provided by textX out of the box.
fkromer commented 2 years ago

I wasn't aware of StrictDoc, good one!

Thanks.

I used Doorstop for a couple of projects after it was presented in the group in the past.

I had a first (evaluating) look at Doorstop a couple of years ago as well. However I was not completely happy w.r.t. the development workflow.

I was looking at the docs in search for a comparison between both and found the following which might be interesting for the rest:

I've written a blog post about StrictDoc and Doorstop this weekend cause I'm stumbling over this topic for years. Head over to Text based requirement management with StrictDoc - …in Python and Embedded System projects. It's probably of interest for you as well.

For a VCS based workflow (diffing versions, etc.) the fact that with StrictDoc one usually uses a single .sdoc file eases a lot of things. The way how requirements need to be organized with Doorstop in folders and files (one single requirement per file!) has prevented me from actually using Doorstop. However this is a matter of taste of course.

Have you been happy with Doorstop so far?

vmayoral commented 2 years ago

Have you been happy with Doorstop so far?

My experience with Doorstop has been acceptable. Exporting capabilities of Doorstop weren't great, so I ended up building a simple script that used the library and generated Markdown tables out of the requirements within every release, for traceability. This helped quite a bit monitor progress and I see StrictDoc has put decent work on export capabilities.

Played around with the example and got impressed.

To be honest, I haven't tried anything else so my opinion is very limited at this point. That said, next time I engage into a project with safety or security requirements, StrictDoc sounds like the way to go!