1. There is a 4 mile traffic jam on the A2 in the direction of Amsterdam.
2. There is a 4 mile traffic jam on the A2 in the direction of Utrecht.
Now take a few minutes to answer the following question:
Which of the sentences is the least ambiguous?
If you are not familiar with Dutch topography and the Dutch road network, you can still make relevant observations. For example:
- Both sentences fail to specify the direction of the traffic jam unambiguously. An unambiguous specification of a direction requires either a compass bearing (“in southerly direction”) or a from – to construction (“from Utrecht to Amsterdam”).
Requirements need context too
In the traffic-jam example we saw that context can help reduce ambiguity. (Not always though, as was the case with the second sentence.) The same is true for requirements: providing context can help reduce ambiguity.
If your requirements are nothing more than a list of “shall-statements”, then you have no context to help reduce potential ambiguity. You are making it much harder for yourself than necessary!
What is the context for requirements?
The business environment is typically the context that is needed for requirements. This could be the departments goals and strategy, their products or services, the types of customers they serve, local rules and regulations, business processes, the personnel and their jobs, skills and cultural background, the operating environment – any or all of those things could be relevant context. Even requirements themselves can provide context to other requirements.
There are many different ways to make sure the requirements and their context remain connected: clustering related requirements together, maintaining traces between requirements and context elements, visual techniques (rich pictures, context diagrams, object models, virtual windows etc.), using requirements attributes, document layout (such as headers, sections, indentation), user story templates, a guided tour of the office – just to name a few.
Which technique(s) you use may vary – it depends on stakeholder preferences, available tooling etc. The key thing is that you provide the relevant context in some way or other!
But watch out!
Remember that we are not striving for 0% ambiguity (or 100% unambiguous-ness?). The initial question should not be translated to “Which requirement is the least ambiguous?”, but to “Are these requirements sufficiently unambiguous for the intended purpose and taking into account the knowledge of the involved parties?“.