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.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
