(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.