The more effort you put into this stage of a project, the easier you, or a developer you hire, will find it to build the product.
All the things your product needs to be able to do. Many people collect requirements for their product by interviewing potential users. Often requirements are broken up into essential and desirable. In theory you can give a thorough requirements document to a developer and they should be able to create your product from it.
Your product is probably going to need to represent some real-world ‘things’ in its code. If you want users to log in then you’ll have a representation of a ‘user’ in your software and your database. A transport app will need to represent real-world trains, buses and journeys. In programming terms these are ‘classes’, and one of the first things a developer will do when they begin to design software is to think of all the classes involved and how they interact.
You don’t need to be too technical to come up with a list of classes, but think about all the ‘things’ that are represented in your product and what restrictions there are on them. A good way to get started is to look at all the nouns in your requirements list.
A use case is a single action that a user can perform with your product, or a single action that the product itself can perform (‘log in’ and ‘comment on photo’ are two examples from Facebook). Like classes these are useful for a developer to start putting together the architecture of your product.
Looking at the verbs in your requirements list is a good way to come up with an initial list of use cases.