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.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
