<div dir="ltr"><div dir="ltr">Where to store the artifacts and what component to do first are independent topics and should be on separate threads. I have changed the subject.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 22, 2019 at 7:29 AM Ting Peng <<a href="mailto:ting.peng@embedded-brains.de">ting.peng@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>
As to the requirements documentation, we need to decide a place to store <br>
those requirements documentation. One suggestion is to store in <br>
rtems/reqs folder, the other is to store in rtems-docs/reqs folder. We <br>
suggest to put the requirements related files (by Doorstop) inside <br>
rtems/reqs so that the versions of both source code and the requirements <br>
could be consistent. If you wouldn't express any disagreement, then we <br>
will use /rtems/reqs. Thank you for your attention.<br></blockquote><div><br></div><div>This is ambiguous to me. Is the suggestion to add a requirements/ directory</div><div>at either the top of the rtems source tree or the rtems-docs source tree?</div><div><br></div><div>Note that rtems is at least one subdirectory in the RTEMS git repository</div><div>so I could interpret that as adding a requirements directory per component.</div><div><br></div><div>Anyway, this can't be answered without knowing the processing requirements.</div><div>If we are tracing requirements to implementation to test implementation to</div><div>coverage, it may make sense to put them in the source tree but that makes </div><div>them harder to include in an RTEMS documentation build.  Thinking out loud,</div><div>it is probably easier to include them in the rtems-docs and have any requirements</div><div>tracing tools be told where the rtems-docs and rtems source is. </div><div><br></div><div>Either way, I doubt we will end up with a flat set of requirement files under the</div><div>top requirements directory. Especially since Doorstop seemed to want one </div><div>requirement per file. I see us with a directory per subsystem.</div><div><br></div><div>But this is all assuming that having a separate repository for qualification</div><div>artifacts is not a desirable option. </div><div><br></div><div>--joel</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Best regards,<br>
<br>
Ting Peng<br>
<br>
On 5/22/19 10:37 AM, Ting Peng wrote:<br>
> Hello,<br>
><br>
> As we need to choose one RTEMS software component as an example to <br>
> have an overview of the qualification process, Sebastian Huber <br>
> suggests to take the Interrupt Manager Extension <br>
> (<a href="https://docs.rtems.org/doxygen/branches/master/group__rtems__interrupt__extension.html" rel="noreferrer" target="_blank">https://docs.rtems.org/doxygen/branches/master/group__rtems__interrupt__extension.html</a>) <br>
> as the example. The goal is to integrate the Interrupt Manager <br>
> Extension in the Interrupt Manager. The example will cover the topics <br>
> of requirements, test plans, test code, test reports, code coverage, <br>
> other metrics, software architecture, software detailed design, <br>
> traceability items (open issue) and Interface control document (ICD) <br>
> vs. RTEMS Classic API Guide (open issue).<br>
><br>
> Thank you for reading this email.<br>
><br>
> Best regards,<br>
><br>
> Ting Peng<br>
><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>