I'm gonna go in the opposite direction of @michielsikma and say that it's very import to be very specific from the beginning on what you spec for a project, especially if it's paid work and your making a written contract.
Contracts are binding and a breach of a contract can be taken to court, usually small claims or whatever court in your country deals with lawsuits under $xxxx.
Do you need to say specifically "Home page will use a while loop, read from mysql table new_products and produce display a list of products with a sample image, price and link to view details" no, I don't think most people are expecting that. But the spec might look like:
Home page
List new products with image and details link
Quick link to Cart
Quick link to Sales email / form / phone number
etc...
The spec gets easier if theirs an approved design already created. Then you can break the design down into each page and the spec basically just reiterates what the design tells you to do.
Going back to above - if the spec says specifically what the app / site will do, and both of you sign it, it can be legally binding so make sure it says everything your responsible to do and if it's a big enough point, the stuff your not responsible for also - ie: "Hosting will be provided by AWS. Client will sign up for an account, give me the username / password. I will design and deploy the servers. A separate contract will need to be decided on for ongoing support"
With that, your putting it on them to choose the username / password, you build the server as you need it and when the project is done, your not on the hook to support it unless your getting paid.
So in the end - be very specific with what you'll build and won't build, but don't make it so fine grain that they need to be programmers to understand it.