[eluser]kgill[/eluser]
What your list describes is pretty close to classic waterfall methodology, if you're curious about these things google software development life cycle (SDLC) or software engineering. The typical way to go about it is a little more formalized but pretty much the same as what you're doing. Meetings with the client to determine what they want, those get formalized into a requirements document which describes what the software will do - aka everything that you're required to deliver and needs sign off from the client and yourself. This is what prevents the client from coming back later and saying oh can you also do this - adding to the requirements means revisiting cost.
Your step #2 corresponds to the functional spec and design phases though if you're doing it correctly there shouldn't be a lot of going back and modifying the database once you're done. When we're spec'ing out a new system my co-workers and I will spend weeks with a whiteboard arguing over the data model making sure it is capable of doing everything we need it to, very rarely does it get changed once we've picked it apart like that. What that involves is just a lot of asking what if and how do we handle this... no coding takes place until we're satisfied with the data model. In a team like ours one change in the DB can mean every one of us having to fix our code depending on the table that got touched and nobody is happy about that. Once we've decided we're happy with the data model one of us will document it in Visio and generate it. So that answers your question of what do you do if someone wants to see documentation, you hand them the ERD (entity-relationship diagram).
The rest is pretty much as you're doing now development, testing, implementation and sign-off.
