Motivation

Systems have tremendous sensitivity to errors in a requirements specification even a misplaced comma can have severe consequences. In code implementation, it is obvious that misplacing even a single character can make a great deal of difference. In fact, the accidental substitution of a period for a comma in a single Fortran statement resulted in the loss of the Mariner 1, the first American probe to Venus in 1962. But how can such a serious problem exist when misplacing a character in a requirements specification? Let's see how that might be so.

The title of Lynne Truss's 2004 book on punctuation, Eats Shoots and Leaves, ^[1] could refer to either

• a panda, if the punctuation is as published, or

• a criminal who refuses to pay his restaurant bill if a comma is added after the word "eats."

Clearly the title of the book is not that of a software specification, but we hope this anecdote illustrates that simple punctuation differences can convey a dramatically different message or intent, especially in a requirements specification.

Aside from punctuation, there are a number of problems with conventional software specifications built using only natural language and informal diagrams. These problems include ambiguities, where unclear language or diagrams leave too much open to interpretation; vagueness, or insufficient detail; contradictions, that is, two or more requirements that cannot be simultaneously satisfied; incompleteness or any other kind of missing information; and mixed levels of abstraction where very detailed design elements appear alongside high-level system requirements.