1 | .. SPDX-License-Identifier: CC-BY-SA-4.0 |
---|
2 | |
---|
3 | .. Copyright (C) 2019, 2020 embedded brains GmbH (http://www.embedded-brains.de) |
---|
4 | |
---|
5 | Requirement Management |
---|
6 | ====================== |
---|
7 | |
---|
8 | Change Control Board |
---|
9 | -------------------- |
---|
10 | |
---|
11 | Working with requirements usually involves a Change Control Board |
---|
12 | (:term:`CCB`). The CCB of the RTEMS Project is the |
---|
13 | `RTEMS developer mailing list <https://lists.rtems.org/mailman/listinfo/devel>`_. |
---|
14 | |
---|
15 | There are the following actors involved: |
---|
16 | |
---|
17 | * *RTEMS users*: Everyone using the RTEMS real-time operating system to design, |
---|
18 | develop and build an application on top of it. |
---|
19 | |
---|
20 | * *RTEMS developers*: The persons developing and maintaining RTEMS. They write |
---|
21 | patches to add or modify code, requirements, tests and documentation. |
---|
22 | |
---|
23 | * *RTEMS maintainers*: They are listed in the |
---|
24 | `MAINTAINERS <https://git.rtems.org/rtems/tree/MAINTAINERS>`_ file and have |
---|
25 | write access to the project repositories. |
---|
26 | |
---|
27 | Adding and changing requirements follows the normal patch review process. The |
---|
28 | normal patch review process is described in the |
---|
29 | `RTEMS User Manual <https://docs.rtems.org/branches/master/user/support/contrib.html#patch-review-process>`_. |
---|
30 | Reviews and comments may be submitted by anyone, but a maintainer review is |
---|
31 | required to approve *significant* changes. In addition for significant |
---|
32 | changes, there should be at least one reviewer with a sufficient independence |
---|
33 | from the author which proposes a new requirement or a change of an existing |
---|
34 | requirement. Working in another company on different projects is sufficiently |
---|
35 | independent. RTEMS maintainers do not know all the details, so they trust in |
---|
36 | general people with experience on a certain platform. Sometimes no review |
---|
37 | comments may appear in a reasonable time frame, then an implicit agreement to |
---|
38 | the proposed changes is assumed. Patches can be sent at anytime, so |
---|
39 | controlling changes in RTEMS requires a permanent involvement on the RTEMS |
---|
40 | developer mailing list. |
---|
41 | |
---|
42 | For a qualification of RTEMS according to certain standards, the requirements |
---|
43 | may be approved by an RTEMS user. The approval by RTEMS users is not the |
---|
44 | concern of the RTEMS Project, however, the RTEMS Project should enable RTEMS |
---|
45 | users to manage the approval of requirements easily. This information may be |
---|
46 | also used by a independent authority which comes into play with an Independent |
---|
47 | Software Verification and Validation (:term:`ISVV`). It could be used to |
---|
48 | select a subset of requirements, e.g. look only at the ones approved by a |
---|
49 | certain user. RTEMS users should be able to reference the determinative |
---|
50 | content of requirements, test procedures, test cases and justification reports |
---|
51 | in their own documentation. Changes in the determinative content should |
---|
52 | invalidate all references to previous versions. |
---|
53 | |
---|
54 | Add a Requirement |
---|
55 | ----------------- |
---|
56 | |
---|
57 | .. image:: ../../images/eng/req-add.* |
---|
58 | :scale: 70 |
---|
59 | :align: center |
---|
60 | |
---|
61 | .. _ReqEngModifyRequirement: |
---|
62 | |
---|
63 | Modify a Requirement |
---|
64 | -------------------- |
---|
65 | |
---|
66 | .. image:: ../../images/eng/req-modify.* |
---|
67 | :scale: 70 |
---|
68 | :align: center |
---|
69 | |
---|
70 | Mark a Requirement as Obsolete |
---|
71 | ------------------------------ |
---|
72 | |
---|
73 | Requirements shall be never removed. They shall be marked as obsolete. This |
---|
74 | ensures that requirement identifiers are not reused. The procedure to obsolete |
---|
75 | a requirement is the same as the one to :ref:`modify a requirement |
---|
76 | <ReqEngModifyRequirement>`. |
---|