|
Page 3 of
5
Quantifying The Qualitative:
how to avoid vague requirements by means of clear specification language
|
Finding Scales of Measure for Less-Obvious Requirements.
Now, if we can just apply these ideas to all qualitative requirements we
would have pretty clear requirements ideas. But a critical problem remains.
If I say weight: you think {Pound, Kilos, Tons, Grams, Ounces}. For some
concepts we have immediate cultural access to one or more acknowledged
scales of measure. Often with internationally standard definitions.
But, for most of the requirements we
will deal with in real life, we cannot think of a scale of measure at all.
Nothing readily comes to mind. And we are not trained to ‘develop’ the
scales of measure. We do not have a catalogue in which to look them up. We
do not have a culture that demands that we find them. So, we give up. We
make excuses: ‘it is qualitative’, ‘it is not measurable’; all of which
means that we are unnecessarily defeated in getting control over the
concepts. They have won the battle and vagueness can ravage our systems at
its leisure.
These are concepts like: -
- ‘easy to maintain’
- ‘portable’
- ‘secure’
- ‘user-friendly’
- ‘safe’
- ‘adaptable’
Yet surely there must be
some approach to quantifying these concepts? We are interested in them
because if they are at ‘bad’ levels, they cost us time and money. So, it is
‘in the cards’ that there must be some way to express how much damage or
good the different degrees of them can cause us.
And, a little common sense
will get you to acknowledge that we could, for example, use scales of
measure like the simplifications below:
|
|
Maintainable: Scale: how fast we can
fix something
Portable: Scale: how much effort
to move to a new environment compared to total new construction there.
Secure: Scale: the % of defined
classes of attacks which would fail to penetrate the system in defined
ways.
User-Friendly: Scale: The time
needed for defined people to master defined tasks.
Safe: Scale: the probability that
defined dangers will result in defined bad results.
Adaptable: Scale: the time or
effort needed to adapt defined systems to defined new requirements.
|
|
Derivations of basic scale definitions
Many of these are obvious when stated, but we may never have seen them
before, so we have some difficulty ‘inventing’ them. However there seem to
be a few basic patterns of scales of measure, and everything else seems to
be a dialect or derivation. I have defined many of the basics in more detail
in my book ‘Principles of Software Engineering Management’
(POSEM).
The
reader is encouraged to copy and make these ideas available to themselves
and their colleagues.
Continuous Improvement on your basic catalogue of Scale definitions
In addition, once you have derived your scales of measure for your
organization’s projects, you will find that the work you have already done,
can usefully be stored and retrieved for future projects. Sometimes it takes
a lot of work to ‘craft’ a really good scale of measure. And some experience
to know if it is good and useful. So we need to be in a systematic
continuous learning mode about these ideas.
A Defined Process for Finding Scales of Measure for
Quality Requirements
In my free Web publication "Requirements-Driven Management" (RDM, 4.4)
there is a slightly more detailed rigorous process defined for quantifying
quality, and the entire book manuscript gives all manner of supporting
detail. But I shall give you the essence here and now:
- Use your common sense to try to work out a scale
of measure
- Look up similar scales of measure ideas in books
and handbooks, including your own company collection of such scales of
measure from previous projects
- Tailor the definition to your current purpose,
using [generic scale definitions] and corresponding [qualifiers] in the
target requirements statement
- If the concept is complex, and no suitable scales
seem to cover what you want control over, then consider ‘exploding’ the
concept into sub-concepts until such a level of detail at which you are
satisfied. Then proceed to step one above for each of the elements of your
definition’s explosion
more... |
|
|
|
©Tom Gilb
2005 |
|
|
|
Back: to
System Development Back to
(previous): Page 2 of
5 |
|
|
|
