Non-quantifiable Requirements

Suppose a requirement is "The automated interfaces of the system must be easy to learn". There
is no obvious measurement scale for "easy to learn". However if we investigate the meaning of
the requirement within the particular context, we can set communicable limits for measuring the
requirement.

Again we can make use of the question: "What is considered a failure to meet this requirement?"
Perhaps the stakeholders agree that there will often be novice users, and the stakeholders want
novices to be productive within half an hour. We can define the quality measure to say "a novice
user must be able to learn to successfully complete a customer order transaction within 30
minutes of first using the system". This becomes a quality measure provided a group of experts
within this context is able to test whether the solution does or does not meet the requirement.

An attempt to define the quality measure for a requirement helps to rationalise fuzzy
requirements. Something like "the system must provide good value" is an example of a
requirement that everyone would agree with, but each person has his own meaning. By
investigating the scale that must be used to measure "good value" we identify the diverse
meanings.

Sometimes by causing the stakeholders to think about the requirement we can define an agreed
quality measure. In other cases we discover that there is no agreement on a quality measure.
Then we substitute this vague requirement with several requirements, each with its own quality
measure.

Requirements Test 1

Does each requirement have a quality measure that can be used to test whether any solution
meets the requirement?

Coherency and Consistency

When a poet writes a poem he intends that it should trigger off rich and diverse visions for
everyone who reads it. The requirements engineer has the opposite intention: he would like each
requirement to be understood in the same way by every person who reads it. In practice many
requirements specifications are more like poetry, and are open to any interpretation that seems
reasonable to the reader. This subjectivity means that many systems are built to satisfy the wrong
interpretation of the requirement. The obvious solution to this problem is to specify the
requirement in such that it is understood in only one way.

For example, in a requirements specification that I assessed, I found the term "viewer" in many
parts of the specification. My analysis identified six different meanings for the term, depending
on the context of its use. This kind of requirements defect always causes problems during design
and/or implementation. If you are lucky, a developer will realise that there is inconsistency, but
will have to re-investigate the requirement. This almost always causes a ripple effect that extends
to other parts of the product. If you are not lucky, the designer will choose the meaning that
makes most sense to him and implement that one. Any stakeholder who does not agree with that
meaning then considers that the system does not meet the requirement.

Requirements Test 2

Does the specification contain a definition of the meaning of every essential subject matter term
within the specification?

I point you in the direction of abstract data modelling principles [7] which provide many
guidelines for naming subject matter and for defining the meaning of that subject matter. As a
result of doing the necessary analysis, the term "viewer" could be defined as follows:

Viewer

A person who lives in the area which receives transmission of television programmes from our
channel.

Relevant attributes are:

Viewer Name
Viewer Address
Viewer Age Range
Viewer Sex
Viewer Salary Range
Viewer Occupation Type
Viewer Socio-Economic Ranking

When the allowable values for each of the attributes are defined it provides data that can be used
to test the implementation.

Defining the meaning of "viewer" has addressed one part of the coherency problem. We also
have to be sure that every use of the term "viewer" is consistent with the meaning that has been
defined.

Requirements Test 3

Is every reference to a defined term consistent with its definition?