Here is not the most appropriate place to deal with this subject specifically, because the way it was put would become very broad, even though it is a very important subject.
You can use < strong> sites like UFCG .
If you create your use cases and have any questions about them, you can work out that specific question and post it here.
The issue of use cases is that you have to consider the actors, who are the users of the system.
The center of the system should be the users, so their use cases, whether in spreadsheet format or diagrams, should consider what actions each actor should take and that should be exhaustive that is, you should describe all use cases for all users or actors.
In fact, as an early part of the requirements elicitation process, use cases describe system functionality succinctly. In this way, each actor is linked to at least one action and one action to at least one actor, so that details that will be dealt with later in the requirements elicitation process are not present. It is a kind of general view of the system, so general, that for lack of detail is called this part of the software engineering process, black box .
This is literally a subject for more than one book. Requirements Engineering is where it all begins. Research by the needs is what will give rise to the first models of the software, so all the actions that each actor must and can perform in the system should be explicitly stated in the use cases in a simple way. (Example: Actor: RH Employee -> Holiday Recording - and all other actions that this employee can perform).