At my job we are to embark on the design and implementation of a software system that is part data warehouse and part data mining system.

For a project of that size and complexity, I'd strongly recommend that you write a throwaway prototype before you do any detailed, intense design work. By all means write an overview before your prototype... but keep in mind that you probably don't know enough about the problem to do a detailed requirements plan or interface specification until you've tried it at least once, in real code. (If you, or other people on your team, have written data warehouse/data mining systems before, all bets are off.)

I'm a big fan of learning by doing: write little throwaway prototypes for each feature as you go. They don't have to be complete, or easy to use, or fast... their purpose is to give you some idea of what a solution looks like, so that you can refine it for your finished product. If you keep the parts separate and the interfaces between them clean, you can refine incrementally as you go with minimal pain, and you'll probably end up keeping some prototype code, but "plan to throw one away; you will, anyhow".

It just so happens that Perl makes an excellent prototyping language.

--
F o x t r o t U n i f o r m
Found a typo in this node? /msg me
The hell with paco, vote for Erudil!