Alex continues with his series of posts on use cases and looking at the Colin Firth's and the Geoffrey Rush's of the use case world...
Previously we discussed the identification of actors that will interact with the system under development. The next activity to be performed in the development of a use case model is to categorise those actors. Actors are usually divided into what we refer to as primary and supporting actors.
A primary actor is a user who will use the system to achieve a goal. The needs of the primary actors drive the behaviour or functionality represented in the use case. If the primary actor roles or needs change, then it is likely that significant modification to the system will be required.
The primary actor is often, but not always, the actor who triggers the use case. Usually, the use case starts because the primary actor sends a message to the system, pushes a button or in some way triggers the story. There are two common situations in which the initiator is not the primary actor:
For an individual use case, any actor that is not primary will become what is known as a supporting actor.
Supporting actors provide a service in the use case and would not exist if there were no primary actors. Supporting actors typically participate in the use case to support creating value and achieving a goal for the benefit of the primary actors.
Supporting actors are used to identify external interfaces the system will use and the protocols that cross the interfaces. This feeds the other requirements, such as data formats and external interface descriptions.
Remember that an actor may be primary in one use case but supporting for another so it is not possible to universally classify the actor as its role may differ between use cases.
The identification of primary and supporting actors is a key step to discovering what our use cases will be as the use cases represent goals that the primary actors wish to use the system to achieve.
