On Mon, Jul 22, 2019 at 1:07 AM Sebastian Huber <sebastian.hu...@embedded-brains.de> wrote: > > Hello, > > I work currently on a requirements engineering section for RTEMS in the > RTEMS Software Engineering manual: > > https://docs.rtems.org/branches/master/eng/index.html > > One topic is the Change Control Board (CCB). My proposal follows: > The proposal looks sensible to me. I had one question and saw one typo to fix.
> Change Control Board > -------------------- > > Working with requirements usually involves a Change Control Board > (:term:`CCB`). The CCB of the RTEMS project is the > `RTEMS developer mailing list > <https://lists.rtems.org/mailman/listinfo/devel>`_. > Adding and changing requirements follows the normal patch review process. > Patches can be approved and committed by RTEMS maintainers. Everybody > can make > comments to proposed patches. There should be at least one reviewer with a > sufficient independence from the author which proposes a new requirement > or a > change of an existing requirement. Working in another company on different > projects is sufficiently independent. Patches can be sent at anytime, so > controlling changes in RTEMS requires a permanent involvement on the RTEMS > developer mailing list. > It's not clear whether "reviewer" here implies a maintainer, or can be anyone (independent). In our normal course of software development, while reviews may be submitted by anyone, we require a maintainer review to approve "significant" changes. It will be good to clarify roles/responsibilities. > For a qualification of RTEMS according to certain standards, the > requirements > may be approved by an RTEMS user. This could be also a independent > authority > which comes into play with an Independent Software Verification and > Validation > (:term:`ISVV`). The approval by RTEMS users is of no concern to the RTEMS replace "users is of not concern to the" with "users is not the concern of the" > project, however, the RTEMS project should enable RTEMS users to manage the > approval of requirements easily. > > * Users should be able to attach their approval to requirements, test > procedures, test cases and justification reports. > > * Attaching an approval should be independent of the normal development work > flow, e.g. it should be possible to commit an approval long after > requirements are committed. > > * Other users should be able to figure out which part of RTEMS is > approved by a > user. > > * The integrity of approvals should be ensured by digital signatures. > Once an > approval is committed, the user no longer needs to trust the RTEMS > project. > > * Changes in RTEMS should invalidate automatically all approvals which are > affected by the change (on a best-effort basis). > > .. topic:: Doorstop > > In Doorstop some values of an item (generalization of a requirement) > contribute to a > `fingerprint of the item > <https://github.com/jacebrowning/doorstop/blob/develop/docs/reference/items.md#reviewed>`_. > Changing a value, e.g. the text of a requirment, changes the requirement > fingerprint. > The links from one item to another include the fingerprint, so the > impact > of changes is also visible to dependent items. The service to manage > approvals can be done with a new Doorstop feature, see > `#375 <https://github.com/jacebrowning/doorstop/issues/375>`_, > > -- > Sebastian Huber, embedded brains GmbH > > Address : Dornierstr. 4, D-82178 Puchheim, Germany > Phone : +49 89 189 47 41-16 > Fax : +49 89 189 47 41-09 > E-Mail : sebastian.hu...@embedded-brains.de > PGP : Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. > _______________________________________________ > 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
