MacLean introduced the notion of criteria and criteria that are more general in order to gather criteria. Having the same name for two concepts makes diagrams fuzzy, thus we decided to define criteria that are more general into factors (which is a concept largely used in software engineer-ing). We exploit the definition from McCall’s work on factors from [15] and from other work that defines a relationship between criteria and factors. The notion of criteria in QOC is thus defined by the following: quality factors correspond to requirements expressed by the clients and/or users; (2) quality criteria are elements that can be measured; (3) metrics: is the actual value of a couple option–criterion for a given scenario of use. Metrics values can be written on the connector between an option and a criterion. Metrics information must be considered as quantitative information and not as qualitative information. Additionally, previous work [13] we have done in the field explains how such values can be computed using performance evaluation techniques.
Buckingham Shum’s [26] usability studies on QOC notation reveals that QOC users need to be able to compare the criteria related to an option (i.e., to express which one is more important for instance). To address this issue, our proposal is to associate a weight to criteria and to factors. Weights range from 1 (important) to 5 (optional). This extension allows users to capture more information in the models. However, Buckingham Shum warns that weight can make it possible for users to distort argumentation.
We propose to relate argument entities, previously defined by MacLean, to all elements of the models and not only to argue the evaluation put on the links option/criterion.
