|
Page 4 of 5
Quantifying The Qualitative:
how to avoid vague requirements by means of clear specification language
|
Generic Scale Definitions
One method for making Scale definitions more-easily reusable is to define
them ‘Generically" and let the necessary detail come out elsewhere, in the
Targets {Plan, Must, Wish} statements, and in separate definitions. There
are two main classes of separate definitions:
- Defined terms (A: Defined: a definition of A.)
- Qualifiers (which themselves may be formally
derived), example Plan[1999, USA] 60%
For example: -
|
|
Maintainability:
Gist: ability to fix faults.
Scale: the clock time for [1. defined class of faults] from a...
[2. defined start point, Default:
first knowledge of the fault by any system or person] to
[3. a defined completion point OR Default: the point where it is in
fact correctly fixed, without
any negative side effects and this is verified] by
[4. defined fixing and testing process OR Default: any process] using
[5. defined capability of person OR Default: any one who does the job
in practice].
Past [P1, P2] Average 24 hours <-
Inspection Statistics
Plan [ P1:{Requirements Faults, Detection Logging in Inspections,
Approved in Inspection
Follow up Process, Fixing in Master Specification, Requirements
Author}, P2: First Release to
Field Trial] 10% of Past.
Must [P1, First General Product Release Internationally] 1% of Past <-
George X.
First General Product Release
Internationally: Defined: the date of
access to our product by more than one country, after field trials for
paid purposes.
Requirements Faults:
Defined: any requirement specification judged by Inspection process as
Major defect, which might cause high downstream (design, test, field)
costs to correct the effects
|
|
|
Hopefully, studying this example, will give you some ideas. Notice:
-
The scale is extremely generic, but
it does have automatic defaults, which are reasonable
-
There are five generic parameters
which can be used to define the Scale’s meaning
-
These five can be specified in
target (Must, Plan) and benchmark (Past, Record, Trend) statements any
number of times, in the scope of a single overall requirement definition
(Maintainability)
-
A useful set of these parameters
can be defined once, as ‘P1’ above and reused, to simplify and clarify
(that the same set are intended)
-
‘Names’ or ‘labels’ can be applied
not only to the overall requirement (like ‘Maintainability’) but to any
useful sub-component of the definition (as in the example ‘P1’, ‘P2’)
-
Any parameter concept (for example
‘First General Product Release Internationally’ can be formally ‘Defined’
here locally (as in this example), or in a Project or Requirements
Glossary (‘globally’) whenever we want to give additional unambiguous
clarity to any concept. The general signal that a term has a formal
definition somewhere is given by ‘Capitalization’ of the words describing
it
What I am showing you in this short
article should indicate to you the possibilities for better definition of
not only quality requirements, but any requirements. The above examples only
hint at the richness of the ‘Planguage’, which I encourage you to explore in
my book "Competitive
Engineering". You will even find ready-made defined
standards for specification, which you can incorporate into your company
standards.
Note: the Competitive Engineering
book is accompanied by a comprehensive glossary of the Planguage terms and
concepts. The glossary can be accessed
online at
CE Glossary (N. America) or
CE Glossary (outside N. America).
I will leave you with a set of 10 of the 100
stated principles in the Requirements-Driven Management book manuscript (unpublished)… |
|
more... |
|
©Tom Gilb
2005 |
|
|
|
Back: to
System Development Back to
(previous): Page 3 of
5 |
|
|
|
