There is a very simple analysis technique in which you write down the use cases in plain text and extract nouns and verbs. The nouns are likely to be essential concepts in your domain (so probably classes), the verbs are likely actions to be taken in the domain (so probably methods). This rule is not written in stone but it can help you get going. When I took courses in Object-Oriënted analysis they started us off on this method but it is something that you learn to do 'by heart' without thinking too much about it with some practice.
Let's look at an example*
A customer can make a reservation for a book in a library. To do this, he must check the availability of the book in the library. If the book is available for the period the user wishes to lend it he can make a lending with the library to lend the book for a given period.
- Make (reservation)
- Check (availability)
- Make (lending)
This would lead me to a system where I have a Book class that belongs to a Library class. The Library class would also contain a list of Reservations and Lendings. On the Library there would be a method makeReservation that creates a Reservation for a Book during a Period. There would also be a makeLending that creates a Lending for a Book during a Period. Finally, a checkAvailability-method would be present that returns information on the availability of a Book during the Period.
The way you go about this is mostly a matter of personal preference. There are some guiding principles you could take into consideration while designing this (SOLID and the Law Of Demeter come to mind) so in that sense there are 'good' and 'less good' solutions. But if it makes more sense to you for the Book-class to have a Borrow-method that creates a Borrowing object on the book, there is nothing wrong with that.
Things like the Single Responsibility Principle (SRP, the S in SOLID) can help you look at the design you think will work and analyse it. For example, with my proposed design Library violates the SRP as it is responsible for creating reservations, creating lendings AND checking availabilities. By explaining the role of the Library class I can immediately see that I violate SRP and there might be a more optimal design.
Then again, if you were to apply all SOLID principles to the letter you wouldn't be able to write any code...
*Simplified for obvious reasons, in reality libraries would have multiple copies of some books etc...