Where do you start use-case modelling?
Every analysis, design, or modelling exercise has to begin somewhere, however, it is often not obvious where you should start. Begin at the beginning is very fine advice if you are telling a story or reading a novel; but the ``beginning'' of a development project is not necessarily the best place to start modelling for that project. Typically, projects begin when one or more stakeholders agree upon the need for development, but the needs or dreams of the stakeholders may not be a good place to start. For example, they may specify particular, detailed solutions (``the booking system should run on those new WAP phone computers from Nokia'') rather than the real requirements (``theatre session times must be accessible over the internet'').
More seriously, although for political reasons the stakeholders may nominally agree on the importance of a particular project, they may strongly disagree on what the system should be for, what it will do, what is required for it to be a success, and so on. Stakeholders can also booby-trap a development project before it gets started by insisting that time-to-market requirements preclude any analysis, modelling, or design; or the system may need to interface to fickle legacy systems; or meet strict technological or resource challenges.
Therefore: Start with the people (and other systems) who will actually use the system.
One of the most important tasks in defining a system is to work out what the system is (and conversely, what it is not). We do this by considering the Actors of the system, that is the people (and other systems) that are outside the system we will build, but that interact directly with it.
First, by brainstorming, textual analysis, interviewing clients, and similar activities, come up with a list of the kinds of people who will use the system. Once you have the list, briefly determine the characteristics of each user. Most especially, you need to attempt to understand users' goals or intentions when using the system, and then characterise different kinds of actors in detail. For example, consider:
If legacy systems are important, you should also list the system actors, that is, the important systems to which you have to interface. You should then characterise the system actors, describing their characteristics, typically by referring to existing manuals or protocol definitions.
Finally, you should roughly prioritise the actors in terms of their importance to the system as whole.