[PATCH] eng: Add Software Requirements Engineering chapter

Sebastian Huber sebastian.huber at embedded-brains.de
Mon Sep 30 13:09:11 UTC 2019


On 24/07/2019 15:44, Sebastian Huber wrote:
> +Requirement Traceability
> +========================
> +
> +The standard |E10-06| demands that requirements shall be under configuration
> +management, backwards-traceable and forward-traceable.
> +
> +History of Requirements
> +-----------------------
> +
> +The RTEMS requirements should placed in the RTEMS sources using Git for version
> +control.  The history of requirements can be traced with Git.  Special commit
> +procedures for changes in requirement files should be established.  For
> +example, it should be allowed to change only one requirement per commit.  A
> +dedicated Git commit message format may be used as well, e.g. use of
> +``Approved-by:`` or ``Reviewed-by:`` lines which indicate an agreed statement
> +(similar to the
> +`Linux kernel patch submission guidelines<https://www.kernel.org/doc/html/latest//process/submitting-patches.html#using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes>`_).

In the first version of this patch, the proposal was to use Git to track 
the history of specification items (requirements are a specialization 
them). I think it would be better to add the revision and the 
description of a change directly to the files, e.g. add a custom 
attribute "changes" which contains a list of "revision" and 
"description" tuples.  Revision 1 items do not need this attribute. 
Example:

changes:
- description: The description of the change from revision 1 (initial) to 2.
   revision: 2
- description: The description of the change from revision 2 to 3.
   revision: 3
- description: The description of the change from revision 3 to 4.
   revision: 4

This information can be used to add the change log of each specification 
item to a human readable document for example.  The documentation 
generator program does not need a Git repository in this case to extract 
the information.

Also this way the revision of a specification item is independent of the 
current version control system. This makes it easier to reference items 
of a specific revision. For example: "With ABC-001 in revision 1 we 
could meet our system requirements, however the change to revision 2 is 
a problem, due to ...".

-- 
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.


More information about the devel mailing list