Actor Hierarchies give us an overview of the people who will interact with the system. We can extend this model to provide a visual indication of how use cases are distributed through the organization. Further, we can leverage a hierarchy to show how use cases are rolled out to the users – a targeted communication for our stakeholders.
Actor Hierarchy
A hierarchy is a model for representing the classification of things. The example we probably all learned first is the hierarchy of phylums, used to classify animals (dogs are a kind of canine, which is a kind of mammal, which is a kind of animal).
The hierarchy is a presentation of classification. Imagine that we were developing a GPS system for after-market addition to cars. As part of determining the requirements for our product we would want to identify the users of our product. In use cases, these users are the actors. We might identify casual drivers, taxi drivers, and couriers as the potential users of our product. What we need to do is organize these users in a logical way. We can use a hierarchy to do this.
All of the actors in the above diagram are “Car Drivers.” Some are casual drivers, and others are professional drivers. There are also taxi drivers and couriers, both of whom are types of professional driver.
If we’re using interaction design, we can build a similar hierarchy for our personas.
Mapping Use Cases To Users
We can create a simple table that shows how our targeted use cases map to our users. We can present the information in our table so that the hierarchy is evident. The pretty pictures above are cool and all, but harder to put in a table
The top of the hierarchy is Actors, branching into sales and accounting as two types of actors. With sales, we have a salesperson and a regional manager. Each column represents an actor, and the groupings of columns give us the hierarchy.
Each row represents a use case. We could put “X”s in each cell to represent which user can do each activity. We get more value from our document by populating each cell with the release-information for each use case (see the cited article on scheduling releases for details).
Evolving Use Cases
Yesterday we presented the concept of evolving use cases. We can use this approach to make communication of this evolution even more effective.
Imagine that we were evolving the Review Regional Orders use case to have an initial version in the Q2 release, and a second version in the Q3 release. In the first (Q2) release (of the functionality that enables the use case), we have all of the features needed by the regional manager. In the second (Q3) release, we add the functionality needed for corporate accounting to use the use case. The diagram above sort-of implies this – but it could be much more effective.
Our chart would look like the following:
The highlighted region shows that we are going to manage two different versions of the Review Regional Orders use case. Version 1 is released in Q2, and version 2 is released in Q3.
Summary
Actor hierarchies allow us to organize our use cases and understand how our users interact with the product. We can combine this documentation model with the concept of evolving use cases to provide powerful communication.
In diagramming your actor heirarchy, something got lost. The casual driver is a buyer in a consumer market, as in B2C. The professional driver is a buyer in a vertical, or possibly horizontal business market, as in B2B.
In the B2B situation there would be a proliferation of stakeholders. The professional drivers are also members of a domain-specific functional culture. This culture provides meaning similar to an ideology in its exclusiveness. That meaning is typically lost in the averaging of the requirements elicitation (RE), because RE is carried out from the perspective of the technologist, not the subculture participants. The way we are trained to do RE contributes to the problem. Mathematics and economics are inherently insensitive to culture.
The professional driver deals with a logistics network that the casual driver has no awareness of. In that logistics network are “functionality opportunities.” Likewise, the management of professional drivers.