Change Control Board (CCB) proposal for requirements

[Sebastian Huber]

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:

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.

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