Requirement Identifiers

[Joel Sherrill]

On Mon, Jul 22, 2019 at 12:53 AM Sebastian Huber <
sebastian.huber at embedded-brains.de> wrote:

> Hello,
>
> I would like to clarify one detail with respect to the requirement
> identifiers. The current consensus is that the requirements should be
> grouped by component, e.g.
>
> RTEMS
> ^-- RTEMS-Classic
>      ^-- RTMES-Classic-Task
>      ^-- RTMES-Classic-Semaphore
> ^-- RTEMS-POSIX
>
> The group name and a number forms the identifier, e.g.
> RTEMS-Classic-Task-0123. We may use number groups as well, e.g.
> RTEMS-Classic-Task-01xx could be task create requirements. Now the detail:
>
> On 11/07/2019 10:15, Sebastian Huber wrote:
> > The standard ECSS-E-ST-10-06C recommends
> > in section 8.2.6 that the identifier should reflect the type of the
> > requirement
> > and the life profile situation.  Other standards may have other
> > recommendations.  To avoid a bias of RTEMS in the direction of ECSS, this
> > recommendation will not be followed.
>
> I would like to move any other meta information about requirements to
> the requirement file as attributes. For example in the file
> RTEMS-Classic-Task-0123.yml:
>
> text: |
>    If the id parameter is NULL, then the rtems_task_create() directive
> shall return RTEMS_INVALID_ADDRESS.
> type: functional
> rational: |
>    The set of stupid developers is non-empty.
>
> The alternative is to create subgroups for each type, e.g.
>
> RTEMS
> ^-- RTEMS-Classic
>      ^-- RTMES-Classic-Task
>          ^-- RTMES-Classic-Task-Func
>          ^-- RTMES-Classic-Task-Perf
>          ^-- RTMES-Classic-Task-Iface
>          ^-- RTMES-Classic-Task-Whatever
>      ^-- RTMES-Classic-Semaphore
>          ^-- RTMES-Classic-Semaphore-Func
>          ^-- RTMES-Classic-Semaphore-Perf
>          ^-- RTMES-Classic-Semaphore-Iface
>          ^-- RTMES-Classic-Semaphore-Whatever
> ^-- RTEMS-POSIX
>
> I would not do this. It ties us to the grouping defined by ECSS. The
> identifiers are longer. The hierarchy is deeper. Using attributes is
> much more flexible.
>
> What do you think?
>

I think everything about a single requirement should be in the yaml file
with the requirement. I do not want them split out.

ARINC 653 has the following for each requirement and note that the
formal requirements and test cases are described in "part 3" of the
standard. Part 1 is required APIs and Part 2 is optional ones.

- ID
- Reference to the main standard
- Description including objectives (rationale?)
- Comments.

IDs are "COMPONENT-MANAGER/CATEGORY-NNNN". Component is API
for the ones I see. The Manager/Category can be "GEN" or an API code.
Then the numbers appear to be 10 apart.

We should consider categories for configuration and internal things
that are hard to accurately reflect from API requirements. Off the top
of my head, FIFO or Priority blocking has one Score requirement
but lots of API visible ones. The various schedulers may be another.


> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax     : +49 89 189 47 41-09
> E-Mail  : sebastian.huber at embedded-brains.de
> PGP     : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> _______________________________________________
> 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/20190722/310f4498/attachment-0002.html>