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:
Display the next match.
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:
Display the Wildcats' future match with the earliest scheduled date.
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:
Find the player and display their number.
Which player?
The sentence assumes that some earlier context makes the identity obvious.
A clearer instruction is:
Find the player whose name matches the selected roster entry, then display that player's jersey number.
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:
Handle the player information.
What does “handle” mean?
Should the program:
A stronger instruction names the intended action:
Display the player's name and jersey number.
or:
Store the player's availability for the selected match.
The more observable the action is, the easier it is to decide whether the instruction was followed.
Consider:
Add the player to the lineup.
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:
Display the active players.
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:
Save the player's availability and show the confirmation.
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:
Display the available players.
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:
Select a player and update the record.
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:
Show the team.
to:
Display the name of the team selected for the current match.
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:
Make the lineup good.
there is no clear result to compare against.
If it says:
Display only players marked available for the selected match.
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.