[PATCH] eng: Add performance specification items

[Sebastian Huber]

Hello,

On 14/11/2020 12:59, Sebastian Huber wrote:
> 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

I think this can be checked in independent of the open discussion how a 
particular performance limit is identified. The item just uses a string 
to identify a set of performance limits. An open issue is how this 
string is generated and what data it includes.

I already fixed the "though" -> "through" typo.

-- 
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hubere at embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

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/