I define an actor as any external entity that interacts with a subject under consideration. For example, I mean a person, a company, a software component, or a hardware device. Furthermore, I include time-triggered processes as actors when needed. Consequently, I treat actors as sources or sinks of information for the system. Moreover, I place actors outside the system boundary. Therefore, I draw them outside when I create use case diagrams.
First, I identify who or what triggers a use case. Next, I decide which actors justify the existence of the use case. In particular, I label those actors as process-triggering actors. For example, when a user starts a login, that user acts as a process-triggering actor. Likewise, when a scheduler fires a timed task, the scheduler serves as a time-triggering actor. In addition, I remember that actors always interact with the system from the outside. Thus, I avoid placing actors inside the system rectangle.
I treat every actor as a stakeholder in requirements engineering. However, I also note that many stakeholders do not become actors. For instance, a sponsor may influence requirements but never operate the system. Therefore, I exclude such stakeholders from actor lists unless they interact with the system in operation. Consequently, I keep use case diagrams focused and clear. In other words, I include only those actors that trigger or meaningfully interact with use cases.
When I draw use case diagrams, I use a clear notation. For example, I draw the system boundary as a rectangle. I place use cases inside the rectangle, I position actors outside, and I connect an actor to a use case with an association line. Furthermore, I name use cases with a verb and an object. For instance, I write “monitor velocity” rather than a noun-only title. Additionally, I may add stereotypes like <>. However, I often hide the stereotype in simplified diagrams. Moreover, I use graphical symbols when they help. For example, I use a clock symbol for time-triggered processes. As a result, readers can recognize time actors at a glance.
I also use context diagrams to complement use case diagrams. Specifically, I create context diagrams to show all neighboring systems and interfaces. Thus, I capture people, IT systems, and devices that act as sources or sinks. Consequently, I may omit non-triggering participants from the simpler use case diagram. However, I keep the context diagram when I need precise interface definitions.
In testing, I adapt the term slightly. For testing, I sometimes treat the test object as the subject under consideration. Therefore, I list actors that interact with the test object. Meanwhile, I still place them outside the test boundary.
Finally, I apply this concept consistently. First, I identify external entities. Second, I decide whether they trigger or participate. Third, I draw boundaries and associations. As a result, I clarify scope, responsibilities, and required system functionality. Consequently, I improve requirements elicitation, modeling, and validation.