The spec (ification) tells you exactly what the problem is, i.e. a very precise version of the requirement. It tells you what the code has to do, without saying how it does it. It sounds like your data mapping document covers the bulk of that. The main thing about the spec is that it has agreement from the customer/your boss. "If it ain't in the spec, it ain't a bug" - if something doesn't work the way they expect, you should be able to say either "That's what the spec asks for" or "it isn't in the spec, so the behaviour is undefined". Ideally it should cover error cases etc (see my post in the other thread) as well as the data mapping.

As far as design goes, your aims are:

• To minimise code rewrites when you decide on a better way/make a mistake
• To minimise code duplication
• To make the code maintainable

So in the main you should try and identify functionality that can be generalised and re-used by different functions. An example of that might be reading a db handle and performing transformations. There's no point in rewriting the while ($db->fetchrow_array) loop over and over again for every data source, so you'll probably want a general "read_datahandle" type of function. Data::Sync does this sort of task, and has general read & write methods, with the read method calling the appropriate transformation from a hash of coderefs keyed on the field name. Your requirement is probably more complex, but that's the general gist.

Note that "there's no point" means "really try not to" - if you find a bug, you want to fix it in one place only; if you find a better way, you want to fix it in one place only, and you'll get really bored cutting and pasting the same code over and over.