[PATCH v2] eng: Add Software Requirements Engineering chapter

[Sebastian Huber]

Hello Joel,

thanks for the review, I tried to address all your issues in v3 with one 
exception:

On 07/11/2019 22:55, Joel Sherrill wrote:
> Overall, this is really good. I am sure we will polish details as
> things progress. I marked a few places with notes. Mostly
> grammar or minor points.
[...]
>     +.. _ReqEngResAndPerf:
>     +
>     +Resources and Performance
>     +-------------------------
>     +
>     +Normally, resource and performance requirements are formulated like
>     this:
>     +
>     +* The resource U shall need less than V storage units.
>     +
>     +* The operation Y shall complete within X time units.
>     +
>     +Such statements are difficult to make for a software product like
>     RTEMS which
>     +runs on many different target platforms in various configurations. 
>     So, the
>     +performance requirements of RTEMS shall be stated in terms of
>     benchmarks.  The
>     +benchmarks are run on the project-specific target platform and
>     configuration.
>     +The results obtained by the benchmark runs are reported in a human
>     readable
>     +presentation.  The application designer can then use the benchmark
>     results to
>     +determine if its system performance requirements are met.  The
>     benchmarks shall
>     +be executed under different environment conditions, e.g. varying
>     cache states
>     +(dirty, empty, valid) and system bus load generated by other
>     processors.  The
>     +application designer shall have the ability to add additional
>     environment
>     +conditions, e.g. system bus load by DMA engines or different system bus
>     +arbitration schemes.
>     +
>     +To catch resource and performance regressions via test suite runs
>     there shall be
>     +a means to specify threshold values for the measured quantities. 
>     The threshold
>     +values should be provided for each validation platform.  How this
>     can be done
>     +and if the threshold values are maintained by the RTEMS Project is
>     subject to
>     +discussion.
> 
> We focused on big-O and whether methods were constant time, bounded, or O(n)
> when designing. Perhaps the focus could be there. But this is a design 
> goal for all
> of RTEMS and something we would document. Nothing to do except a general
> design goal.
> 
> This section also sounds like part of what is required by a systems 
> integrator
> when leveraging what the FAA calls a Reusable Software Component:
> 
> https://www.faa.gov/regulations_policies/advisory_circulars/index.cfm/go/document.information/documentID/22207 
> 
> 
> You get credit for what's common and have to fill in details for your 
> system.

I added a ticket for this:

https://devel.rtems.org/ticket/3819

I think it is important to look at, but I need some time to read the 
advisory.

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