On 13/11/2020 20:03, Gedare Bloom wrote:
+Generic Non-Functional Requirement Item Type
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+This type refines the following types:
+
+* :ref:`SpecTypeNonFunctionalRequirementItemType` though the
through?
Nice an automatically generated typo.
+ ``non-functional-type`` attribute if the value is ``build-configuration``
+
+* :ref:`SpecTypeNonFunctionalRequirementItemType` though the
+ ``non-functional-type`` attribute if the value is ``constraint``
+
+* :ref:`SpecTypeNonFunctionalRequirementItemType` though the
+ ``non-functional-type`` attribute if the value is ``design``
+
+* :ref:`SpecTypeNonFunctionalRequirementItemType` though the
+ ``non-functional-type`` attribute if the value is ``documentation``
+
+* :ref:`SpecTypeNonFunctionalRequirementItemType` though the
+ ``non-functional-type`` attribute if the value is ``interface``
+
+* :ref:`SpecTypeNonFunctionalRequirementItemType` though the
+ ``non-functional-type`` attribute if the value is ``interface-requirement``
+
+* :ref:`SpecTypeNonFunctionalRequirementItemType` though the
+ ``non-functional-type`` attribute if the value is ``maintainability``
+
+* :ref:`SpecTypeNonFunctionalRequirementItemType` though the
+ ``non-functional-type`` attribute if the value is ``performance``
+
Is there a specific kind of performance (metric) in mind? latency vs
throughput? Or does it not matter
In the generic non-functional requirements, the requirements text is in
natural language. So, you can write whatever you want.
This patch introduces a specialization for performance requirements
which are expressed in limits of a sample set of some measured runtime
of an operation.
text: |
When a partition has exactly
${../val/performance:/params/buffer-count} free
buffers, the ${.:limit-kind} runtime of exactly
${../val/performance:/params/sample-count} successful calls to
${../if/get-buffer:/name} in the ${.:/environment} shall be
${.:limit-condition}.
In this item, the corresponding test code is also included.
test-body:
brief: |
Get a buffer.
code: |
ctx->status = rtems_partition_get_buffer( ctx->part_many,
&ctx->buffer );
description: null
--
embedded brains GmbH
Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
Phone: +49-89-18 94 741 - 16
Fax: +49-89-18 94 741 - 08
PGP: Public key available on request.
embedded brains GmbH
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
