Posts Tagged ‘context’

Using context to reduce ambiguity

August 22, 2012
Words derive meaning from their context. The meaning provided by the context can reduce ambiguity. For requirements, reducing ambiguity is a good thing, so it pays to keep requirements and their context together in some way.
Compare these 2 sentences:

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”). 
Since this applies to both sentences you could be tempted to conclude that they are equally ambiguous. However, anyone who regularly commutes to Amsterdam on the A2 (like myself) and anyone else with sufficient knowledge of the Dutch road network knows that the A2 ends (or starts) at Amsterdam. Thus, the phrase “in the direction of Amsterdam” in sentence 1 can only mean “in a northerly direction”. Given the context, you would conclude that sentence 2 is more ambiguous than sentence 1.

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?“.