[PATCH] eng: Add Software Requirements Engineering chapter

[Gedare Bloom]

On Wed, Jul 31, 2019 at 5:33 AM Sebastian Huber
<sebastian.huber at 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.huber at embedded-brains.de
> PGP     : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel