On Tue, Jul 23, 2019 at 9:36 AM Joel Sherrill <j...@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.hu...@embedded-brains.de> wrote: >> >> ----- Am 22. Jul 2019 um 15:55 schrieb joel j...@rtems.org: >> >> > On Mon, Jul 22, 2019 at 12:53 AM Sebastian Huber < >> > sebastian.hu...@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@rtems.org > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
