Where to Store Requirements for RTEMS Components

[Joel Sherrill]

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.

On Wed, May 22, 2019 at 7:29 AM Ting Peng <ting.peng at embedded-brains.de>
wrote:

> Hello,
>
> As to the requirements documentation, we need to decide a place to store
> those requirements documentation. One suggestion is to store in
> rtems/reqs folder, the other is to store in rtems-docs/reqs folder. We
> suggest to put the requirements related files (by Doorstop) inside
> rtems/reqs so that the versions of both source code and the requirements
> could be consistent. If you wouldn't express any disagreement, then we
> will use /rtems/reqs. Thank you for your attention.
>

This is ambiguous to me. Is the suggestion to add a requirements/ directory
at either the top of the rtems source tree or the rtems-docs source tree?

Note that rtems is at least one subdirectory in the RTEMS git repository
so I could interpret that as adding a requirements directory per component.

Anyway, this can't be answered without knowing the processing requirements.
If we are tracing requirements to implementation to test implementation to
coverage, it may make sense to put them in the source tree but that makes
them harder to include in an RTEMS documentation build.  Thinking out loud,
it is probably easier to include them in the rtems-docs and have any
requirements
tracing tools be told where the rtems-docs and rtems source is.

Either way, I doubt we will end up with a flat set of requirement files
under the
top requirements directory. Especially since Doorstop seemed to want one
requirement per file. I see us with a directory per subsystem.

But this is all assuming that having a separate repository for qualification
artifacts is not a desirable option.

--joel


>
> Best regards,
>
> Ting Peng
>
> On 5/22/19 10:37 AM, Ting Peng wrote:
> > Hello,
> >
> > As we need to choose one RTEMS software component as an example to
> > have an overview of the qualification process, Sebastian Huber
> > suggests to take the Interrupt Manager Extension
> > (
> https://docs.rtems.org/doxygen/branches/master/group__rtems__interrupt__extension.html)
>
> > as the example. The goal is to integrate the Interrupt Manager
> > Extension in the Interrupt Manager. The example will cover the topics
> > of requirements, test plans, test code, test reports, code coverage,
> > other metrics, software architecture, software detailed design,
> > traceability items (open issue) and Interface control document (ICD)
> > vs. RTEMS Classic API Guide (open issue).
> >
> > Thank you for reading this email.
> >
> > Best regards,
> >
> > Ting Peng
> >
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20190522/8b3911d4/attachment-0002.html>