Requirement Identifiers

[Gedare Bloom]

On Tue, Jul 23, 2019 at 9:36 AM Joel Sherrill <joel at rtems.org> wrote:
>
> Hi
>
> I am not sure if I am derailing this or helping. I think we need to seriously
> consider that we want these to be easy to manage and the logical names
> should reflect the natural groups in RTEMS.
>
> I lean to something simple like this without the arbitrary sections. ARINC 653
> doesn't have odd subsections beyond something like this.
>
> Classic
>    Classic-General
>    Classic-Task
> POSIX
>    ...
>
> If we go to a third level of outline which isn't based on API or RTEMS logical
> category, then we end up separating error from functional requirements and
> the other categories ECCS had.
>
>   Classic-Task-Error
>   Classic-Task-Functional
>   Classic-Task-Performance (What would these be anyway?)
>
> The above seems like an unnatural organization to me from a human
> maintenance view.
>
> The following would naturally sort the requirements in a manageable manner.
> And I don't think we will disagree about where most requirements go.
>
> Classic-Task-Create
> Classic-Task-Delete
>
> I could see marking a requirement as functional or error. if each error is
> a requirements, then we will have 1000s of those. It could make the
> printed requirements document nicer.
>
> We don't have a fancy tool to manage requirements. I think having an organization
> that reflects the public API view of RTEMS will help us all maintain them and make
> it easier to add. I don't want 10K requirements in a random number pool and arbitrary
> subcategories that are meaningless.
>
> We have to be careful to do what makes them presentable to humans.
>
It would seem wise to make the hierarchy of requirements follow the
same organization as the hierarchy of the Manual documentation.

> --joel
>
> On Mon, Jul 22, 2019 at 9:40 AM Sebastian Huber <sebastian.huber at embedded-brains.de> wrote:
>>
>> ----- 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.
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel