UML is great for clarifying requirements. It really helps to clarify your ideas and iron out inconsistencies what your users are asking for. The most effective way of doing that of course is to write the software, put it in front of your customer, and say "Is that what you meant?" Often the biggest problem is to get your various stakeholders to agree what they want. (Skills in diplomacy are required here, which not all developers major in.)

That's why it's best to arrange your project so that you deliver something visible at regular intervals, preferably starting with the aspects that are the least clear. At the heart of the agile approach is talking to your customers and getting regular feedback on what you're doing for them.

Often, though, even the most extreme programmer can take a while to come up with a spike that can show enough to your customers to flush out the most important potential misunderstandings.

Models help with that - you can spend an afternoon modeling and sketching and come up with a heap of interesting questions and answers. So I tend to think of models as the earliest spike. I like to do it at the start of each iteration, when we're discussing what we're going to do in the next iteration with the customer or business stakeholders.

Activity diagrams and state charts are often useful - they focus discussion on what people do, what happens next, what the different possibilities are at each juncture.

But I've always found class diagrams the most useful. They depict the fundamental concepts and relationships in the business - really, the vocabulary used to describe everything else. Most software development starts with getting a clear understanding of the domain - the world in which the program works - and it's in the customers' heads where you find it.

Take the example of a mobile phone company I was involved with in my previous life as a consultant. They were building some new applications to manage the process of installing new base stations, but the developers were having some difficulty getting the people in the operations and engineering divisions to agree the requirements. Right at the bottom of this disagreement, when we'd finally peeled back all the layers, was a difference in terminology. To about half the company, "base station" meant the radio mast and the box of kit wired up to it. To the other half, it meant a radio antenna and the transceiver that drives it. Now, you can have several of the latter in each of the former, and that's where the problem was. Once we'd drawn the following diagram, we could discuss different words to put in the boxes: