|
Page 2 of
5
Quantifying The Qualitative:
how to avoid vague requirements by means of clear specification language
Here is some
explanation of the formally
defined language we have just used.
|
Example’s Parameter |
What’s this? |
Used for |
Note also |
|
Weight |
Name of requirements |
Cross referencing, reuse of concepts |
Reduces need to repeat full requirement
many places |
|
Gist (or 'Ambition') |
A rough informal idea of the requirement |
Summarising, getting consensus. |
Useful departure point, but rarely a clear
definition. |
|
Scale
|
Definition of the requirements scale of
measure |
Getting precision and clarity. Defining the
concept. |
Useful departure point, but rarely a clear
definition |
|
Meter |
Definition of how we are going to measure
or test the attribute in practice |
Agreeing as to how the requirement
fulfillment will be judged in practice. |
Contractual use. |
|
Past |
A benchmark of past status for that
requirement |
Knowing the meaning of concepts like
“improved” |
Contract. |
|
Must |
A future requirement target which is
necessary for system survival. |
Early delivery minimum levels. Tradeoff
minimum levels. |
Useful reference point.
|
|
Plan |
A future requirement target which is
necessary for success and satisfaction |
Understanding the full requirement. Knowing
when to stop designing and building |
Contract full payment level |
|
Did you notice that each statement could have several components?
|
|
Parameter Name |
Qualifier |
Level on Scale |
Source of the level |
Plan |
[End Next Calendar Year, Me] |
100% |
<- New Year Resolution |
|
|
|
|
The parameter name is a
predefined concept in the 'Planguage' planning language. It has a precise meaning and function.
The qualifier(s) distinguish between different required
levels at different times, places and under different conditions [when,
where, if]. They allow you to specify requirements in three basic dimensions
of time, space and event. A requirement does not have to be a simple point,
it can be a curve. And there can be several dimensions of these curves. This
allows requirements to be stated for both the short term and the long term.
It allows you to differentiate requirements for different customer types,
users and products. It allows you to state requirements conditional upon
certain events, or certain conditions, being true.
For example: |
| Plan [Children, If
living with a Parent] 20, [Children, If NOT living with at least one
parent] 30. |
|
|
The Level on the scale is where we
get really precise about the requirement. This does not mean we have to know
some exact correct value, because ‘greater than 20%’ or ‘20% plus/minus 5%’
or ‘over 20 years old’ are also precise in their meaning, without being
unnecessarily exact in pointing about a particular level. The level
specification has no meaning without us also knowing the defined ‘Scale of
measure’, and the ‘qualifiers’.
more... |
|
|
|
©Tom Gilb
2005 |
|
|
|
Back: to
System Development Back to
(previous): Page 1 of 5 |
|
|
|
