I'm going to answer the more generic question, not the one you specifically asked.

1. Gather up all your requirements and organize them. Sift through them and try and make them less "organic" and more "holistic".
2. Once you've got that done, then build a design from those requirements. (Note that you might end up with a design radically from your current implementation. This is ok, but something to note.)
3. Make note of those things that differ between your design and your current implementation. Those are now RFC's.
4. As you complete changes in a section, make sure to update the use-case (or design) associated with that section.
5. Last, but not least, write self-documenting, strongly-cohesive, loosely-coupled code. You should want to refer to the code if you want to find out what the code does. Refer to the documentation if you want to find out what problems the code is intended to solve.

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.