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