A Qualifier is a defined set of Conditions, embedded in, or referenced by, a specification.

Alternative Names

Concept Number: *124
English Master: Qualifier
Synonyms, Variations & Acronyms: none


All of its” Conditions must be “true”, for that specification to apply.


Goal [Germany, Teachers]: 65%.

Where “Germany” and “Teachers” are each Qualifier Conditions (defined elsewhere). The set of Qualifier Conditions, and the square brackets, form the Qualifier.

A Qualifier defines any interesting set of specific time, location, and event Conditions (also known as Qualifier Conditions). These are sometimes classified as “when”, “where”, and “if” Conditions.

Square brackets around the Qualifier Conditions are used to denote a Qualifier.

An alternative is to use the Qualifier Parameter (which also happens to use square brackets!). For example: Qualifier Tag: Qualifier [Condition1, Condition2]. This is useful when you want to define and reuse a set of qualifiers, especially a Complex and lengthy set. For example: Goal [Qualifier Tag] 60%.




Condition, Parameter.


Goal [German School]: 65%.
German School: Qualifier: [Country = Germany, User =Teachers].

Where “German School” is a defined reusable Qualifier. Tagging a “Qualifier” Parameter, or statement allows us to simplify a large set of Qualifier Conditions, and perhaps to describe or summarize them at the same time. “German School: [Country = Germany, User =Teachers].” would be the logical equivalent to the “Qualifier:” statement above. You can tag a Qualifier directly.


1. Qualifiers can be present in any specification (for example, a System Attribute specification, a Requirement-Specification, a Design-Idea specification, or an Evo-Step-Specification). We expect most Planguage Parameter-Specifications to be subject to qualifiers (either explicit, implied, or inherited).

2. Any number of Qualifier Conditions can apply to a given specification, expression or statement. There can be multiple instances of any one Class of Qualifier Conditions. There is no sequence Requirement for the Conditions.

3. Qualifiers are always specified as sets within square brackets, “[ ]”, even when a “Qualifier” Parameter is used.

4. Qualifiers have to be evaluated to see if they are “true” in any given instance. In the Case of evaluating an Evo-Step, this may be done in real time.

5. Qualifiers have the effect of “dividing up” a System into separate, maybe overlapping System dimensions or “views”. This has many uses. One use is to divide up a System into smaller distinct areas for delivery of Evo-Steps.

6. A Qualifier is a substantial contribution to understanding the Priority of a specification.


Project Manager Attendance:
Goal [By = Next Year, Market = London, Activity = Customer Meetings, Event Condition = If Sale Agreed]: 90%.

The Qualifier Conditions specify when, where, during which activity, and After which event - the Goal has validity – and thus has Priority over any specification that is not yet valid.

Scale: % Uptime.
Goal [QQ]: 99.5%.
Stretch [QQ]: 99.9%

QQ: Qualifier [By End of Year, Home Market, Consumer Goods, If Fierce Competition on Price].
Authority [MOP]: Product Planning.

The MOP Requirement has two distinct Priority mechanisms. The MOP Goal statement has Priority over a corresponding (“has same qualifier”) Stretch statement. Secondly, the QQ tagged Qualifier has a number of Qualifier Conditions that must all be true for either of the target Levels to be in force.

The Authority statement gives additional prioritization information for MOP, in relation to other Requirements with different powers behind them.

7. A Qualifier defines the set of Conditions, which together enable, or “activate”, a related statement. The potential Qualifier Conditions can be roughly classified as:

time Conditions: “when”. Dates, deadlines, relative times to events, weekdays, hours (time spans or precise hour).
place Conditions: any notion of “where”. Geographical location, Type of person or group, or Role (like trainee, teenager, teacher), System Component (like module, program, laptop screen, software, contracts, Standards),
event Conditions: any notions of “if” – any occurrence Conditions (such as:
• activity commenced or terminated (like project started, Policy Issued)
• activity in progress (like testing being carried out, parliament in session, voting in progress)
• specific indicator set (like red light is on)
• specific Status attained (like Approved, Checked)

We can optionally preface event Conditions with the logical “If” Parameter in order to emphasize that we must analyse the Status of the event to determine if the Qualifier Condition is “true”.


Tolerable [Europe, Year = After Ten Years, Peace]: 60% ±20% < Annual Plan Section 6.4.5.

The three Qualifier Conditions must be all three be “true” for the “60%” Requirement Level to be a valid Requirement. “Peace” is an example of an event Condition. Europe is a place Condition.

8. The implication of the Qualifier definition, that all Qualifier Conditions must be “true” to have effect, is that in a Qualifier like [A, B, C], “A and B and C” must be valid for the Qualifier to “enable” its related statement.


[ ]

“Square brackets around any set of qualifiers.”






This Concept entered by Diane O'Brien.

Created by system. Last Modification: Thursday 11 of July, 2019 19:10:09 CEST by Admin (Kai).