<div dir="auto"><div>Hi Sebastian,<div dir="auto"><br></div><div dir="auto">Sorry to toppost. I cut my finger and have some trouble using a keyboard. I just seek clarification whether you are proposing abandoning doorstop, forking it, or replacing it with a custom Python tool.</div><div dir="auto"><br></div><div dir="auto">Gedare</div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 20, 2020, 12:14 PM 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 20/04/2020 15:20, Joel Sherrill wrote:<br>
<br>
><br>
><br>
> On Sun, Apr 19, 2020 at 10:14 AM Sebastian Huber <br>
> <<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank" rel="noreferrer">sebastian.huber@embedded-brains.de</a> <br>
> <mailto:<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank" rel="noreferrer">sebastian.huber@embedded-brains.de</a>>> wrote:<br>
><br>
>     Hello,<br>
><br>
>     I am about to add the next couple of hundred specification items<br>
>     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<br>
>     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 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<br>
>     some<br>
>     pretty nice features. In particular, I think the file based<br>
>     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<br>
>     always<br>
>     sense. Having them in every item is just overhead and may cause<br>
>     confusion.<br>
><br>
><br>
> If they are documented well and their flow through the process is clear,<br>
> there should not be huge confusion. Performance overhead maybe.<br>
><br>
> I have seen project requirements that had schedule phase or HW/SW <br>
> associated<br>
> with each requirement. On those projects, it seemed to me that the <br>
> primary<br>
> problem was that the tooling couldn't check that parent requirement<br>
> custom attributes had an relationship to those of the children. Schedule<br>
> phases and HW/SW didn't match across the levels of requirements and<br>
> there was no way to know if it was intentional or just 100s of mistakes.<br>
><br>
><br>
>     2. The links cannot have custom attributes, e.g. role, enabled-by.<br>
><br>
><br>
> i assume by enabled-by you are tracking to an RTEMS compile or condefs.h<br>
> configure option.<br>
Yes, the enabled-by stuff mostly relates to the RTEMS CPU options, e.g. <br>
RTEMS_SMP, RTEMS_POSIX_API, etc.<br>
><br>
> The FACE Technical Standard uses the term conditional to describe <br>
> capabilities<br>
> an implementation of the standard may provide. The term optional is <br>
> also used<br>
> in the general requirements community but these. I recall that is what <br>
> POSIX<br>
> calls them. Interestingly, neither standard uses will or may in those <br>
> requirements<br>
> as the textbooks suggest but collects them under optional feature <br>
> categories.<br>
><br>
><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<br>
>     verification<br>
>     with type-based rules.<br>
><br>
><br>
> This sounds like you have found the problem I was referring to above.<br>
> Parent and child should follow rules on custom attributes.<br>
Yes, I think it is a must to verify basic things, e.g. proper <br>
relationships, the right set of attributes, proper values for the <br>
attributes, etc.<br>
><br>
><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)<br>
>     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<br>
>     them.<br>
><br>
><br>
> This seems fixable.<br>
><br>
><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<br>
>     this in:<br>
><br>
>     <a href="https://git.rtems.org/sebh/rtems-qual.git/" rel="noreferrer 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>
><br>
><br>
> You are indeed pushing beyond what a requirements management tool<br>
> is usually scoped to do. Which is funny because some of the commercial<br>
> tools have capabilities not discussed so far. They are usually metrics,<br>
> static analysis, and/or code coverage. We address two of the three with<br>
> custom tools.<br>
><br>
> I agree with Chris that you should discuss this with the Doorstop project.<br>
> RTEMS has certainly grown with odd requirements thrown at it. It would<br>
> be rude to not give another open source project the same opportunity.<br>
> Of course, that may not change the end result.<br>
<br>
<a href="https://github.com/doorstop-dev/doorstop/issues/471" rel="noreferrer noreferrer" target="_blank">https://github.com/doorstop-dev/doorstop/issues/471</a><br>
<br>
><br>
> If we do end up beyond Doorstop's mission, then it is worth considering<br>
> a sibling tool to do the generation. But I also know that Doorstop is not<br>
> a huge body of Python either.<br>
<br>
I converted the specification of the new build system using path-like <br>
UIDs. Python is really nice here, since you can simply use the os.path <br>
support. The transformation to the new format was pretty easy now that <br>
everything is contained in a machine readable format that ends up with a <br>
bunch of Python lists, dicts, and scalars.<br>
<br>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" target="_blank" rel="noreferrer">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
</blockquote></div></div></div>