|
Page 2 of
8
"Rich Requirement Specifications: the use of
Planguage to clarify requirements"
|
There are
aspects of the Requirements Language that make certain aspects of a
requirement reusable across projects. For example: |
| Usability:
Scale: The probability in % that
defined Users can successfully complete defined Tasks under defined
Conditions.
Goal [Users = Novices, Tasks =
Most Difficult, Conditions = {Noise, Pressure}] 60%.
Goal [Users = Experts, Tasks =
Average, Conditions = {Noise, Movement}] 80%. |
|
|
In this case the scale of measure
definition has three scale qualifiers (Users, Tasks, Conditions). These are
defined by corresponding scale variables in the Goal statement. This allows
reuse of the scale in the same requirement definition, but it also enhances
the capability for reuse of that scale definition in entirely different
projects.
|
|
Principle R2: The
requirement should give information allowing us to check its quality. |
|
What is the ‘quality’ of a requirement specification? Different people are
going to give very different answers. But here is mine. There are two
distinct quality aspects of a requirement specification:
- the intelligibility of the specification
(even though it is wrong or bad!)
- the relevance of the specification to the
stakeholder world (does it really fulfill the real needs of stakeholders?)
– even though it may be unclear
The requirements language has a large array
of tools addressing these two aspects.
Let us first look at the issue of
intelligibility:
|
| Reliability:
Scale: Mean Time Between Failure
Goal: 20,000 hours |
|
Some simple notions of intelligibility in this
basic example are:
- the requirement is given an intelligible
reference name (Reliability)
- the requirement is described by a set of
clear language parameters (Scale, Goal)
- distinct concepts are clearly separated
(the name, the scale of measure, the target level)
The language parameters themselves are
formally defined in the requirement language concept glossary, so that the
parameters have an exact meaning. For example:
|
|
Goal
Concept *109 March 15, 2003 |
| A goal is a primary
numeric target level of performance.
A Goal parameter is used to specify a
performance target for a scalar attribute.
A Goal level is specified on a defined
scale of measure with its relevant qualifying conditions [time, place,
event].
An implication of a Goal specification
is that there is, or will be, a commitment to deliver the Goal
level (something not true of a Stretch or Wish target specification).
Any commitment is based on a trade-off
process, against other targets, and considering any constraints. The
specified goal level may need to go through a series of changes, as
circumstances alter and are taken into consideration.
A specified Goal level will
reasonably satisfy stakeholders. Going beyond the goal, at the cost
of additional resources, is not considered necessary or profitable –
even though it may have some value to do so.
|
|
|
(and this snippet does not include the
extensive notes also found in the glossary)
Of course the exact content itself is
critical to intelligibility, but we are just mentioning some of the
intelligibility concepts, not all of them.
more...
|
|
©Tom Gilb
2005 |
Back to: System
Development
Back (previous): Page 1 of 8
|
