Module::ScanDeps might help...

Super Search may well have lead you to the following threads, at least one of which would have answered your question:

• List all modules and versions used by a program
• Perl Module Dependencies
• Documenting Perl Scripts
• Source-Code Analysis?
• Module dependencies

Update: Bah, it actually runs the code.

I know this sounds like a lot of work, but I would strongly recommend a manual walk-through. Keep pen and paper or a simple text editor on the side and record what you learn.

Usually, out and and out dependencies are not the main issue in planning a refactoring. The dependencies are generally a by product of well factored code, not the starting point.

The thing to look for are:

• algorithms that are the same except for data or small variations in logic that can be replaced with well chosen boolean flags, op codes, or code references - these can be consolidated into a single function with some data parameters. Or if you don't like data parameters and you are comfortable with closures or functor classes, you may want to replace these closely related functions with functor objects or a function that generates closures.
• groups of interrelated functions that are conceptually similar. If you have two or more ways of implementing the functional cluster, you might want to consider refactoring your code into a class for each functional group. Then create a subclass for each separate implementation of that functional group.
• combinations of functional groups - once you start grouping your functions into conceptual groups, you may start noticing that some of your code takes implementation A from group 1, implementation B from group 2. Some other code takes implementation X from group 1 and Y from group 2. You might want to consider re-factoring this code into composition classes - e.g. a class whose constructor takes two parameters - an object that implements group 1 functionality and an object that implements group 2 functionality.