It seems to me that you cannot possibly write a software specification in English that is completely free of ambiguities, simply due to the informal nature of natural language - and therefore that a truly unambiguous specification must include code written in a formally specified language.

Is this a known result or am I missing something?

  • 1
    "code written in a formally specified language". That would be mathematics and logic, right? Isn't that what math and logic are for? It seems odd to ask, since these languages have always existed for the express purpose of being unambiguous. Why ask?
    – S.Lott
    Sep 9, 2011 at 2:22
  • @S.Lott: Users want specifications in their own language, not math or formal logic. It is our job to translate between the two domains.
    – tdammers
    Sep 9, 2011 at 5:58
  • 2
    Your code may be unambiguous, but that doesn't mean it's correct.
    – JeffO
    Sep 9, 2011 at 6:00
  • 1
    @tdammers: What? The question was on natural language vs. formal language. What do users have to do with this? Further, what if the user actually is a logician? Further, don't "business analysts" usually write on behalf of the users? The "user" thing seems specious and outside this question.
    – S.Lott
    Sep 9, 2011 at 10:09
  • @S.Lott: I was assuming a situation where you have to describe the software to a customer / user / other non-technical stakeholder, which would be the best reason for wanting to use a natural language in the first place.
    – tdammers
    Sep 9, 2011 at 15:36

13 Answers 13


Isn't this what lawyers always did to avoid ambiguities?

The result is they write in the most unnatural ways, trying to read their papers is more difficult than ever, and despite this there are always inconsistencies and ambiguities.

You are right, you cannot write a software specification that is completely free of ambiguities, but you won't manage to do that implementing a formal specified language either.

This is also why we document our code, because sometimes it's difficult to read for our minds.

No point in documenting code with another code.

  • 2
    Some lawyers like to obfuscate and obscure things. Depends on your goal.
    – duffymo
    Sep 8, 2011 at 19:57
  • 1
    You are confusing lawyers with mathematicians.
    – Doc Brown
    Sep 9, 2011 at 6:34
  • 1
    @Doc: Math is just another code, because only mathematicians can read it, and there's no point in documenting code with code, that's cryptography.
    – Jose Faeti
    Sep 9, 2011 at 6:41
  • 2
    @Jose: I would say you are heavily oversimplifying. 99% of all mathematical proofs are written in natural language - of course, a technical language with special terms and more or less making use of formulas, but surely no "formally specified language".
    – Doc Brown
    Sep 9, 2011 at 11:20
  • @Doc: that's what I'm saying... docs written in natural language. Non sense explaining a code with another code.
    – Jose Faeti
    Sep 9, 2011 at 14:27

Impossible? Let's ask if it's desireable first. If we agree that it's impossible, and there's still lots of useful software out there, then the goal of an unambiguous specification seems academic.

I'd say that it's impossible to prove that anything is perfect and unambiguous, both for the spec and the software.

I think it depends on the size of the problem. If the problem is small enough, mathematical in nature, and perhaps some other criteria that I'm missing I'd say it's possible to write an specification that's workable.

The larger the problem, the wider the audience, the harder it is to do.

But avionics and other complex problems suggest that it's possible to write "good enough" specifications in English to solve large problems.

  • 2
    "good enough is good enough, but perfection is a PITA" - I used to work in building environment controls, and there is no such thing as a completely unambiguous spec there, even when they run to 400 pages - sometimes it didn't matter, and for the times it did we had RFIs
    – HorusKol
    Sep 8, 2011 at 23:32

well.. a completely unambiguous specification of the problem is the actual code itself :)

This is a known problem and for special mission critical systems it is mandatory to write unambiguous specification in a formal (programming) language and then transform that to a code that is provably does what the specification says. This is a very narrow field, 99.999% of the developers never has to do tasks like this, but I once talked with a guy who did this for a traffic controlling/railway system.


I'm a W3C follower guy, and I tend to write articles based on their specifications. My experience tells me that reading any specification without written example codes, is simply a headache.

I completely agree and I think the main reason is that, developers tend to read and understand code better. Just imagine you get a mathematical paper without any formula.

To calculate the result, simply add variable x to variable y, 
and then divide that by the b factor.


result = (x + y) / b

