Doorstep and ISO 26262 / EN 61508

[stefanoco]

Also relates to #309 I'm willing to start a discussion about using doorstop in the context of Functional Safety concerned developments according to mentioned norms. Any experience about this?

[jmvillalba]

We are using doorstop in this context. It's usefull to maintain traceability.

But it's necessary to know the limitations of the tool.

One of the limitations that I miss the most is: being able to have several parent documents. Also, when you change an item, it prompts you to check the traceability upwards, but not downwards.

[stefanoco]

Maybe Doorstop will develop in the direction of easy and simple usability, without bothering too much about the peculiar needs of FUSA concerned env, while the similar StrictDoc will evolve more into a FUSA tool? As far as I can see, StrictDoc solves exactly these limitations you mention here

[fkromer]

In the past I had to use several tools w.r.t. requirement engineering. One pain point overlooked quite often is interoperability with other tools. Usually requirements of a single compontent need to get into the context of some bigger system. This means the tool you use has to support at least the export of requirements in commonly agreed on requirement interoperability standards which will differ dependent on the domain I guess. @stefanoco Thanks for letting us know about StrictDoc.

[ckolumbus]

I do have a proposal for solving the "multi-parent" problem. I'm coming from a medical device software development environment and have similar requirements as mentioned above. We are using Caliber for most of the requirements and the idea is derived from how we define traces there. It depends on what exactly you need to achieve, but please read on and comment on the proposal

Context:

• Assume we have the following tree Feature_Req <- SW_Req <- SW_Test, and now we have a TRA (thread and risk analysis) which "generates" new mitigation requirements based on the Feature_Req.
• I'm also assuming now that the following is sufficient: EVERY requirement from TRA needs to be picked up by the SW_req (implemented) , but NOT EVERY SW-Req needs to trace to a TRA requirement. In our case this holds true because we need to make sure that all TRA elements are implemented, but not every SW Req actually need one
• on a side note: in order to verify that all TRA requiremetns a tested, a new TRA_Test document could be created as a child to the TRA itself.
• the main difference to normal tracing in doorstop is, that in this case EVERY requirement in a child document needs to trace to a parent req, unless it is derived. Here it is more saying: "no matter what you do elsewhere in the mapped document, you need to pick up all my requirements at least somewhere". This loosens the tight tracing requirements that would break with multi-parent approach.

If the assumptions are above are valid, then a possible implementation sketch can look like this

1. let's define a document that holds the TRA: normal document dependencies, could be a child doc of Feature_Req
2. configure an "map_to" attribute in the TRA document that lists the documents that need to pick up all the requirements from the TRA, in our case this would list "SW_Req"
3. as a sanity check we could make sure that the mapped document is neither a parent of a child of the current document (direct or indirect, to avoid trace loops)
4. when validating document we can check for the existence of the map_to attribute and validate whether all items from this document are actually picked up by the "mapped_to" document(s). we will not, as in the normal case, check whether every child document requirement will have a link to this "mapped" parent

The implementation should be quite easy. we would need a hard-coded or flexible way to configure attributes on document level (maybe a new feature like extended attributes for documents, similar to those for items) and one more validation rule for the case described above.

[ckolumbus]

example implementation is now avail according to the feature description above

[ckolumbus]

@stefanoco I've implemented a suggestion in pr #569 , maybe you you review the proposal to see whether this would fit your needs.

[stefanoco]

Sure @ckolumbus I'm doing now thanks!

[mumbricht]

In addition to these more technical issues, a concern we are having in adopting Doorstop is the implementation of the ReqIF interchange format, the standard interchange used by Doors and others. In our case, we need a ReqIF output or adapter to plug into our MBSE tool, Capella.

Has the use of ReqIF for an export format been investigated? Are there non-obvious technical challenges, or could we make a prototype and send it in as a pull request?