Specification, User story, Test

Specification. Specification can never be complete. There is certain amount of information needed to build a system. If specification contains that much information, it can be the system itself. In this case, system = specification.
But of course this is not very common scenario. Usually, some "business person" describes requirements for the software, in English, and programmer translates it into formal program. Of course we all know that English is ambiguous, and so there are N persons with N views of what a software should do according to that specification. And more importantly, this specification will not be complete, because there is so much a system can do, those thing which one would call “implementation details” actually creep into “specification details”.
The only way I see of using specification as a single source of truth, is for "business person" to write the program himself.
Some solutions that do not work:
1. Take the right programmer, the one who captures the intent of the specification so well, that the ambiguities of what software should do will never arise.
-- people are just so different. When they are left for their own interpretation, each will produce different results.
2. Write specification in some "specification language", understandable by business person.
-- First of all, has anyone seen formal specification language understandable by business person? Second, if that language is not automatically translatable into final program, and human has to make his own decisions for this translation, he will make those decisions. They are not irrelevant, or else they wouldn't be necessary. And there is no guarantee they will do what you wish, because you jus didn't say what you wish - because you don't know what you wish.

User story. So, reasonably sized software system is an input from many people. Each of them is shaping that software in some way. How then to ensure we are building the right system? User stories seems to be the right way. The idea is to capture input from domain expert by small (i.e., manageable) chunks. Each user story tells a story about user interacting with the system. User stories are not necessarily captured all at once, but just some most valuable system aspects, once in a while, when the need arises to move forward.

Test. Sometimes user stories may not be precise enough. This is where automated tests can help. They are the executable system specification – a thing that formal specification fails to achieve. They can do this because they are incomplete specification, only pinpointing some, very small amount of cases. They are the things nailing down your user story carpets to the ground. As with user stories, they are examples of how a system is used.

So. Specification will not work as a single source of truth for a system. Writing specification and requiring that someone else would do “all the dirty work” will fail. Formal specification = program itself. Specification can be used as a starting point. Specification can be used to model some aspects of a system (it may be easier to write them in some formal language which is not executable (like, some nice pictures), but I believe as SE progresses, such cases will be diminishing ). But most of the time, user stories or similar mechanisms, acting as examples of required system behavior – will yield much better results, because people learn by example, and programming is understanding. Finally, if precision of user stories is not enough, automated tests can cover the most interesting cases, nailing down your system so that it won’t be blown away.