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