Source: http://www.apdex.org/index.php/2010/08/apdex-g-section-2-index-overview/
Timestamp: 2019-04-18 10:35:02+00:00

Document:
The introduction contains a brief description of the reasons for reducing a set of measurements to an index.
Section [2.1] corresponds to Apdex section §2.1. I have generalized the language, and made the last two goals (comparability among tools and applications) more realistic. This section was originally discussed in Core Apdex Qualities.
Section [2.2] corresponds to Apdex section §2.2. I have added definitions for some terms used but not defined in the current Apdex spec, and introduced Measurement Domain and Tool Creator.
Section [2.3] replaces all the material currently found in Apdex section §2.3, which will be reviewed later for inclusion in Apdex-R.
Section [2.4] replaces all the material currently found in Apdex section §2.4, which will be reviewed later for inclusion in Apdex-R.
Section [2.5] presents the most significant changes in section . The difference is illustrated in Figure 1 below. First, section [2.5] defines three Satisfaction Levels. Next, section [2.5.1] defines Thresholds as the boundaries of Performance Intervals, which are ranges of values within the measurement domain that share a common satisfaction level. Finally, section [2.5.2] defines Performance Zones as a collection (union) of one or more performance intervals. The arguments for these proposals were presented in Configurable Zone Alignment in Apdex-G and Generalizing the Apdex Thresholds. The extensive discussion of threshold relationships at the end of section §2.5 will be reviewed later for inclusion in Apdex-R.
Section [2.6] corresponds to Apdex section §2.6.
There are many aspects of performance relating to the delivery and management of information technology. One critical performance factor is the responsiveness of the human-computer interface from the perspective of the human user. This responsiveness is a core quality of a transactional application. The speed by which an application reacts to the needs of the user directly affects the user’s productivity and satisfaction with the application experience. It is a critical metric of application performance that has direct implications for business revenue, customer retention, and user productivity.
Therefore, measuring and tracking application response time is important to an enterprise that values the opinion and productivity of its users’ experiences. However, measuring is a necessary but insufficient step in proper management of the user experience. Meaningful reporting of the measurements is equally important. The Application Performance Index (“Apdex”) defines a methodology for reporting the responsiveness of human-application transactions, in terms of its effect on user productivity.
Other Apdex terms are defined in context within this document and its addenda. Section  Glossary collects together all Apdex terminology.
This document specifies domain-independent rules that apply to all measurement types. An addendum may define a class of measurements within a specific measurement domain, and specify supplemental rules that apply only to that class of measurements. The addendum type (see [1.1]) may also be referred to as the Measurement Type of that class of measurements.
Most research into application response times has focused on user attitudes and behaviors when exposed to differing Task times. Since Processes and Task Chains are simply sequences of Tasks, this Apdex specification assumes that applicable research conclusions obtained for Tasks can be generalized to apply to Task Chains also. Therefore Apdex considers that the above discussion of performance zones and thresholds applies either to a single Task or to a Task Chain (a sequence of related Tasks).
Because the set of Task times comprising a Task Chain time are likely either to be independent (because environmental conditions affecting one Task have no effect on other tasks in a chain), or to be positively correlated (because Tasks share a common system environment) it is reasonable to generalize the conclusions obtained for single Task times to Task Chain times. Such a generalization would not be valid if the Task times comprising a Task Chain tended to be negatively correlated, because in that case (for example) user frustration with one task could be offset by obtaining rapid response time from another task in the chain. Users accustomed to such offsetting behavior might well expect smaller levels of variance in total Task Chain times, and thus develop thresholds for Task Chains that were lower than the sum of the individual Task thresholds, and which did not adhere to the rule that F is four times T. In this situation, the proposed Apdex mathematics would still work, but the resulting Apdex score might well overestimate the users’ perceived quality of a Task Chain. At present, Apdex considers that such negatively correlated Task times are unlikely to occur in practice.
I am unsure whether to capitalize and/or bold Apdex terminology (a) when it is first introduced, and (b) when it is referenced later. In section [2.5] above I experimented with using bold face for terms of art that are referenced within definitions.
I am considering using glossary-style definitions when introducing terms within the body of the document. This approach, illustrated in [2.2] and [2.5] above, allows definitions in the glossary to be made identical to their counterparts in the earlier sections of the spec.
I have edited sections [2.3] and [2.4], introducing the terms ‘Measurement Type’ and ‘Measurement Subtype’ to avoid confusion with ‘Measurement Domain’, which was already defined in [2.2].

References: §2
 §2
 §2
 §2
 §2
 §2