Continuing The Project That Time Forgot, a UML case study in comic strip form... (Click pictures for larger images.)
There's the business, and then there's the role of the system within the business. If all you focus on is the role of the system, you can miss chances to see where the system's really needed.
So time permitting, I would rather start by understanding the whole business and then work inward. Oh, sometimes the division is very clear: if my client asks for a change to their payroll system, I probably don't need details about their waste management system.
Or do I? What if the waste management staff is made up of hourly employees? What if excess waste problems can result in overtime? What if that overtime gets charged to a different budget, such as the Environmental Quality Initiative?
The boundaries between "business" and "problem domain" can be fuzzy, and it's easy to cross the boundaries without realizing it. I find it's easier to start with a broad scope and narrow in than to start with a narrow scope and expand.
And if I had to pick the number one category of overlooked Actors in requirements analysis, it's the development and maintenance teams themselves. Customers think about what they need from your system; but how often do they think about what you need from the system? Do they think about running diagnostics to chase down problems? Do they think about maintenance and archiving of data? Do they think about staging and deploying patches and new releases? Do they think about detecting and tracking defects and problems and patterns of usage and percentage of down time? Do they think about support personnel and the tools they'll need to keep users running?
Maybe. Maybe, if they're a very experienced system buyer. But most often, the answer is no. If you don't think of the development and maintenance and support staffs as Actors, and you don't identify their Use Cases, no one will. Then you'll deploy, and the system will need maintenance, and your users will need support, and you'll have no tools to help them. And when you start trying to retrofit the tools after the fact, someone will say "You should've thought of that." And they're right. You should have. You're the professionals here.
So Owner has done a good job of identifying the "stars" of the story. These are Actors you will see again as the story plays out. (Trust me: if I didn't need them in the story, I wouldn't draw them. I'm just too busy to draw characters I don't need. (Somewhere Editor Bill and Curtis Gray are stunned into disbelief at that remark.)) But he has barely scratched the surface of the full Park staff. After much longer discussions, The UML Guy identified these basic classes of Actors:
This is a common pattern in many of my models:
- Users are anyone who might be involved with the system in any way. They may be anonymous visitors to the Park's Web site; or they may be more specific Actors, as described below.
- Authorized Users are Users who have permissions to do something on the system that Users can't do. This is represented in the diagram above as a set of Authorizations. Different Authorized Users will have different Authorizations. We'll get more specific about what that means when we get closer to code.
- An Employee is an Authorized User that works within the organization and has additional Authorizations as a result.
- A Supervisor is an Employee with a Staff of Employees, along with additional Authorizations and responsibilities.
- A Vendor is an Authorized User who isn't employed by the business, but who provides services to the organization and may have additional Authorizations and responsibilities.
In addition, this model has another class of Authorized Users: Guests. We want each Guest to have Web access to Park content, so that we can sell additional services and souvenirs to them. And then Priority Guests are Guests who pay for full Internet access.
After identifying these major classes of Actors, the team identified more specific versions of each. The Vendor Actors diagram is the simplest:
The Supervisor Actors are more numerous:
The Employee Actors are where the "Actor Explosion" comes in. This is just the first diagram; more detailed Employee diagrams follow:
Most (but not all) of these Employee classes have more detailed Employees below.
Here are the Ops Staff Actors:
And Ops Staff is complex enough to require two even more detailed diagrams. Here are the Transport Staff Actors:
And here are the Facilities Staff Actors:
Here are the Laboratory Staff Actors:
Here are the Lodge Staff Actors
Here are Concession Staff Actors:
Here are the Marketing Staff Actors:
And finally, here are the Medical Staff Actors:
Whew! That's a total of 86 different classes and subclasses of Actors! And I'll bet if I spoke to people in the transport, hospitality, marketing, or amusement industries, I'd find more. Owner's 8 Actors may be the most important, but they're less than 10% of the total set of Actors.
And I haven't even started looking at system and device actors. We'll likely end up with around 100 candidate Actors. Will we need all of them? Probably not. But I'm more comfortable now that we haven't overlooked anything.
And yet categorizing isn't enough! We really need to understand relations between them as well. For instance, Employees report to Supervisors. Here is a rough Org Chart for the Park staff, with an arrow from each Employee to the Supervisor to which she or he reports:
There's one more lesson in this Episode: although I see this work as identifying Actors, I went a little farther than that, identifying their goals and motivations as well. That's a step down the road to identifying Personas, as described by Alan Cooper in About Face and The Inmates Are Running the Asylum. In fact, since these are fictional characters, it's a lot like defining Personas. Cooper argues that by creating fictional Personas that represent users with personalities and motivations and goals, you create a filter to differentiate "okay software that someone can use" from "great software that will really satisfy this person's goals and make this person happy". I like a lot of what Cooper has to say in these books. I'm not 100% persuaded yet, but he's persuasive. Of course, I've also gone way overboard by his standards. He recommends typically around 3 Personas, 5 for a big project. I have 8, plus the review team, plus almost 80 more Actors. But I have them in part for the demands of the story, not the system. If Alan Cooper were doing Interaction Design for this project, he would likely focus on just one or two of these Actors, and flesh them out to a handful of Personas, and work on designing great software for them. Then he would focus on other Personas over time.