All of its” Conditions must be “true”, for that specification to apply.
Goal [Germany, Teachers]: 65%.
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%.
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.
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.
Project Manager Attendance:
Goal [By = Next Year, Market = London, Activity = Customer Meetings, Event Condition = If Sale Agreed]: 90%.
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.
• 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)
Tolerable [Europe, Year = After Ten Years, Peace]: 60% ±20% < Annual Plan Section 6.4.5.
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.