Which one is shorter? Which one is more readable? Which brings more comprehension with it?

The same is true about specifications. Many times, when you get to the technical parts, writing one line of code can clarify a lengthy paragraph of explanation.

  • And even then, I'll ask what are the domains of (x + y) and (x + y) / b. Are they double? Are they integers? Are they infinite-length integers? I hope, if they are integers, you wrote the rules about rounding :-)
    – xanatos
    Oct 3, 2011 at 10:46

Assume there is a formal language which allows to write unambiguous specifications. Then I propose that there should be a bijective mapping to a subset of English. Therefore, it should be possible to write unambiguous specifications if you stick to this subset.

But any formal language that is expressive enough to do anything interesting will not be free of inconsistencies (Gödel incompleteness).

  • I'm sure that reasoning is ambiguous as it's in plain english. Could you write it in a formal language?
    – blubb
    Sep 8, 2011 at 19:54
  • 1
    I believe that this is your assumption: citeseerx.ist.psu.edu/viewdoc/summary?doi=
    – Thomas Owens
    Sep 8, 2011 at 20:01
  • And then there is the halting problem, which translates to ambiguity: N is greater than N by 1 doesn't define N
    – mojuba
    Sep 9, 2011 at 6:41
  • 1
    -1 for getting Gödels Theorem wrong.
    – Ingo
    Sep 9, 2011 at 12:11

Specifications are ambiguous and imprecise because people are ambiguous and imprecise. Find a perfect person and perhaps then you can get a perfect specification.

English, Swahili, Sanskrit or Babylonian makes no difference.


Ambiguity is actually a strength in this context.

To explain why, let's assume for a moment that it is possible to use the English language in a completely unambiguous way, so that any problem that can be solved programmatically can be expressed completely and unambiguously. If we use this variant of English, and our description does indeed describe the program to be written completely and unambiguously, then it logically follows that is must be possible to perform an automated translation into the target programming language - in other words, the variant of English we have conceived is actually a programming language itself.

People who read design documents (especially functional designs) don't actually want this level of detail - reading a program's source, whether in C++, Java, or Unambiguous English, is way over the average non-programmer's head. This is where natural languages come in: they allow the writer of a specification to slide either way on the detail scale, moving irrelevant implementation details into subtext, or leaving them unspecified entirely. Natural languages are full of devices to convey meaning relatively clearly even though you are not providing an exact definition (which is part of what makes automated translations so hard).

So the goal is usually not a complete, correct and unambiguous spec; the goal is to write a spec that illustrates clearly, to humans, what you are about to build.

Whenever you do need correct and unambiguous, and things are getting technical anyway, pseudocode is often more valuable than either natural languages or rigid formal ones - it can still leave out irrelevant details (by calling unspecified functions / processes), but the structure is unambiguous.


You're not missing anything, except that documentation is written for humans to read. Some ambiguity is expected, and even welcome, because terse text is difficult to read (=not for humans).

Specifying documentation for a formal language in yet another formal language would be a sort of chicken-and-egg problem.

If you really need formal specification, then there are formal ways of checking models. It's an active and very interesting area of research, but the end "users" here are machines, not humans.


