It is important to give deep thought as to what you want to accomplish with the software. If you tell a builder that you want a building and give no other amplifying information, what do you think you would get? Would you get a house, a garage, an office building, or something else? About all you can be sure you will get is a floor, roof, walls, and doors. Now suppose you tell them you want a house. With this increased specificity, in the US, you are likely to get a building with a kitchen, bathroom(s), living room, and bedroom(s).
This is still far from enough information to be sure you and the builder are thinking along the same lines. You could be thinking the White House and they could be thinking a starter house. The more detail you give the builder, the more likely you are to get what you want. This same concept applies to developing a software product.
There are 2 main categories of specifications. There are functional specifications that specify what the product is supposed to do. Then there are technical specifications that explain how the product does what it does. The technical specifications are much more detailed and without specific knowledge of the technology being implemented, you should avoid trying to get to this level. A technical person generally needs to write the technical specifications.
When developing your functional specification, you will need to specify the requirements. Requirements are what the application must do. You can list these out.
Use cases for showing user perspective
Use cases are a way for defining how a subset of the functionality works from the perspective of a user. For example, let’s talk about the how a user logs in to a web application. Your use case could be stated as:
The user opens their browser and navigates to http://somedomain.com. The user clicks on the login button. The login form is displayed to the user. The user enters their username into the user text box and their password into the password text box, and then they click on the submit button.
For every interaction your user will have with the system, you should have a use case. Notice that the use case specifies what the user is interacting with.
Prototypes help developer understand what you are thinking
In order for the developer to have an idea of what you are expecting, you should create a prototype. This prototype is a way giving the developer an idea of what you are expecting it to look like. A prototype (also called mockup) is much cheaper than getting working software to this point, and finding out that it will not meet the user’s needs. A prototype could be as simple as a drawing on a piece of paper or on a white board and taking a picture.
I prefer to use Balsamiq Mockups to do my prototypes because they have a wide variety of components I can use to convey what the app should look like. You can also take screenshots of components or parts of screens that you like and assemble them to look the way you want your screen to look. Others prefer to use PowerPoint or MS Word to create their mock ups.