Actually you need a full business and technical analyze of your software.
Your assumption is wrong: actually you only need a good enough business and technical analysis. That's how you can still be agile (with or without TDD).
At any rate, TDD works on a lower level than the full system. When working in TDD fashion, you are focusing on a single task / story, not the whole system. You need to have a good enough understanding of that single story to get you started. And of course, the story requires some context to make sense. But that some context is usually much less than what a full business and technical analyses encompasses.
Before starting to work on the product backlog, the Product Owner (if necessary) gives the team an overview of the system, the team members ask questions and discuss them to gain a good enough common understanding of the purpose of the system, its users, the way it is (going to be) used etc. Then they start breaking down stories into manageable backlog items and working on the product backlog. Again they discuss each backlog item / story to get a common understanding on what it means, how it fits into the big picture etc. Once the team members get a good enough understanding of an item to estimate its relative size, they estimate it, then move on to the next PB item.
When an item is selected into the next sprint, again the team discusses it in detail enough to understand what tasks need to be done in order to complete the item. This gives them a good enough understanding to start working on individual tasks in TDD fashion. If, during work, a team member finds an unclear spot or needs more information or clarification, s/he discusses the issue with the PO. This way, the team has the needed information, and only that, just when they need it, to define their test cases and interfaces, then implement them in TDD fashion.
