Umm let’s see... FDD known as functional design documents are "usually" and that is in our case prepared by the BA's. I work with Siebel and some SAP but not a whole lot, but they are both an every efficient ERP and CRM systems. Functional design documents do what they sound like, they take the businesses requirement and describes it as what they are suppose to do once placed in an application. A simple example could be if x consumer buys y product then he/she will be interested in b,c and d products also. Something like what amazon.com does at a very basic level; provide you with info on what other consumer who bought the same products you bought were interested in. Going into TDD's it specifies what needs to happen behind the application when x consumer buys y product and what needs to be triggered for the application to go and search for all the x consumers who bought product y and what else were these consumers interested in so the application can display the results saying "people who bought this also bought that". This is as far as I understand how FDD's and TDD's work at a very basic level, but every special industry has it's own requirements and this might differ. But coming back to an ERP or CRM systems, the so called "Drunken Sailor" days are over, which was when and IT Solutions firm could go up to a company and tell them what they needed, now it's as far as I can see vice-versa, it's the company that tells you ok this is what we want done and this is our budget. This is my experience.