The key to building a use case diagram that is based on a problem statement is to listen closely to the subject matter experts (SME) as they describe the problem domain to you. The SMEs cannot describe the problem domain without talking about the actors and use cases of the system.
Users appear as the subject in most sentences describing how the system is used. For example, the SMEs might say,
The agents update the customer address.
The agent uses the system to change information stored by the system. Hence, the agent becomes a potential
actor in your use case diagram. The actions described in the problem statement become potential
use cases.
In the example just used, “update address” becomes a candidate use case.
However, just because a SME says something does not mean it necessarily belongs in your use case diagram. Keep in mind that the context of
the system, the scope of the project, and the constraints on the project and system will provide you with the criteria from which you will build your use case diagram. Also remember that the scope of project initiation maintains an encapsulated view of the system.
This means that only the features of the system that must be visible from outside the system should appear on your use case diagram.
It often works well to have the SMEs develop the use case diagram with you. Use the drawing process as an opportunity to ask probing questions about the content, always applying the criteria described above to decide whether or not to include what the SMEs say.