How to improve your SRS by distinguishing between vague and ambiguous requirements in health IT and medical device systems

Because it’s so easy to build software these days we’re seeing a proliferation of healthcare apps — what’s hard to figure out is whether we’re building the right software. Abder-Rahman Ali, currently pursuing his Medical Image Analysis Ph.D. in France, has graciously agreed to give us advice on how to write good software specifications for health and medical technology solutions. Some of you are probably rolling your eyes and thinking that software requirements specifications (SRS) are old and “tired” and we should be writing agile user stories instead. The reality is that in regulated and safety critical environments we still rely on SRS documents but the complex nature of systems of systems is making even those documents difficult to write. So, we’ll be talking requirements instead of user stories for now. The following is Abder-Rahman’s second installment, focused on vague and ambiguous requirements. He can be reached via e-mail or twitter.

Sometimes, when we pass by a software requirement that is not clear enough, we may say it is vague, and in another occasion, we may say it is ambiguous. Yes, we added such two features to that same requirement by that same person. But, did that person just use those two terms to refer to that that requirement was unclear? Does he just use those two terms interchangeably? Well, the bottom line, do vague and ambiguous mean the same at all? Or, they refer to two different things? This is what we will investigate in this article of our series.

Before beginning this topic, let us see how dictionaries define the terms vagueness and ambiguous.

Of the ways how Merrian-Webster dictionary defines the term vague is as follows:

Not clear in meaning: stated in a way that is general and not specific

Not thinking or expressing your thoughts clearly or precisely

Not completely formed or developed

Whereas, if we see how the same dictionary defines the term ambiguous, some of how it defines it is as follows:

Able to be understood in more than one way: having more than one possible meaning

I like how Diana Santos distinguishes between those two terms in her book, where she argues that vagueness is related to the language system, and thus, is considered systematic, and is a frequent property of the language. Whereas ambiguity is considered an unsystematic and accidental property.

Diana also stresses that for an expression to be vague between A and B, there should be a shared content. That is, having the same linguistic object doing double duty. In this case, we can consider the cases of “either A or not A” as an instances of vagueness. This Vagueness is automatically reflected in the speaker’s performance since it is an essential property of the linguistic system. But, if we go towards ambiguity, most ambiguities produced by speakers go unnoticed, since as we mentioned, it is considered unsystematic.

Put in another way, invitation to critical thinking takes us to the following; If we want to say that a term or expression is ambiguous, is to say that it has more than one conventional meaning. That is, it can be conventionally understood in more than one way.

Let us take an example. If you hear the word “bank”, what would it mean? Some of the meanings for “bank” are as follows:

• a noun for piled up mass, such as snow or clouds
• a noun for the slope of land adjoining a body of water
• a value for the action of putting something of value away in safekeeping

The book also points out that for a term to be vague means that it is not entirely clear what it does and doesn’t apply to.

Cognitive Linguistics: Basic Readings, sums the above up, by mentioning that the difference between ambiguity and vagueness is a matter of whether two or more meanings associated with a given phonological form are distinct (ambiguous), or united as non-distinguished subcases of a single more general meaning (vague). An example for ambiguity as we mentioned is the term “bank”, where the meanings are quite separate. An example of vagueness is “aunt”, where it can mean “father’s sister” or “mother’s sister”, thus, the meanings are united into one meaning, that is, “parent’s sister”. So, the bottom line is that ambiguity corresponds to separation of different meanings, and vagueness corresponds to unity of different meanings.

So, I think we should now start admitting that there really exists a difference between those two terms, shouldn’t we?

Let us come back to software requirements. As Ben Rinzler mentions, the requirements statements must define a specific and testable outcome. That is, a way to measure that the requirement has been met has to be provided. But, such precision will diminish with vague and ambiguous requirements.

Rinzler continues; a vague requirement is that requirement that does not include enough information to establish exactly how to meet the requirement. On the other hand, an ambiguous requirement can have multiple meanings. Such requirement may sound precise, but defines the desired result in terms that can be interpreted in more than one way.

Let us take an example on both vague and ambiguous requirements to make this more clear.

An example of a vague requirement is the following:

The system shall be able to read updates from MedImg

The above requirement is considered vague since what will be “read” and what happens to the data was not specified.

This requirements can be improved as follows:

The system shall be able to import new tumor patient data supplied by MedImg to the radiology management system, for evaluating the tumor to be malignant or benign

An example of an ambiguous requirement is the following:

The system shall be able to provide historical reports

Here, we have to specify what we mean by “historical reports”. Thus, the requirement can be improved as follows:

The system shall be able to provide patient tumor data for the past five calendar years

We will end up the article here at the moment, so it doesn’t grow bigger for the reader. The main point to remember is that vagueness and ambiguous refer to two different terms, and they are factors that diminish the requirements’ precision and its ability to be measured and evaluated.

Stay tuned for the next articles, where we will dig more deep on how to deal and work with such uncertain requirements, and how can we present them in a precise manner.