Change Control Board (CCB) proposal for requirements
gedare at rtems.org
Mon Jul 22 21:32:10 UTC 2019
On Mon, Jul 22, 2019 at 1:07 AM Sebastian Huber
<sebastian.huber at embedded-brains.de> wrote:
> I work currently on a requirements engineering section for RTEMS in the
> RTEMS Software Engineering manual:
> 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
> 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
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
> For a qualification of RTEMS according to certain standards, the
> may be approved by an RTEMS user. This could be also a independent
> which comes into play with an Independent Software Verification and
> (: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
> * The integrity of approvals should be ensured by digital signatures.
> Once an
> approval is committed, the user no longer needs to trust the RTEMS
> * 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
> Changing a value, e.g. the text of a requirment, changes the
> The links from one item to another include the fingerprint, so the
> 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.huber at embedded-brains.de
> PGP : Public key available on request.
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> devel mailing list
> devel at rtems.org
More information about the devel