How do you determine what the system should do?
Actors are unfortunately part of the problem, not part of the solution. Knowing that you have to build a system that will be usable by particular actors often makes your job harder rather than easier, since having to worry about the people that will use a system is just another problem on top of all the technical or managerial issues of making any sort of system work.
So, just knowing the actors doesn't help work out what a system should actually do. What you need to know is what the actors need to accomplish with the system, what are their intentions or goals, and what responsibilities are incumbent on the system to support them.
Similarly, lists of requirements (``wish lists'') produced by stakeholders or the marketing department are often very informal, imprecise, and irregular, mixing large and small, detailed and vague, important and irrelevant information all in one document.
Of course, stakeholders still want you to stop mucking about and deliver the system yesterday.
Therefore: List Candidate Use Cases for each Actor.
A use case is one complete case of system use. In other words, a use case describes a single sequence of interaction between an actor and a system. From the actor's point of view, the new system should seem to be a ``black box", which exhibits only behaviour, with no internal workings visible. A candidate case should be short and sweet, with just enough to be meaningful. Some examples are:
Any non-trivial system will have a lot of use cases, and it will take a while to nail down which ones actually apply to your system, so identify as many candidate use cases as quickly as possible. A candidate use case is just what it says -- something that may become a use case, but there's no commitment to it being so at this stage.
Actually finding or determining the use cases is not easy, and involves all the vagueness and uncertainty of analysis. To find use cases, you can use domain knowledge, textual analysis of wish lists or other documents, standards, other systems, and interview stakeholders and people working in the domain. Most importantly, you must look for potential users of the system, and try to understand them and their goals and intentions.