In the world of use case modeling, there is this concept of an actor. Actors are the things (human or otherwise) outside of your system that will interact with it in some way.
Actors are not real people – they are the roles that those people (or systems or things) play. They are an abstract concept, but during analysis, most of us prefer to spend our time thinking about concrete solutions – not about abstract concepts. So it’s easy to skip the effort that should've been spent exploring, identifying, and describing all of the actors in the system. Don’t do this.
To explain why, let me begin with a confession: I became interested in use cases because it was hard for me to absorb the traditional requirements specifications I had to read in order to do my job. I wasn’t sure if it was my short attention span or the fact that the software requirements specification (SRS) in front of me was as exciting to read as my mobile-phone contract. An SRS can drone on, page after page, numbered sub-item after sub-item, making assertion after assertion without ever talking about who is using the system or why they are using it.
We write down requirements to communicate – to spread information – about how we’re going to solve a problem. On its own, a traditional SRS is an awful way to spread information. It's dense with information – a list of unnaturally worded statements that doesn't easily show how they relate. No wonder I had a hard time absorbing these documents, and no wonder it’s difficult to spread information with them.
But do you know what kind of information does spread? Stories. Humans have been spreading information with stories since… well, for a very long time. And what is a use case but a story? It’s a story about how one user is going to accomplish one thing using our system. The story can be as formal or as informal as necessary.
An essential element of a story is a central character - a protagonist. Without a character, a story is just a set of disjointed facts - much like a traditional requirements specification. In a use case, the central character is the primary actor.
Characters make the story readable and actors make our requirements comprehensible. They indicate why a requirement exists (because the actor needs to get something done). They give us clues about what requirements we might have missed (are there stories we forgot to tell?)
And most importantly, actors are what separate the use case approach from traditional forms of requirements gathering.