<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 22, 2019 at 12:53 AM Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@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>
I would like to clarify one detail with respect to the requirement <br>
identifiers. The current consensus is that the requirements should be <br>
grouped by component, e.g.<br>
<br>
RTEMS<br>
^-- RTEMS-Classic<br>
     ^-- RTMES-Classic-Task<br>
     ^-- RTMES-Classic-Semaphore<br>
^-- RTEMS-POSIX<br>
<br>
The group name and a number forms the identifier, e.g. <br>
RTEMS-Classic-Task-0123. We may use number groups as well, e.g. <br>
RTEMS-Classic-Task-01xx could be task create requirements. Now the detail:<br>
<br>
On 11/07/2019 10:15, Sebastian Huber wrote:<br>
> The standard ECSS-E-ST-10-06C recommends<br>
> in section 8.2.6 that the identifier should reflect the type of the <br>
> requirement<br>
> and the life profile situation.  Other standards may have other<br>
> recommendations.  To avoid a bias of RTEMS in the direction of ECSS, this<br>
> recommendation will not be followed.<br>
<br>
I would like to move any other meta information about requirements to <br>
the requirement file as attributes. For example in the file <br>
RTEMS-Classic-Task-0123.yml:<br>
<br>
text: |<br>
   If the id parameter is NULL, then the rtems_task_create() directive <br>
shall return RTEMS_INVALID_ADDRESS.<br>
type: functional<br>
rational: |<br>
   The set of stupid developers is non-empty.<br>
<br>
The alternative is to create subgroups for each type, e.g.<br>
<br>
RTEMS<br>
^-- RTEMS-Classic<br>
     ^-- RTMES-Classic-Task<br>
         ^-- RTMES-Classic-Task-Func<br>
         ^-- RTMES-Classic-Task-Perf<br>
         ^-- RTMES-Classic-Task-Iface<br>
         ^-- RTMES-Classic-Task-Whatever<br>
     ^-- RTMES-Classic-Semaphore<br>
         ^-- RTMES-Classic-Semaphore-Func<br>
         ^-- RTMES-Classic-Semaphore-Perf<br>
         ^-- RTMES-Classic-Semaphore-Iface<br>
         ^-- RTMES-Classic-Semaphore-Whatever<br>
^-- RTEMS-POSIX<br>
<br>
I would not do this. It ties us to the grouping defined by ECSS. The <br>
identifiers are longer. The hierarchy is deeper. Using attributes is <br>
much more flexible.<br>
<br>
What do you think?<br></blockquote><div><br></div><div>I think everything about a single requirement should be in the yaml file </div><div>with the requirement. I do not want them split out. </div><div><br></div><div>ARINC 653 has the following for each requirement and note that the</div><div>formal requirements and test cases are described in "part 3" of the</div><div>standard. Part 1 is required APIs and Part 2 is optional ones.</div><div><br></div><div>- ID</div><div>- Reference to the main standard</div><div>- Description including objectives (rationale?)</div><div>- Comments.</div><div><br></div><div>IDs are "COMPONENT-MANAGER/CATEGORY-NNNN". Component is API </div><div>for the ones I see. The Manager/Category can be "GEN" or an API code.</div><div>Then the numbers appear to be 10 apart.</div><div><br></div><div>We should consider categories for configuration and internal things</div><div>that are hard to accurately reflect from API requirements. Off the top</div><div>of my head, FIFO or Priority blocking has one Score requirement</div><div>but lots of API visible ones. The various schedulers may be another.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
-- <br>
Sebastian Huber, embedded brains GmbH<br>
<br>
Address : Dornierstr. 4, D-82178 Puchheim, Germany<br>
Phone   : +49 89 189 47 41-16<br>
Fax     : +49 89 189 47 41-09<br>
E-Mail  : <a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a><br>
PGP     : Public key available on request.<br>
<br>
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<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></blockquote></div></div>