A ‘Specification’ or a ‘Spec’ is the piece of paper(s) that declares what your app does and how it is accomplished. It’s the blueprint if you will. There are quite a few ways to do a spec, ranging from the lighter (also sometimes called a ‘brief’) to the enveloping complete enveloping breakdown. No matter which way you choose to go about it, always do a spec. I repeat: Always do a spec.
In client projects, specs are often contracts on which estimates can be based on – the mother document that dictates to all parties involved what needs to be made and (roughly) how. In personal or in-house projects they’re not as commonly seen as a priority, but they should be.
You’d be surprised how much of an idea is further developed, changed or refined when you’re asked to put everything in writing. Areas of uncertainty are naturally brought forward and further questions are raised. In a sense, the act of creating a spec is the first conscious and calculated ‘design’ of the solution. A lot of initial ideas and assumptions are explored and illuminated in this document, which keeps everyone involved in tune with what is being built. It can also be beneficial to periodically revisit a spec and update it retroactively while the project moves into its next phases.
A program like Pages, Word, or any other simple markup editor will be fine for this phase. The real trick is deciding what to include and what to leave out of a spec. It is best to keep things short and concise under the assumption that the more you write, the more can be misinterpreted. List both functional and non-functional requirements. Explain what your app is, and not how it needs to be done. Use plain language. In the end, the best spec is the one that is agreed upon by all parties.
Many articles could be written about the art of a good spec, however, this is not one of those articles. Read more