On Wed, Jul 31, 2019 at 5:33 AM Sebastian Huber <sebastian.hu...@embedded-brains.de> wrote: > > 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. > Good.
> -- > 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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
