[RTEMS Project] #3703: Technical Specification (TS) for space profile
trac at rtems.org
Tue Feb 26 12:14:55 UTC 2019
#3703: Technical Specification (TS) for space profile
Reporter: Sebastian Huber | Owner: Sebastian Huber
Type: task | Status: assigned
Priority: normal | Milestone: 6.1
Component: doc | Version: 6
Severity: normal | Keywords: qualification
Blocked By: | Blocking: 3701
A Technical Specification (TS) is required by
ECSS-E-ST-40C] and consists of
* the Software Requirements Specification (SRS, ECSS‐E‐ST‐40C Annex D),
* the Software Interface Control Document (ICD, ECSS‐E‐ST‐40C Annex E).
There is currently no requirements document for RTEMS. Requirements must
be reverse engineered from the documentation, the source code and the
tests. The TS will be created for the space profile of RTEMS SMP. It
should be easy to extend the TS so that more functionality can be covered
once the ground work is done.
specification/ ECSS-E-ST-10-06C] places requirements on requirements and
the specification content.
We need a format for requirements. One idea is to define a custom XML data
model for RTEMS requirements and use an XML document to store the
requirements in the RTEMS kernel repository (requirements master document,
RMD). The RMD can be used to generate human readable documents via Sphinx.
ECSS-E-ST-10-06C and ECSS-E-ST-40C mandate some of traceability
1. ECSS-E-ST-10-06C, 8.2.3 Configuration management and traceability: The
history of requirements shall be traceable. In the XML documents the
history of requirements changes, removals, additions, etc. could be stored
in a special section along with additional information, e.g. reason for
change, date, approval status, etc. A Git pre-commit hook could check that
changes in the requirements document follow a specified procedure, e.g.
one commit may change at most one requirement and there must be a
corresponding revision entry for this change.
2. ECSS-E-ST-10-06C, 8.2.3 Configuration management and traceability: If a
requirements is derived from other requirements, then this information
must be visible (backward traceability).
3. ECSS-E-ST-40C, 220.127.116.11 Verification of the software architectural
design: Each software component shall provide a link to the requirements
it implements (forward traceability). Software architectural design to
requirements traceability matrices shall be provided.
4. ECSS-E-ST-40C, 18.104.22.168 Verification of code: Source code shall be
traceable to design and requirements. Software code traceability matrices
shall be provided.
5. ECSS-E-ST-40C, 22.214.171.124 Verification of software unit testing (plan and
results): Unit test shall be traceable to software requirements. Software
unit tests traceability matrices shall be provided.
The presentation in a human readable form of the traceability information
should be done by tools using the RMD as input and the overall source code
with requirement link annotations. This requires that we have a human and
machine readable requirements identifier (also ECSS-E-ST-10-06C, 8.2.6
Ticket URL: <http://devel.rtems.org/ticket/3703>
RTEMS Project <http://www.rtems.org/>
More information about the bugs