Use Case To Actor Mapping

We know the importance of identifying the use cases that enable our business goals. We also know the value of understanding the actors that will use our products. This article shows how to demonstrate a simple but powerful view that maps the use cases to the actors.

Why Map Use Cases To Actors?

Most use case templates and requirements documents include a place to list the actors for each use case. Very few encourage us to provide a big-picture view. Even users of requirements-management systems are left without an easy way to show this perspective. Can it really be valuable, if it is so often overlooked?

A critical element of defining and managing requirements is assuring completeness of your requirements. The first step to assuring completeness of your requirements is to acknowledge that the requirements represent a structure of decomposition of a problem.

Once you’ve identified the goals of the business (or the problems faced by customers within your market, when taking a multi-customer view), you need to recognize that those goals are achieved by enabling use cases. Each of those use cases is then enabled through the implementation of functional requirements.

Part of defining use cases is defining the actors (a.k.a. users) that perform those use cases. You can (and should) use an actor hierarchy to describe the users. If you fail to define the actors effectively, you risk creating the elastic user anti-pattern. This anti-pattern is what happens when you lose sight of the differences between different user groups. You run the risk of designing a solution that fails to meet the needs of any one group of users, by homogenizing them into a lowest common denominator user. Or worse, cutting user-experience corners, and designing “whatever is easiest” and justifying those decisions by rationalizing a schizophrenic actor who changes characteristics to suit your designs.

Most people defining requirements (product managers and business analysts) will do a good job of defining use cases, and identifying the actors that use them. And most tools and books provide good guidance on how to define an actor, or how to define the actors for a single use case. But so few can give you that big picture.

Requirements Iterative Development

If you have worked the entire lifecycle of a requirements process from problem to solution, you have experienced iterative requirements development. Most requirements processes work top-down (some prototype-driven processes are more “bottom up”). Define the goals. Then define the use cases needed to achieve those goals. Then define the functional requirements…

Hold on.

Don’t let that “agile requirements” vs “waterfall requirements” debate sneak in here. That’s a matter of formality and scale. What we’re talking about, specifically, is iterative development that happens as a result of insight, independent of (or in spite of) the process used. This applies to any process for defining requirements.

You define a set of goals. You may or may not validate that set of goals. You think you are done. You start defining the use cases and mapping them back to the goals. You discover two things. First, some goals are not mapped to any use cases, and second, some use cases are not mapped to any goals. You resolve this. You add and remove goals, and you add and remove use cases. The act of defining the use cases enlightens you about the goals they are intended to support. You are iterating on your goals. Unfortunately, a lot of project managers don’t understand this, and build a schedule around a milestone such as “business requirements approval”. Then when you apply your insights into a revision (iteration) of your goals, during the “use case development phase” the schedule is blown.

You do your change requests, reset expectations, and manage the political fallout of a schedule change. Then after “use case approval”, you move into requirements definition. As you document requirements, you uncover new use cases, or rewrite use cases, or otherwise benefit from the insights you have. And those changes to use cases propagate back up into changes in requirements. Now you’ve really messed up the schedule. The way some people fixate on schedules, you’d think they would rather stick their fingers in their ears and keep the schedule than benefit from improvements now, when they cost 100 times less to fix. Oops. Guess I went on a rant, there.

This is also commonly called “requirements churn” and can be tracked – either in a good way or a bad one. The bad way to track this creates an environment that discourages change (“you better keep the schedule!”). The good way to track this creates an environment of “get it (more) right the first time.”

One way to get it “more right” the first time with your goal definition is to look at the big picture with your use cases. One piece of that is mapping (or tracing) the use cases back to the goals. Another tool is to create a mapping between your use cases and your actors.

Use Case To Actor Mapping

Create a simple grid in a spreadsheet. Each row is a use case, and each column is an actor. In each cell, when the actor is the primary actor for a use case, add the letter “P”.

Primary Actor

The primary actor is the person who is the subject of the use case, performing the verb of the use case on the object. A use case may have multiple actors but has one most important person. The term actor represents the person who takes action – not someone playing a role. Other actors may be involved, either as participants, or as infrequent or secondary performers of the use case.
Some examples:

• Primary Actor: Pilot. Secondary Actors:Flight Crew, Sr. Maintenance Technician
• Primary Actor: Author.
• Primary Actor: Financial Accountant. Secondary Actor: Financial Accounting Manager

Foundation Series: How To Read A Formal Use Case

A simple grid with a handful of use cases and actors would look like the following:

The interesting analysis this allows you to do (and it is more powerful with a larger body of use cases and actors) is to review the big picture. You would ask yourself “who does each use case?” even without this tool. That’s just part of writing the use case. Now you can also ask “what use cases does each actor perform?” And you can easily see to ask questions like “If A03 does that, why can’t A02 do it?”

This big picture analysis, in my experience, will also accelerate the discovery of missing use cases. You should also capture when an actor is a secondary actor in the use case. You will then have a grid that looks like the following:

When asking the comparative questions about UC03, you uncovered another use case.

This tool accelerates those insights, allowing you to make changes “further upstream”, or if your glass is half-empty, correct fewer mistakes later.

Conclusion

Use the use case to actor map to provide a big picture view of how people will interact with your product. This view will improve your understanding of how people use the product, simplify the analysis, and encourage insights earlier in the requirements process.