Change Control Board (CCB) proposal for requirements (v2)
joel at rtems.org
Wed Jul 24 23:17:18 UTC 2019
On Wed, Jul 24, 2019 at 1:39 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). The Doorstop maintainer was
> not so fond of my idea to add support for digital signatures:
> So, here is a new proposal without signatures. I think this makes the
> process a bit easier.
> 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
> There are the following actors involved:
> * *RTEMS users*: Everyone using the RTEMS real-time operating system to
> develop and build an application on top of it.
> * *RTEMS developers*: The persons developing and maintaining RTEMS.
> They write
> patches to add or modify code, requirements, tests and documentation.
> * *RTEMS maintainers*: They are listed in the
> `MAINTAINERS <https://git.rtems.org/rtems/tree/MAINTAINERS>`_ file
> and have
> write access to the project repositories.
> .. TODO: Make a reference to the "normal patch review process".
> Adding and changing requirements follows the normal patch review process.
The normal process should be defined and referenced.
> Reviews and comments may be submitted by anyone, but a maintainer review is
> required to approve *significant* changes. In addition for significant
> changes, there should be at least one reviewer with a sufficient
> from the author which proposes a new requirement or a change of an existing
> requirement. Working in another company on different projects is
Different companies and same funding source isn't independent.
> RTEMS maintainers do not know all the details, so they
> trust in
> general people with experience on a certain platform. Sometimes no review
> comments may appear in a reasonable time frame, then an implicit
> agreement to
> the proposed changes is assumed. Patches can be sent at anytime, so
> controlling changes in RTEMS requires a permanent involvement on the RTEMS
> developer mailing list.
There is a problem with independence and reasonable time frame. You are
relying on volunteers to review requirements (or anything else) and at
availability mercy. I don't know how you ensure you have proper second
from the volunteer community in a reasonable time frame. Lack of commentary
could just mean personal issues or travel. For example, I spent 3 weeks of
traveling and/or teaching and was sick enough for two rounds of
care about reviewing but I didn't review much last month. And even when I do
review, there is a practical limit.
Some of this going to have to be spoon fed to the community to have a chance
to get it reviewed by volunteer. Better would be paid time from alternative
developers to speed this up.But ultimately some core reviewers will be
A normal timeout isn't appropriate for requirements. They really deserve
acknowledge. A true CCB waits for a majority from a quorum.
A technical part of the solution is be something like Phabricator which
getting multiple approvals and lets you do online reviews. A tool like this
helps with the records for code reviews and approval beyond the final git
> For a qualification of RTEMS according to certain standards, the
> may be approved by an RTEMS user.
I think you mean tailoring the requirements and code.
> The approval by RTEMS users is not the
> concern of the RTEMS project, however, the RTEMS project should enable
> users to manage the approval of requirements easily. This information
> may be
> also used by a independent authority which comes into play with an
> Software Verification and Validation (:term:`ISVV`). It could be used to
> select a subset of requirements, e.g. look only at the ones approved by a
> certain user.
Careful with approved. Do you mean tailoring again?
> RTEMS users should be able to reference the determinative
> content of requirements, test procedures, test cases and justification
> in their own documentation. Changes in the determinative content should
> invalidate all references to previous versions.
Determinative doesn't appear to be a word.
> .. 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 requirement, changes the
> The links from one item to another include the fingerprint, so the
> of changes is also visible to dependent items. Currently, MD5 is
> used as
> the hash. Since this hash is insecure, it is proposed to add a
> configuration option to Doorstop which enables SHA512 for hashes.
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the devel