The specification document is like a contract between you and the developer. If the developer hasn’t implemented a feature that you thought it was obvious to have, but it wasn’t specified in the document, it’s your fault.
It is therefore very important to make things very detailed feature-wise. It’s not about where your a form or a button should be placed but more about the interaction between the end user and your software.
In a specification document, I would first describe the project as a whole, including who it is meant for, what problem you solve.
Then, describe the different entities that will interact with each other in your application with simple and short sentences. For instance, for a marketplace application, we would have something like the following:
- A User can be of different types: an Administrator, a Buyer and a Seller.
- All Users have an email, a First name, a Last name, an Address and a Phone number.
- The Buyer can buy Goods from the Seller.
- The Seller can put new and used Goods to sell.
- A Good is composed of a Title, a Description, 3 Pictures, a Price, a Shipping Price.
At last, describe the different views of your application with mockups that can be made with a tool called Balsamiq (https://balsamiq.com/, it has trial version). If you have a specific layout in mind, now is the time to specify it!
If possible, add a description below each of your mockup view to illustrate your idea even better.
Don’t worry if it’s not thorough, it is very normal since you don’t have the same logic as the developer after all. You will ask your CTO to complete it further with technical specifications and also fill the holes. The idea is to give minimal workload to the CTO with what you’ve done with this document. It can even give him an even better understanding of your project.
If your CTO bills per hour, then that would also save you quite a lot of money.
Make sure to download the specification document template from my resource page.