How are branching statements supposed to be written in UML use case descriptions? Here is the situation I am modelling -
An employee has to swipe a card through a card reader to clock into work. The system emits a sound signifying a read success or failure. If the read fails three times the user is given the option of entering their details manually into a PC.
Here is the use case description I have made, it seems very awkward and unclear with all the if/elses. Is this the way use case descriptions are supposed to be written or is there a better method?
The UML specification does not specify any way to show branching within a use case specification. However, modelers have come up with a few suggestions one of which is very similar to what you already have. In the book UML 2 and The Unified Process (page 82) one such approach is introduced:
"Use the keywords 'If' and 'Else' to indicate a branch within a flow. You can clearly indicate the body of an 'If' statement by careful use of indentation and numbering."
n. If condition
n.1 Do something
n.2 Do something else
...
n+1. Else
n+1.1 Do something
n+1.2 Do something else
...
n+2. ...
Note that you may want to drop the 'end if' phrases. The book also introduces other keywords such as 'For' and 'While'.
From my personal experience however; flows of complicated use cases will not be read by anyone when they are expressed in text. The best approach I have seen in the industry is to use activity diagrams to show main flow of use cases. This is to have a use case specification with all the other parts (preconditions, post-conditions, name, description, primary and secondary actors and ...) but leave the flow part empty and refer to an activity diagram as completely explained by @javier. I would however mix the two diagrams and separate the user and system steps by activity partition (swim-lanes).
Sequence diagram is definitely not an option.