(Some of my points have already been alluded to by other answers, but I feel that I'm providing a different enough perspective to make this worth an answer rather than a comment.)

Before we address the issue of whether a specification can be truly and completely unambiguous, we must address the question of whether it should be unambiguous, at least at the level that you are asking about.

Let me approach this from the perspective of a program manager working on a small-to-medium sized project, or a feature as part of a larger project. There are usually two different types of specifications that will be written for such a project: a Functional (or PM) specification and a Design (or Dev) specification:

  • The Functional specification has the job of describing what the projecty or feature should do, often from the perspective of the customer. It should not, in general, describe how this should be done. Depending on the type of project, the customer may care what the external-facing API looks like, but does the customer care whether class A inherits from class B or implements interface C? He shouldn't. And neither should the functional specification. This already introduces one level of ambiguity: that of technical design.
  • The Design specification has the job of describing how the functional requirements should be met, from the perspective of the architect or technical designer of the feature or project. It is intended to resolve the high-level ambiguities of technical design. This will contain those details that you didn't want in the functional specification, such as the architecture of the solution, including class sctructure, inheritence, perhaps even individual functions and methods, depending on the scope and scale of the project. Does the architect care what you call your temporary variables or whether you use a list or an array for an internal datatype? Assuming she trusts her developers, she shouldn't, and neither should the design specification. This introduces a second level of ambiguity: that of implementation.

In general, these implementation-level details are not captured in a formal document, but rather documented, per se, in the code itself, including the comments. This level of ambiguity allows a good developer to use his or her own skills and make the detail-oriented technical decisions that are the hallmark of a good individual developer. Because of this, I will not hesitate to say that ambiguity in a specification is, in fact, a good thing: it allows developers to do their jobs, and elevates them above mere "code monkeys".

This isn't to say, however, that there should be ambiguity through the whole document. On the high level, there should be no ambiguity about the interface with the customer. If the feature has a public-facing API, it should be strictly defined. If the system requires a date to be passed in to do it's job, should this date be in the local time zone or UTC? What format is needed? Does it need to be accurate to the millisecond, or is the minute just fine?

Coming back to the question of whether natural language can be used to create unambiguous specifications, it's true that it isn't very good at capturing this level of clarity. I've seen it done in certain limited circumstances, but those are likely unique exceptions that we can't apply universally. Most often, ambiguity is resolved with the help of technical jargon, diagrams, or even pseudocode. Once you start enlisting the help of such tools, the natural language ceases to be the sole descriptor. Because these tools can make even a completely functionally unambiguous specification much more clear, I would venture to say that such an undertaking shouldn't even be attempted.

Having said that, because natural language is generally supplemented by these tools to make it functionally unambiguous, it is my professional opinion that no, natural language alone is not sufficient to create unambiguous specifications in all cases.


One can make natural language relatively unambiguous, but only with great difficulty.

The legal profession quite desperately needs language to be as unambiguous as possible. While much about how a law is applied may be open to interpretation, what the words mean should not.

This need lead to the invention of legalese. How far are you willing to go?


There are a number of specifications by the open group, ISO, the IETF and ITU that are sufficiently unambiguous for highly competitive companies to interoperate quite successfully. There are a number of specifications that are the basis of contracts or laws where millions of dollars are at stake.

So specifications may not be "perfect". However that is because humans are not perfect. For example it is unambiguous that HTTP should use a "Referer" header - the correct spelling is in fact "Referrer".

The English language is capable of being unambiguous, but humans are capable of making mistakes - including ambiguity.

In addition it may be helpful to be deliberately ambiguous for details that have not been finalised or may need to be updated in the future. For example a specification may specify a "hash" rather than specifically specifying md5, sha1, crc32 etc.


I believe the correct answer is negative. It's necessary to distinguish the following questions:

  1. Is it possible to write a software specification in a natural language that does not contain ambiguities?
  2. Is it possible to write software in a natural language that does not contain ambiguities?

The difference between the first and second question concerns the level of detail involved, the amount of interpretation required, and the rules imposed on the construction of sentences in the natural language for the purposes of writing the software or software specification.

The answer to the second question is affirmative. Given a suitably constrained subset of a natural language with agreed-upon rules for sentence construction and meaning, code can be written in grammatical English sentences. For instance, the following language unambiguously permits writing assignment statements:

Variables: x,y,z,...
Constants: 1,2,3,...
Rules: (1) if x is a variable and n a constant, then
           "The variable x contains the number n" is a sentence.
       (2) if x is a variable and n a constant, then
           "Assign the number n to the variable x" is a sentence.

That is, we can systematically translate code written in formal programming languages into natural languages by describing each procedure. On the other hand, a software specification often requires interpretation. Thus, whether a software specification can be given unambiguously depends on the level of detail involved in the specification. However, given a selected domain over which the specification ranges, with particular operations on this domain selected, a similar translation process can be carried out. For instance:

Over the domain D supporting operations f,g,h over elements a,b,c in relations
P,R,Q with properties φ,ψ,θ, design a program that does X,Y,Z.

where the statements X,Y,Z contain only those items mentioned in the specification's preface and are written in a suitably formal and agreed-upon subset of a natural language. The ambiguities will then concern how to implement the specification - but this will be expected.



An unambiguous specification of a computation is a computer program.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.