I have heard conflicting things about this and just wanted to clarify.
I have always thought that when constructing a Use Case Diagram, I only include the activities that will be carried out by the system. For example, if it were a bank atm, "User depositing money" would be included, as it involved the user interacting with the atm. However, "User is paid cash in hand from job" is not included in the diagram, even though it may bear relevance to a scenario or situation.
Thanks all
The fact that the user is paid in cash is in any way related to the information system which is a system involving people. The payment transaction has to be integrated with your project, at least on a conceptual point of view. In other words it should have a relationship of an unspecified kind with a use case, depending on the context.
I recognize my answer is quite messy: if you're already getting bored, jump directly to the solution section...
The use cases diagram
According to The UML User Guide:
A use case is a description of sequences of actions that a system performs that yield observable results to a particular actor.
The point is about modeling what is related to the system: your main problem is to consider the scope of your project.
Depending on the scope you identify, the use case you should consider would be something like Cash withdrawal: consider the observable results from the point of view of the actor. This part is highly subjective whether you consider the operation part of the system or not. I personally disagree with the other answers here.
A few words about being paid cash in hand. On a pure development process point of view, would it be normal to have a sharp idea how a user is being paid while modeling ? Still the scope question here: perhaps is it a strong constraint in your context.
Even when reverse-engineering, a use case is user-oriented, it has nothing to do with how things are done, but what is done: I think nothing to do with especially automating things, even when talking about a system. There is a subtle idea here: I consider an information system, a system involving people in the first place, not a completely automated system. Of course, purely automated systems can be modeled with UML, but most systems involve users.
The relationship between the use case itself and the information how the payment is done has not to be represented on the diagram figure. However, even if this is not in the use cases spirit, the way it is done could be written in a note if it is an important constraint the diagram reader should be informed of.
The solution
In my point of view, the right place to put that information in the use cases is not the diagram figure itself but in a use case description. Martin Fowler gives a few hints about this in UML distilled. You have a simple use case description example here. This is related to the way you are using UML and the way you wish to describe use cases (I personally share Martin Fowler's perception).
Perhaps you would prefer to represent this with a formalism specific to your modeling software, but I think this would not be a traditional way of using UML (appropriate for an Executable UML, not appropriate with blueprint or sketch).
Most often use cases are used at the functional/logical level of your model (MDA's PIM level). This means that it only describes those parts of the process that will be automated.
So unless your system has a feature that somehow records the fact that the user is paid in cash, that isn't part of the system under construction.
At the business/conceptual (MDA's CIM level) level however you model the whole processes, regardless of automation. So at this level it "User is paid in cash from job" would certainly be at its place.
