Start from the outside in. What interfaces does the system have? What are their purposes? How and where does the system store data? What executables are there?

Start from the outside in. What interfaces does the system have? What are their purposes? How and where does the system store data? What executables are there? What are their purposes? Why was it separated as it is? What communication channels are there between the executables? For the more complicated executables, what components do they have and how do these interact? Why are these components as they are and not different? This is kind of a hierarchical breakdown that would map quite well into parts, chapters and sections of a document. From that level downwards there should be comments for non-obvious pieces of code. Often the birds-eye-view is what is lacking. One should also be cautious of existing documentation and of people telling you how things are. Often things are stated with great confidence that are not completely true or not true at all or used to be true but are no longer. This is also a danger of any documentation that you would be writing. If you are not keeping it up-to-date and also making sure that people have a way of finding whatever information they need, it might just be a better idea to not write documentation at all.