Change Control Board (CCB) proposal for requirements

[Gedare Bloom]

On Mon, Jul 22, 2019 at 1:07 AM Sebastian Huber
<sebastian.huber at 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.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
> http://lists.rtems.org/mailman/listinfo/devel