[RTEMS Project] #3703: Technical Specification (TS) for space profile

[RTEMS trac]

#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
 [https://ecss.nl/standard/ecss-e-st-40c-software-general-requirements/
 ECSS-E-ST-40C] and consists of
 * the Software Requirements Specification (SRS, ECSS‐E‐ST‐40C Annex D),
 and
 * 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.

 [https://ecss.nl/standard/ecss-e-st-10-06c-technical-requirements-
 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
 information:

 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, 5.8.3.3 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, 5.8.3.5 Verification of code: Source code shall be
 traceable to design and requirements.  Software code traceability matrices
 shall be provided.

 5. ECSS-E-ST-40C, 5.8.3.6 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
 Identifiability).

--
Ticket URL: <http://devel.rtems.org/ticket/3703>
RTEMS Project <http://www.rtems.org/>
RTEMS Project