Working group meeting 20200528
- Doorstop does not support one-to-many for software to implementation. We would need to send in a patch.
- Impact analysis of requirement changes one requirements is already supported in Doorstop, but impact analysis through to implementation is not supported. The work done by Ternaris is relevent here, as they have similar capability already.
- Doorstop does not currently differentiate between verification requirements and other requirements. This means that all the verification tracing is possible, but it is difficult to identify verification-related information separate from implementation-related information. Instead of the simple textual search that Doorstop has, we might want to have a satisfies link and a verifies link.
rmtoo is effectively a weaker, older, unmaintained version of Doorstop. It came from the Automotive Linux work on SIL2 Linux. We might be able to get some ideas for change management, linking, tracing, etc. from it.
- CI integration (from Philipp)
- Testing CI integration using Doorstop’s checking for tainted requirements (impact analysis) and identify requirements that need to be reviewed due to a change in parent requirements.
- Currently have CI set up so that the build fails if there are unreviewed, impacted requirements.
- A trace report is also generated by the CI, e.g. https://maplessai.gitlab.io/external/requirements-testing/. This is useful for reviewers to do their reviewing.
- Merge request templates should have a checkbox for requirements being atomic, unambiguous, etc., and traced requirements being reviewed.
- As a tool, Doorstop looks useable. What we need to think about now are processes, such as when requirements must be reviewed, etc.
- We cannot prescribe processes for other projects, but we could document best practices for using Doorstop.
- We could look to adding something about design documentation and requirements management to REP 2004. We must have tools and processes ready to go before we propose the changes, and probably a working example with one of the core packages, e.g.
rmw due to its nature as an interface library and the potential interest of ADLINK.
- This is a case of after-the-fact safety, which is generally known to be hard and some people consider impossible. However there is nothing we can do to avoid this problem - and we are not trying to achieve safety certification, just ease the QA process for users of ROS.
- Having a template for a semi-formal design document would be useful.
- We need to talk with Ternaris about what we need to and can merge, and what shortcomings there are in Doorstop that still need to be solved.
- e.g. Ternaris has a tool that can extract this information
- We should ask Apex.AI and Ternaris if they have any design documentation and requirements best practices they can share.
- Mapless will begin producing a list of features we need to start porting to or adding to Doorstop; communicate with Ternaris about this.
- Geoff will begin putting together a proposal for changes to REP 2004 to identify what we need to make possible before we can make it required by REP 2004.
- Geoff to ask Apex.AI if they have any learnings and best practices about design documentation that they can make open for the ROS community to learn from.