|
Overview:
Qualitative
requirements can and should always be specified as clearly as possible. Most
people do not know how. Everybody can learn how. Organizations should insist
on quantitative clarity for all critical qualitative aspects of their
project, process or product. The main concept is to define an ‘operational
scale of measure’ for all qualitative requirements. (Note: some people refer
to these as 'non-functional' requirements.)
Current Culture:
We have all seen
requirements of the type: -
Change: {enhance, improve,
reduce, increase} to...
Something: {performance,
ease of use, maintenance costs, productivity, security, adaptability}.
For example:
"substantial increase in our product’s ease of use for the customer"
Such statements are
even called "non-functional requirements", which is evasive. They are
‘quality requirements’. They are not functional requirements (what the
system shall do), they are not cost requirements (which resources the system
shall use), nor are they design ideas (what we will do to make the system
meet its requirements). They are also not, general constraints (which create
a fence around permitted and not permitted areas of requirements and
design).
For certain limited
purposes, such as emotional management speeches, or hiding the real
objectives, these vague statements can be useful. For serious projects with
large investments, long duration projects, high impact results, high risk
situations, this primitive culture is unnecessary and unacceptable.
One top manager I
worked with (Dr Robb Wilmott, Chairman of ICL) realised this when I pointed
it out, and turned around same day (in about 1983) to his direct reports and
said they would get no more money or power from him without quantification
of all those wonderful things they had been promising him. That led to a
culture change at the top, and a company that went into profit and stayed
there, while almost all competitors ran up losses. But, the first thing I
had to do was to tutor the directors on how to quantify their glorious
futures. Not one of them had any previous training or culture in doing so.
Another company, Douglas Aircraft, in 1987-9, I was enlisted to teach the
engineering managers and senior engineers “How to quantify the
Unquantifiable”. They were motivated when they saw it was possible. But
their engineering training, management training and company culture had
never shown them how to quantify qualitative ideas in general.
There are
several companies which already have clear top management policies about
quantifying quality requirements and objectives: for example ICL, Ericsson,
Hewlett-Packard, and IBM, and maybe yours if you dig enough. But most
companies have not taken a position on the subject. And even when they have,
the top management wisdom is not always backed up by a pervasive company
culture, and necessary training.
Well if
you want an interesting mission in life, this is your opportunity.
The rest
of this paper will assume that you would like to know how to quantify
qualitative ideas, and will concentrate on the how.
Expressing a Variable Idea as a defined Scale of Measure
Let me show you a set of
ideas for describing a qualitative idea.
For example: “reduce
weight” can be expressed as…
|
