[PATCH] eng: Add Software Requirements Engineering chapter

Sebastian Huber sebastian.huber at embedded-brains.de
Wed Jul 31 11:33:17 UTC 2019


On 24/07/2019 15:44, Sebastian Huber wrote:
> +Requirement Verification
> +========================

I confused the terms verification and validation.  It should be 
"Requirement Validation".  From ECSS-E-ST-40C:

"3.2.44  validation
<software> process to confirm that the requirements baseline functions and
performances are correctly and completely implemented in the final product
3.2.45  verification
<software> process to confirm that adequate specifications and inputs 
exist for
any activity, and that the outputs of the activities are correct and 
consistent
with the specifications and input"

> +
> +The verification of each requirement shall be accomplished by one or more of
> +the following methods and nothing else:
> +
> +**By test*: A test specification is provided to demonstrate that the requirement
> +  is satisfied when the software is executed on the target platform.
> +
> +**By design*: A rationale is provided to demonstrate how the qualification
> +  requirement is satisfied implicitly by the software design.
> +
> +**By analysis*: A statement is provided how the requirement is met, by analysing
> +  static properties of the software.
> +
> +.. topic:: Doorstop
> +
> +    For an item in a parent document it is checked that at least one item in a
> +    child document has a link to it.  For example a child document could
> +    contain verification items.  With this feature you can check that all
> +    requirements are covered by at least one verification item.

I received a comment via private mail:

"reason for test/design/analysis splitting? Maybe biased, but having 
mostly used (ECSS) RAIT scheme (review, analysis, inspection, test), I 
think 'design' should be replaced with 'inspection': By inspection, you 
verify that the design of the software satisfies a certain requirement. 
Otherwise it does not fit the other two words: 'design' is a property of 
the software, 'test' and 'analysis' are actions of verifying 
requirements (like 'inspection')"

In fact, we have in ECSS-E-ST-40C:

"5.6.3.1 Development and documentation of a software
         validation specification with respect to the technical
         specification
[...]
b.      Validation shall be performed by test.
         EXPECTED OUTPUT: Software validation specification with respect 
to the
         technical specification [DJF, SVS; CDR].
c.      If it can be justified that validation by test cannot be performed,
         validation shall be performed by either analysis, inspection or 
review of
         design.
         EXPECTED OUTPUT: Software validation specification with respect 
to the
         technical specification [DJF, SVS; CDR]."

I think this makes more sense than my original proposal. So, validation 
of each requirement shall be done by test, by analysis of design, by 
inspection of design, or by review of design.

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