I use pencil, paper and rubber , It's what I was taught way back in the 80's, call me a dinosaur but it works for me I have never found a piece of software that really meets my needs.
Actually, that's not strictly true, for very complex or very large projects I use a number of design techniques, jacksons structured design and UML mainly. I loe UML because you take just the bits that work for you and do it your way at the same time others can understand it but the real bous is that it kida naturally leads you down an OO route.
You should be fine with paper and pencil and write out use cases
You don't have to be formal, just write down clearly a list of actions that a user can perform. Where they go to perform the actions, what they see when they get there, what ionformation they can complete, what information they HAVe to complete and document the effect this has on the system.
A simple example
Make a up of tea
1) User visits mysite/make_tea
2) User sees a kettle, a tap, milk, sugar, cup
3) User only needs to fill kettle if kettle needs filling
4) User boils kettle
5) User puts tea in cup - Ooops, I forgot to mention that User sees tea in step 2. Must add that in!
6) Users purs boiling water into cup.
7) User might want to add sugar (Note to self - Perhaps a check box to add sugar and prompt user to state how many spoonfulls - Ooops - I forgot to mention that user also sees a teaspoon in step 1!)
8) User might want to add milk - Pour milk function will need a number of millileters as a param
9) User makes the above selections and submits the form.
10) Need to describe what happens when the form is submitted.
11) User is directed to my_site/drink_tea
12) User sees a message "Couldn't make tea! and an explanation of why.
13) User is given an opportunity to correct mistakes
14) ... And so it goes on
But really, just do what suits you.
I would go on to describe a kettle and it's functions and attributes. A Quick example
A Kettle holds water
A Kettle has a size.
A Kettle can be boiled.
A Kettle pours water
Things a kettle can do are functions, or methods, if you prefer. things a kettle has are attibutes (Columns in a table)
The above can easily be converted into a structured diagram of some description but that's not what is important. The really important thing here is that you think about the whole aspect of the application and you make just enough notes to prompt you into going into further detail if you need to.
The devil is always in the detail. Those ommissions regarding spoon and tea are what classically happens when you write a program to make tea from your head rather than from a piece of paper. I know! It's what I just did! Those were genuine ommissions as I wrote it out from my head.
Writing things out in this kind of way is difficult because you are forced to think about every spect of your app, and when you are quite happy that you understand how to make a cup of tea you wonder if it's worth the pain of having to think through all the scenarious, like how to make sure that the kettle won't switch on unless it has water, what happens if there is not enough water to make a cup after it has boiled. Trust me, it will save you a lot of head scratching and refactoring. Remember, it takes time to write code. It takes a lot less time to write a spec.
What you want and what you need are too often not the same thing!
When your head is hurting from trying to solve a problem, stop standing on it. When you are the right way up you will see the problem differently and you just might find the solution.
(Quote by me 15th July 2009)