Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
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?
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.
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.
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.
or:
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.
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).
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:
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:
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.
No
An unambiguous specification of a computation is a computer program.
