My recipe for OOAD with UML

How do you go from requirements to coding?
Everybody has different alternatives. Working on my SCEA assignment, I'm using OOAD with UML.
I choose to have an intermediate point: I'm not formally doing the OOA first (only in my head) and the OOD doesn't have much detail.
Ingredients:

• Enough Use cases
• A Busines domain model (small)
• Some Aditional requirements
• Pen and paper (could be relpaced with a whiteboard)
• A working brain (hard to find, I usually manage without it ;-) )
• Plenty of coffee
• A beer

Read the use cases and requirements, stir that in your head for a while Get a piece of paper and draw the "map of the world" (existing components, outside systems, etc) to give your brain something to think about.
Create a very basic class diagram based on the domain model
Select one of most the complex use case and create a sequence diagram for it:

• Put the actors involved
• Choose the interface/style required to interact with them (web, Thick client, Messaging, etc.)
• Use the identified objects from the class diagram to fulfill the requirements from the use case
• Each object will have their responsibilities in the use case context.
• You will need to add more objects and/or split existing ones to better distribute those responsibilities
• Drink a cup of coffee
• Write your assumptions

Once you fulfilled the requirements of the use case, let the sequence diagram cool for a while.
Dump all the classes you identified in the class diagram and mix them with the existing ones.
Think how you can better organize it (if smells like refactoring, you’re good, but don’t expect any “code smell” we’re far from the code). Once you’re satisfied with the result, go back to the sequence diagram and adjust it so it conforms to the new class structure. If your class diagram grows too big (maybe # of classes >7+-2) organize it in layers: put one layer of services classes, one layer of domain classes, one layer of application classes, etc.
Once the class diagram is ready, group those classes in components of the component diagram (you can add lollipop notation for the interfaces, is a nice touch)
Rinse and repeat for the other use cases.
When you’re done, you can serve the components inside deployment units in a big deployment diagram.
Now you can take a break and drink the beer!

DISCLAIMER: as with most recipes, the real process is completely different