<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Apr 19, 2020 at 10:14 AM Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello,<br>
<br>
I am about to add the next couple of hundred specification items for the <br>
RTEMS pre-qualification activity. Before I do this, I would like to <br>
present some issues that popped up during my daily work with Doorstop. <br>
Doorstop is a requirements management tool which was selected for the <br>
pre-qualification activity:<br>
<br>
<a href="https://docs.rtems.org/branches/master/eng/req-eng.html#selected-tool-doorstop" rel="noreferrer" target="_blank">https://docs.rtems.org/branches/master/eng/req-eng.html#selected-tool-doorstop</a><br>
<br>
I am quite happy that Jan Sommer suggested to use this tool. I has some <br>
pretty nice features. In particular, I think the file based organization <br>
in YAML format forming a directed acyclic graph is really the right <br>
thing for this project. However, it turned out that it lacks the <br>
required flexibility.<br>
<br>
1. Its use case is requirements management. So it has some standard <br>
attributes useful in this domain, like derived, header, level, <br>
normative, ref, reviewed, and text. However, I want to use it more <br>
generally for specification items and these attributes make not always <br>
sense. Having them in every item is just overhead and may cause confusion.<br></blockquote><div><br></div><div>If they are documented well and their flow through the process is clear,</div><div>there should not be huge confusion. Performance overhead maybe.</div><div><br></div><div>I have seen project requirements that had schedule phase or HW/SW associated</div><div>with each requirement. On those projects, it seemed to me that the primary </div><div>problem was that the tooling couldn't check that parent requirement </div><div>custom attributes had an relationship to those of the children. Schedule</div><div>phases and HW/SW didn't match across the levels of requirements and</div><div>there was no way to know if it was intentional or just 100s of mistakes. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
2. The links cannot have custom attributes, e.g. role, enabled-by.<br></blockquote><div><br></div><div>i assume by enabled-by you are tracking to an RTEMS compile or condefs.h</div><div>configure option.  </div><div><br></div><div>The FACE Technical Standard uses the term conditional to describe capabilities </div><div>an implementation of the standard may provide. The term optional is also used </div><div>in the general requirements community but these. I recall that is what POSIX </div><div>calls them. Interestingly, neither standard uses will or may in those requirements</div><div>as the textbooks suggest but collects them under optional feature categories.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
3. Inside a document (directory) items are supposed to have a common <br>
type. I would like to store at a hierarchy level also distinct <br>
specializations.<br>
<br>
4. The verification if the items is quite limited. We need verification <br>
with type-based rules.<br></blockquote><div><br></div><div>This sounds like you have found the problem I was referring to above.</div><div>Parent and child should follow rules on custom attributes. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
5. The UIDs in combination with the document hierarchy lead to <br>
duplication, e.g. a/b/c/a-b-c-d.yml. You have the path (a/b/c) also in <br>
the file name (a-b-c). You cannot have relative UIDs in links (e.g. <br>
../parent-req) . The specification items may contain multiple <br>
requirements, e.g. min/max attributes. There is no way to identify them.<br></blockquote><div><br></div><div>This seems fixable. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I will probably stop using Doorstop and use a custom tooling. With <br>
Python, this is quite easy. I already have the infrastructure for this in:<br>
<br>
<a href="https://git.rtems.org/sebh/rtems-qual.git/" rel="noreferrer" target="_blank">https://git.rtems.org/sebh/rtems-qual.git/</a><br>
<br>
I will try this out with the new build system.<br></blockquote><div><br></div><div>You are indeed pushing beyond what a requirements management tool</div><div>is usually scoped to do. Which is funny because some of the commercial</div><div>tools have capabilities not discussed so far. They are usually metrics,</div><div>static analysis, and/or code coverage. We address two of the three with </div><div>custom tools.</div><div><br></div><div>I agree with Chris that you should discuss this with the Doorstop project.</div><div>RTEMS has certainly grown with odd requirements thrown at it. It would</div><div>be rude to not give another open source project the same opportunity.</div><div>Of course, that may not change the end result.</div><div><br></div><div>If we do end up beyond Doorstop's mission, then it is worth considering</div><div>a sibling tool to do the generation. But I also know that Doorstop is not</div><div>a huge body of Python either. </div><div><br></div><div>--joel</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
</blockquote></div></div>