Requirement Identifiers

[Joel Sherrill]

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.

--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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20190723/cd8fb39b/attachment-0001.html>