Requirement Identifiers

[Sebastian Huber]

----- Am 22. Jul 2019 um 15:55 schrieb joel joel at rtems.org:

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

Sorry for not being clear enough. The requirements are self-contained.

The question is if a requirement type (or other attributes) should be contained in the identifier?

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

Yes, but the grouping is another topic. I would like to get the identifiers fixed first.