An instruction is ambiguous when it can reasonably be understood in more than one way.
People deal with ambiguity constantly.
We use context, habits, tone of voice, and prior experience to guess what another person means.
Computers need the ambiguity resolved in the program or data.
Consider:
Which match is “next”?
Possible meanings include:
Until the meaning is defined, different implementations could all claim to follow the instruction.
A more precise version might say:
Now several assumptions have been removed.
The instruction identifies:
Precision does not mean using complicated words.
It means making the intended meaning clear enough to apply consistently.
Consider:
Which player?
The sentence assumes that some earlier context makes the identity obvious.
A clearer instruction is:
The second statement carries more information about how the player is identified.
Words such as these can hide ambiguity:
Those words are not always wrong.
They become risky when the thing they refer to is unclear.
Some verbs sound useful but do not define a technical action well enough.
For example:
What does “handle” mean?
Should the program:
A stronger instruction names the intended action:
or:
The more observable the action is, the easier it is to decide whether the instruction was followed.
Consider:
That instruction might need a condition.
Perhaps the player should be added only when the player is available.
At this point in the course, you do not need to write conditional code yet.
You do need to recognize that an instruction can be incomplete when an important situation has not been defined.
A requirement should not leave major decisions to accidental interpretation.
A word can be familiar and still be technically unclear.
Consider:
What does active mean in this system?
It could mean:
If the program needs to use the concept, the system needs a defined meaning for it.
Domain vocabulary is useful only when the people and software working with it share the same interpretation.
Consider:
A person may naturally assume:
But if the sequence matters, state it clearly.
A more explicit instruction is:
The second form makes the dependency visible.
Precision does not mean describing every physical or visual detail.
Suppose the real need is:
Adding instructions about:
does not make the technical instruction more precise.
Useful detail is detail that removes uncertainty about the required system behavior.
This is abstraction again.
Include what matters.
Leave out what does not.
A useful way to find ambiguity is to pretend you cannot make assumptions.
Read:
Ask:
You do not need to turn every requirement into a giant paragraph.
You need enough information that the intended result is not based on guesswork.
A first version of an instruction may reveal ambiguity only when someone tries to follow it.
That is normal.
Revision can move from:
to:
The second version did not become “more technical” by using difficult vocabulary.
It became more precise by making the intended information and context explicit.
If a requirement says:
there is no clear result to compare against.
If it says:
the result can be observed.
Clear requirements make testing possible because they give you an expected outcome.
Precision therefore supports both implementation and verification.
When you read or write technical instructions, look for places where a human reader might silently fill in missing information.
Ask:
Every ambiguity you remove makes the instructions easier to implement, trace, and test.