diff options
author | Sebastian Huber <sebastian.huber@embedded-brains.de> | 2020-05-28 09:21:38 +0200 |
---|---|---|
committer | Sebastian Huber <sebastian.huber@embedded-brains.de> | 2020-05-29 08:21:03 +0200 |
commit | 23ab40d3e6899c5956c26770f07f3a5eb910be8b (patch) | |
tree | f03dc4c0a50ae7e205b5de02da9b32c2d0d6ec30 /eng/req/req-for-req.rst | |
parent | eng: Split up requirements engineering chapter (diff) | |
download | rtems-docs-23ab40d3e6899c5956c26770f07f3a5eb910be8b.tar.bz2 |
eng: Add generated documentation of spec items
The documentation of the specification items is generated by an RTEMS
qualification tool from a specification of specification items.
Move non-generated content to "req-for-req.rst".
Update #3715.
Diffstat (limited to 'eng/req/req-for-req.rst')
-rw-r--r-- | eng/req/req-for-req.rst | 47 |
1 files changed, 46 insertions, 1 deletions
diff --git a/eng/req/req-for-req.rst b/eng/req/req-for-req.rst index d38e384..9225e95 100644 --- a/eng/req/req-for-req.rst +++ b/eng/req/req-for-req.rst @@ -346,4 +346,49 @@ Justification of Requirements Each requirement shall have a rationale or justification recorded in a dedicated section of the requirement file. See *rationale* attribute for -:ref:`ReqEngSpecItems`. +:ref:`ReqEngSpecificationItems`. + +.. _ReqEngValidation: + +Requirement Validation +---------------------- + +The validation of each :ref:`SpecTypeRequirementItemType` item shall be +accomplished by one or more specification items of the types +:ref:`SpecTypeTestCaseItemType` or :ref:`SpecTypeRequirementValidationItemType` +through a link from the validation item to the requirement item with the +:ref:`SpecTypeRequirementValidationLinkRole`. + +Validation by test is strongly recommended. The choice of any other validation +method shall be strongly justified. The requirements author is obligated to +provide the means to validate the requirement with detailed instructions. + +.. _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. |