Use Cases are like classes. They have inheritance (extends) and relationships like includes and uses.
Preconditions are common relationship constraints. Some of us write the preconditions and postconditions in the text of the use case. You can draw it, but it isn't required.
Do not try to sequence the use case bubbles. That's what activity diagrams and sequence diagrams are for. That's what narrative text is for. That's something the users already know.
Also, don't waste a lot of time treating the use cases as a super-high-level programming language. Remember, the actors already know what they're doing; they don't need help sequencing things.
You need to focus on capturing the actors, the use cases, and basic "extends", "uses", "includes" among the use cases. Use Case models are not programming. The use case diagram is knowledge capture of "who" and "what".
Think of it as more like a security model that defines what the actors can do. Order, sequence, and other details don't matter as much as what the actors do.
When you have Actor associated with actor (like Technician and Front Desk), you're saying that the actors interact outside the system. You're saying that the tech never logs in to the system to do get their work or log their time.
If the technician actually will log in to get work and record time, then the technician participates in some use cases.
Use cases aren't programming. They're things actors do. Use cases are connected by virtue of being built in a big, common piece of software. You don't need to draw data flow or logic arrows among the use cases. They can all be largely independent.
When you design the system, you'll implement UI features and database features that connect the use cases in some sequence.
