A functional requirement is unambiguous if and only if:
1) It is written as being equivalent to an assignment
statement. I.e. it is written in terms of inputs,
processing and an output.
2) The words that state the process are either
a) an algorithm or
b) the name of an algorithm.
3) The inputs are
a) constants,
b) names of constants,
c) derived through a chain of unambiguous requirements from
i) numbers at the system input or
ii) names of numbers at the system input.
1) A functional requirement states that the system “does” something.
It defines a behavior. The only behavior that is available to
a digital system is to change the value of a piece of data.
In a hardware system the data might be the value of a register,
or the value of an output signal. In a software system the data
will be a variable, or an output. A statment that tells how
the value of a piece of data is to be changed, is equivalent
to an assignment statement. An assignment statement is made
up of inputs, processing and an output. Hence, a functional
requirement must be written in a way that is equivalent to an
assignment statement. If a requirment statement does not have
all three parts, it is not a functional requirment. If it is
supposed to be a functional requirement, it is incomplete and
hence ambiguous.
2a) If the words that state the process are an algorithm,
the processing is unambiguous. It can be as simple as
“The system shall set the status to 0.” Or it can be
much more complex. But as long as it is an algorithm,
the processing portion is unambiguous.
2b) If the words that state the process simply name an algorithm
the processing portion is unambiguous. Of course, the available
inputs mentioned in the remainder of the requirment must be
sufficient to execute the named algorithm.
3a) The value of a constant is unambiguous.
3b) The name of a constant (“freezing point of water”) is unambiguous.
3c) Any other data name used as an input must come from somewhere.
In particular, it must be either the output of some other requirement
or be a system input. If it is neither of these, than it was made up
out of thin air and is inherently ambiguous.
If the input is the output of another requirement, the value will
only be unambiguous if the requirement that created it is unambiguous.
And so on back to the system inputs.
Hence the Requirements Completeness Excel Macro which will verify
that for each input there is an unbroken chain of requirements
all the way back to the system inputs.
3ci) A system input which is a constant is unambiguous.
3cii) A system input which is the name of a number (the id field of
a command message) is unambiguous. But that means that you have
some sort of an interface document that defines the system inputs
down to the smallest field. Hence the system inputs are all
unambiguous.