Hey dwiz,
I'm going through the exact same thing at work right now, and am creating my first technical design/requirements document for software that I'll be implementing. Some tips that I've gotten from fellow developers is to start out with a set of well-defined use cases that sum up the problem to be addressed by your software. Each use case may describe the functionality of a single function or method or it might describe the interaction of an entire subsystem. That's up to you.

The idea is that by describing the whole of the problem in non-technical language you not only allow yourself to more tightly define the scope of your task, but you also provide a good starting place for someone else who might have to pick up where you left off.

As a plus, by fully spec'ing out your project with a bunch of use cases, you've essentially defined what your code will have to do and all you have to do is program to the spec. This is a lot easier than programming the code and then making a spec that matches what your code does.