<div dir="ltr">Hi<div><br></div><div>I am not sure if I am derailing this or helping. I think we need to seriously</div><div>consider that we want these to be easy to manage and the logical names</div><div>should reflect the natural groups in RTEMS.</div><div><br></div><div><div>I lean to something simple like this without the arbitrary sections. ARINC 653 </div><div>doesn't have odd subsections beyond something like this.</div><div><br></div><div>Classic</div><div> Classic-General</div><div> Classic-Task</div><div>POSIX</div><div> ...</div><div><br></div><div>If we go to a third level of outline which isn't based on API or RTEMS logical</div><div>category, then we end up separating error from functional requirements and</div><div>the other categories ECCS had.</div><div> </div><div> Classic-Task-Error</div><div> Classic-Task-Functional</div><div> Classic-Task-Performance (What would these be anyway?)</div><div><br></div><div>The above seems like an unnatural organization to me from a human </div><div>maintenance view.</div><div><br></div><div>The following would naturally sort the requirements in a manageable manner.</div><div>And I don't think we will disagree about where most requirements go.</div><div><br></div><div>Classic-Task-Create</div><div>Classic-Task-Delete</div><div><br></div><div>I could see marking a requirement as functional or error. if each error is</div><div>a requirements, then we will have 1000s of those. It could make the </div><div>printed requirements document nicer.</div><div><br></div><div>We don't have a fancy tool to manage requirements. I think having an organization</div><div>that reflects the public API view of RTEMS will help us all maintain them and make</div><div>it easier to add. I don't want 10K requirements in a random number pool and arbitrary</div><div>subcategories that are meaningless.</div></div><div><br></div><div>We have to be careful to do what makes them presentable to humans.</div><div><br></div><div>--joel</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 22, 2019 at 9:40 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">----- Am 22. Jul 2019 um 15:55 schrieb joel <a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a>:<br>
<br>
> On Mon, Jul 22, 2019 at 12:53 AM Sebastian Huber <<br>
> <a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>> wrote:<br>
> <br>
>> 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>
>><br>
> <br>
> I think everything about a single requirement should be in the yaml file<br>
> with the requirement. I do not want them split out.<br>
<br>
Sorry for not being clear enough. The requirements are self-contained.<br>
<br>
The question is if a requirement type (or other attributes) should be contained in the identifier?<br>
<br>
> <br>
> ARINC 653 has the following for each requirement and note that the<br>
> formal requirements and test cases are described in "part 3" of the<br>
> standard. Part 1 is required APIs and Part 2 is optional ones.<br>
> <br>
> - ID<br>
> - Reference to the main standard<br>
> - Description including objectives (rationale?)<br>
> - Comments.<br>
> <br>
> IDs are "COMPONENT-MANAGER/CATEGORY-NNNN". Component is API<br>
> for the ones I see. The Manager/Category can be "GEN" or an API code.<br>
> Then the numbers appear to be 10 apart.<br>
> <br>
> We should consider categories for configuration and internal things<br>
> that are hard to accurately reflect from API requirements. Off the top<br>
> of my head, FIFO or Priority blocking has one Score requirement<br>
> but lots of API visible ones. The various schedulers may be another.<br>
<br>
Yes, but the grouping is another topic. I would like to get the identifiers fixed first.<br>
</blockquote></div>