Requirement Identifiers

Sebastian Huber sebastian.huber at
Thu Jul 11 08:15:41 UTC 2019


I work currently on a requirements engineering section for RTEMS in the 
RTEMS Software Engineering manual:

The goal is to add a technical specification for a subset of RTEMS. A 
technical specification consists of requirements. One basic element is 
that requirements can be identified. We have to discuss how requirements 
are identified in the RTEMS project.

The proposed tool to manage requirements in RTEMS is Doorstop:

This tool add some restrictions to the way requirements are identified.

The following text is a part of my requirements engineering draft 
document in ReST format.


Each requirement shall have a unique identifier (UID).  The open 
question is in
which scope should it be unique?  Ideally, it should be universally 
unique. As
a best effort approach, the name *RTEMS* shall be used as a part in all
requirement identifiers. This should ensure that the RTEMS requirements 
can be
referenced easily in larger systems.  The standard ECSS-E-ST-10-06C 
in section 8.2.6 that the identifier should reflect the type of the 
and the life profile situation.  Other standards may have other
recommendations.  To avoid a bias of RTEMS in the direction of ECSS, this
recommendation will not be followed.  In addition, it would also make 
the use
of :term:`Doorstop` more difficult, since this tool does not support 
dependent identifiers.

.. topic:: Doorstop

     The UID of an item (requirement) is defined by its file name 
without the
     extension. An UID consists of two parts, the prefix and a number. 
The parts
     are divided by an optional separator. The prefix is determined by the
     document to which the item belongs.

Proposal: Default Doorstop Numbering

One UID scheme for RTEMS requirements is the concatenation of *RTEMS* and a
5-digit number which is automatically generated by Doorstop.  It starts with
RTEMS00001 and ends with RTEMS99999.  These identifiers are just unique and
bear no other information.

Proposal: Number Groups

Another UID scheme for RTEMS requirements is the concatenation of 
*RTEMS* and a
5-digit number which reflects the hierarchy of requirements.  For 
example UIDs
from RTEMS01000 to RTEMS01999 are task requirements, UIDs from RTEMS02000 to
RTEMS02999 are semaphore requirements, UIDs from RTEMS03000 to 
RTEMS03999 are
message queue requirements, etc.  It would be also possible to add a 
character, for example RTEMS-01234.

.. topic:: Doorstop

     This is currently not supported by Doorstop, see `issue #349

Proposal: Document Hierarchy

Another UID scheme for RTEMS requirements is the concatenation of 
*RTEMS*, one
or more component names, and a 3-digit number which reflects the 
hierarchy of
requirements.  Each part is separated by a "-" character.  For example UIDs
from RTEMS-Classic-Task-001 to RTEMS-Classic-Task-999 are task requirements,
UIDs from RTEMS-Classic-Semaphore-001 to RTEMS-Classic-Semaphore-999 are
semaphore requirements, UIDs from RTEMS-Classic-MQ-001 to 
are message queue requirements, etc.  The benefit is that requirement 
files are
organized in directories.

.. topic:: Doorstop

     Doorstop uses documents to create namespaces (named a prefix in 
     For the example above, you can create the documents like this:

     .. code-block:: none

         doorstop create -d 3 RTEMS-Classic -p RTEMS reqs/classic
         doorstop create -d 3 RTEMS-Classic-Task -p RTEMS-Classic 
         doorstop create -d 3 RTEMS-Classic-Semaphore -p RTEMS-Classic 
         doorstop create -d 3 RTEMS-Classic-MQ -p RTEMS-Classic 

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
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

More information about the devel mailing list