>>Is there any tool or any approach that I should know to document an existing system?

All documenation is a PITA, of course. But at my agency the top powers have decided we need more bureaucracy (er, I mean Documentation). For legacy reasons, if nothing else, I agree with the documentation ideas below.

What I have decided on (having some degree of input on this, and I know a lot more than the top management about grunt-level coding), is to go back through current systems and rename massive amounts of things, now that there's no longer a pesky 8.3 or 10-12 char naming limit, etc.

So we are renaming everything in all network/web systems: projects, classes, forms, objects, methods, tables, views, fields, variables, files, folders, everything under the sun, basically, with nice, long, very descriptive "self-documenting" names everywhere. (Adding only a few comments when really needed.) Basically, "comments" are "out-of-fashion", they are the "old-way" of doing things, and self-documentation is the "new way."

Kind of a parallel to Help systems. A well-designed app shouldn't even need a Help system - except maybe a glossary of terms, or for function parms, stuff like that. But no more of these elaborate & confusing usually "no-Help" systems like MS Office (just one example) has been cranking out for years...

It's a royal PITA, almost like building a whole new system (but not nearly that bad). But I like the logic of this new naming approach, when I get legacy apps, if they looked like the vfp system I'm almost done with now, I'd probably have a heart attack to be able to tell what's going on just by looking at the uncomplied SW.

Sorry guys, I'm probably way off your topic here, just in a verbose mood tonight.