Jonathan Babcock has posted a very interesting blog entry on the “precision” problem in the requirements definition process. Jonathan draws an interesting distinction between “accurate” requirements vs. “precise” requirements.

To quote his post:

Natural language is inherently ambiguous

The odds are stacked against the BA when it comes to writing requirements that are both accurate and precise, as natural language is inherently ambiguous. The same phrase, punctuated or intoned differently can take on a variety of meanings. For example,

“I, John Doe, am glad to see you here!”

Am I John Doe, and telling someone ( or maybe even a group of people) that I am happy to see him (/her/them) here, or am I addressing myself to John Doe and telling him I am glad to see him here? The statement is accurate, and both are are valid interpretations of the sentence, but only one is the correct result. This is an example of the difficulty I was experiencing with my “accurate requirements”. Different people can understand the same phrase differently depending on the individual and the context. So, how does a BA cope with this?

Some shops adopt different, more precise ways of expressing requirements such as UML, pseudo code, and formal specification language.

This is an excellent entry - read the full entry here.