Much to the astonishment of my warm-weather relatives in Texas, Alabama, and California, I live in an area of the country that receives about 4 feet of snow each year. As with most snow-blessed (or snow-cursed, depending on your point of view) regions, my municipality takes great pride in its ability to minimize the impact of our inevitable snow events. We scoff when our sunbelt brethren are, quite literally, frozen in their tracks by light, slushy glazes. Famously, a local mayoral election turned on this very issue in the late 1970's.

In the hours before flakes begin to fly, a fleet of snow removal vehicles take to the streets and begin the tedious work required to keep the roads freely flowing. To simplify their work, a complex patchwork of "Snow Routes" have been drawn up, and you know you're on one when you see one of these ubiquitous signs:

It seems like such a simple message, doesn't it? "When it snows 2 inches, don't park here." But in conversations with friends and neighbors, I am surprised to find there is no common consensus about what this actually means. Here are just a few of the interpretations and objections I have heard:

• How are we measuring two inches of snow? What if it snowed only one inch on my street, am I still in violation?
• What if it only snowed an inch, but the wind blew the snow around, does that still count?
• Every street has these signs. Where am I supposed to put my car? Am I supposed to drive around aimlessly until it stops snowing?
• Why 2 inches? Don't they mean two inches or more? Or am I safe once the snow gets to 3 inches and beyond?
• Do they mean 2 inches in an hour? A day? 2 inches since they last cleared the street?
• When can I park again? After they clear the street? Technically, that is still "after 2" snowfall"...

I admit, some of these are silly, and readily answered. But the point here is that, from a single, succinct message, there is so much ambiguity, so much room for interpretation. And the cost of not getting the interpretation correct is a parking ticket, and possibly a towed vehicle; an inconvenience and aggravation for sure, but hardly the end of the world.

Now take this a step further, and suppose that, instead, the sign read something like a typical business requirement. Something like, "The system shall allow the user to browse through a list of available services." The ambiguity, room for interpretation, and lack of clarity is magnified many times over, in comparison with our simple sign. One way to add clarity is to decompose the requirement into finer levels of detail, successively defining each piece of the requirement into atomic levels of text, whose meaning is clearly understood by everyone. Indeed, many companies do just this. They end up with giant spreadsheets of requirements with 10 or more hierarchical layers and thousands of rows. It takes time to thoroughly review these types of documents, and business stakeholders tend to lack the necessary bandwidth to do so. Likewise, downstream consumers like developers, QA personnel, consultants, and technical writers are often awed by such lists, but don't necessarily understand the requirement any better. This requires that they interpret the ambiguous requirement in their own way, which may or may not meet the original business need. If they miss the mark, the resulting rework will cost significantly more than a parking ticket.

Another approach would be to recognize, as our No Parking sign illustrates, that natural language is often an imprecise means for communicating even simple concepts. Most people process and retain greater information detail when it is communicated in multiple forms. Many of the objections I listed above could be assuaged by adding diagrams, and / or public service announcements showing which conditions warrant a parking ban, and what to do about it. Likewise, adding clarity to requirements requires that we not only add detail to the text, but we also provide additional clarity through other communication means. Perhaps a business process is required to add context; or a user interface may be deployed on a use case step to specifically define system behavior as it meets the requirement goal. Communicating multiple aspects of a requirement is not easy, but a lifelike simulation that incorporates all these aspects can ensure all facets of the requirement are understood.

The equivalent, from a snow removal standpoint, would be a perfect understanding of the factors that produce significant snow events, resulting in accurate forecasts months ahead of time. Wouldn't that be something? With a warm, sunny forecast known well in advance, I might even be able to convince my relatives to come visit us some January.