Requirement Identifiers

[Sebastian Huber]

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?

-- 
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.