Start by thinking of the users that will really use the system—the subset of the users for whom the system provides value. Ignore for the moment those users who simply service the system. The real users are the ones without whom the system itself would be pointless and unnecessary. These should have already been identified as part of the system’s vision.

How should you represent the actors in a use-case model? We have already discussed the definition of user types as a fundamental part of establishing the vision for the system. We now need to start to define the relationship between these user types and the system to be built. The first step is to define the roles that these users will adopt with respect to the system—these system-related roles are modeled as actors. For each of the user types identified, ensure that there is at least one actor defined to address their needs of the system. The actors that represent the roles adopted by the key users are the primary actors. They are the first actors to be identified and agreed upon when you are finding the actors for a system.

Initially, it may seem that a trivial, one-to-one mapping between the user types and the system’s actors is all that is required, but as we shall see, the relationship is generally more complex than this. Take, for example, the simple telephone system where we had the user types and actors defined as shown in Table 4-1. Remember use types are defined by their competencies and capabilities, whereas actors are defined by their goals and relationship with the system.

Most of us do better at finding the specific and have more trouble with the general. Some of the longest brainstorming sessions in which we have partici-pated have dragged on because the participants were trying to be so general that they could cover every possible case with the fewest number of actors. (In fact, one group got so general that it defined only one actor—the Performer.) There is a time for abstraction, but not usually while brainstorming. Working from the specific to the general is always easier. When you identify a few people who play the same actor role, the actor is nearly always obvious; working the other way around is almost always harder.

Once you have identified an actor, it must be named. A good starting point for this is to identify the role the user plays while interacting with the system. Don’t get preoccupied with finding perfect actor names, especially early in the process; find an acceptable working name and refine it later if or when you need to. (In fact, there is no such thing as “perfect” in use-case mod-eling—remember that “good enough” is often more than sufficient to accomplish your objectives. Knowing when to “quit” is often a big part of success.)

If you have trouble dealing with all of these different levels of abstraction involving user types and actors, then start by being even more specific and think of some of the actual individuals who will use the system. Then think of how you can categorize them as both user types and actors. It is often a good habit to keep a few individuals (two or three) in mind and make sure that the actors you identify cover their needs.

The primary actors are the ones for whom the system is built; they are the ones to whom the system provides sufficient economic value to warrant its construction. It is both necessary and correct that we should concentrate our efforts primarily on these actors and the users that will take on these roles. There are typically, however, other sets of actors essential to the successful operation of the system that are often forgotten. These are the actors that support the use cases provided by the system and those that support the system itself.

Nearly every use case requires information to be provided, or decisions to be made, by actors other than the one that started the use case. As the scope of a use case starts to emerge, other supporting actors will often be required for the system to be able to achieve its goal and deliver the value to the actor that initiated it. For example, additional information may be required that the system does not have. This can lead to the identification of additional actors as the source of this information. In other cases, a decision may be required that cannot be made by the system and the initiating actor alone. For example, in a banking system loans of over a specified amount may need to be approved by a senior member of staff as well as by the system.

Nearly every system requires some actor to start the system and to shut it down, and many systems require some sort of routine maintenance (ensuring that the system’s data is backed up, for example). If the system must provide special behavior to support these actors, their use cases must be identified. Conversely, if standard utilities are used to back up the system, for example, there is no need to specify the actor or the use case unless these utilities are used in unique ways or are extended in some way. When you are identifying actors, make sure that the requirements related to supporting the system and its use cases are represented in some way by the actors.

Don’t isolate the use-case modeling activities from the other requirements-related project activities; it is very rare that use-case modeling starts from a completely blank page. As discussed in Chapter 3, we would expect there to be some sort of Vision document in place containing information about the stakeholders, users, their key needs, the features required of the system, and the constraints placed upon the project. This is all useful information to consider when finding the actors and use cases of a system.

When finding actors the following relationships should be considered:

You should also consider the impact of the defined features and constraints by revisiting the features and considering who is interested in a certain requirement or area of functionality. By asking yourself, “Who is interested in this capability,” you may find additional actors and possibly stakeholders. Constraints may also give clues to the existence of yet-unidentified actors by defining things outside the system with which the system must interact. For example, there may be a constraint that mandates that the new system will integrate with an existing system to obtain all of its customer-related information.

Some people see the iconic, stick-figure representation of the actor and assume that the actor must be a person. They assume that use cases are a technique for describing human–machine interactions, and in doing so they miss one of the main benefits of using use cases. In fact, they may be missing the most important purpose of use cases.

An actor represents anything that is outside the system that exchanges information with the system. This certainly includes people, and for many systems, people are the most important external users of the system. But for many other systems—including command and control systems, switching systems, and sensor-monitoring systems—the actors are primarily other systems, devices, or sensors.

Although this example may seem oversimplified, use cases evolved in an environment in which there was a great deal of internal processing and interaction with other systems and not a great deal of “human” interaction relative to the total amount of processing that occured—in telecommunication switching systems. It is a credit to the power and simplicity of the approach that use cases also work very well for systems that have a great deal of human interaction. In both cases, the systems must respond in very specific ways when certain events occur. In the case of highly technical systems in which there is not a great deal of user interaction, the technical complexity of these systems often obscures the real purpose for which the system is being built. Use cases help to solve this problem by focusing on what the system does in response to external events in order to provide the desired results.

As a result, use cases tend to be even more important for systems that have no significant user interface—they are often the only way that the stakeholders of the system can understand what the system does. When a system has a well-defined user interface and easily identified users, it is often easy to get good feedback on whether the system does what its users expect. With technical systems that exist deep within telecommunication networks or are embedded in devices, however, the “user” is often another system. Visualizing what happens in these systems is much more difficult, and use cases can play an important role in helping to define the desired and expected behavior under various circumstances.

Use cases are not just a user-centered design technique ^[1]; they are also essential for systems that effectively have no user. Don’t let the actor icon fool you ^[2]—actors aren’t just people.

Considering actors that are other systems forces you to confront the boundary of the system you are creating. What does your system do, and where does it end? If you consider only the human actors, you often end up with a system that includes other systems—and this really makes it difficult to figure out what your system is supposed to do. Representing other systems as actors helps to define what your system will and will not do—the boundary of the system. If you rely on some other system to do something, that other system is an actor to your system; if another system requests information from your system, it is also an actor to your system. Treating everything outside your system as an actor simplifies your problem—you need only focus on what your system must do for its actors.

To illustrate the effect of not being able to establish the system boundary on the scope of the system, consider once again the ATM. Nearly everyone identifies the bank customer as an actor, and many people identify an operator who services the ATM as an actor, but not everyone recognizes the banking network or some central bank system as an actor. This oversight leads to ambiguity about what the ATM does and what it does not do—is the ATM responsible for determining whether the customer has sufficient funds on hand, or is the banking network? If you cannot rapidly decide on the system boundary, you may eventually find that you are not focusing on what is necessary.

Sometimes it is difficult to tell if another system is really an actor or just part of the system’s assembly. Often, we are faced with systems that could either be treated as actors or as devices. The choice of representation depends on a couple of factors. If the system is required to communicate with some other system, and the communication is something that affects the flow of events, then the system is an actor. If communication with the other system is simply a means by which the designer provides the required functionality, and the designer can choose how, when, or if the other system is used, then the other system is not an actor and should be omitted from the use-case model.

This last example illustrates why we don’t consider the operating system, database, or other utilities as actors. Although we certainly make use of their capabilities, we are not required by the system to use them in specific ways at specific times. Things that are the designer’s choice should not be represented in the use cases. Stated another way, anything that must be done a certain way should be documented in the use cases; anything that’s purely up to the designers and developers should be left out. Put yet another way, constraints on the solution (such as “the system shall run on the XXX operating system”) should be recorded, but not in the use cases. The best way to handle constraints is to identify them, record them, and trace them to use cases that must satisfy the constraints. This allows us to make sure that nothing is forgotten while ensuring that the constraints do not get in the way of understanding the real behavior of the use case. One way to address this problem is to ask yourself: “Do I have control over the behavior of the other system?” If not, it is typically because the other system is developed and managed by another group and is wholly separate from your system. A rule of thumb for actors: “If you can’t control it, it’s an actor.”

Whatever decisions are made about the appropriate set of actors for the system, the use-case modelers must never preempt the designers and try to use the use-case model to design the system.

Devices are typically mechanisms that actors use to communicate with the system, but they are not actors themselves. We are writing this book on a computer, but the keyboard is not the user of the word processing program—we are. If we were to say that the actor for the word processing system is the keyboard, we would lose track of the real goal of the system: to help us to write a book. There is more to this than simply entering keystrokes.

Sometimes it’s harder to see this. In a fire detection system, what do we call the actor that first notifies the system that there is a fire? Because the system uses devices called sensors to report unusual increases in temperature, you might consider the sensor to be an actor. In fact, the fire is the actor, but we tend not to think of a fire as an animate thing. Even in an automated system, however, events can be reported manually—someone can ring the fire alarm. In this case, it’s very easy to see that the fire alarm switch is not the actor; the actor is the person who pulls the switch. This points us to a more satisfactory solution: From the standpoint of the system, an automated sensor that signals a fire and a manual switch that signals a fire are identical, and both would trigger the same response by the system. We could use the same actor for both cases—an actor called Fire Detector—and (ideally) the same use case for both ways of reporting a fire. If the use cases (in other words, the requirements) are different for manual versus automated reporting, we could simply modify the names slightly, introducing the actors Manual Fire Detector and Automated Fire Detector.

Other devices, such as disk drives, tape drives, or communication equip-ment (including printers), have no place in the use-case model. Although they are important to the design of the system, introducing them as actors obscures the real purpose of the system. The purpose of devices is to support some required behavior of the system, and the requirement to use a particular device may impose certain constraints on the implementation of the system, but devices do not define the requirements of the system. The system may even be required to run on a particular device, such as a handheld computer, but this requirement does not define what the system must do for its actors. The focus must remain on system definition.

The printer-as-actor issue deserves a little more discussion. Often, systems must produce a printed report of information that it contains. Teams often want to show the printer as an actor that then forwards the report to the real actor. This isn’t needed and it gets in the way. Just as the computer display or keyboard is not an actor, the printer is not an actor, either; it is just a mechanism for conveying information. The use case describes the compilation of the information and makes note that the report is printed, but for the purpose of the use case, we need to focus on what the system does to collect and format the information, not on how it is delivered. Besides, most systems allow information to be reviewed on a screen and then printed if the user wants a hard copy, so printing is really just an option in the use-case description.

This raises an important point—use cases are not an all-encompassing requirements technique, and you cannot represent all the requirements of a system with use cases. Use-case descriptions are a great way to approach the difficult task of describing the behavior of a system. Remember: Use cases are stories about how someone or something uses the system to accomplish something useful. Don’t feel that you need to somehow account for all requirements in the use cases, and don’t turn use cases into a design technique.

Sometimes the use cases for the system are obvious, but the actors involved are difficult to identify. This issue is often encountered when the system has so-called “batch” processing that runs unattended, typically overnight (if such a thing exists anymore in the round-the-clock world of some systems). The initial approach most teams take is to identify an actor called the System Clock to start the job. This is an awful lot like a device, and sometimes causes problems; at the very least it doesn’t seem like the other actors in the system.

The way out of this dilemma is to consider that someone manages when these jobs should be started and stopped and that the system may support other use cases to allow this person to manage these jobs. For this reason, an actor with a name like Job Scheduler is a better choice. The specific mechanisms used to start and stop jobs in the system will vary, perhaps using the system clock or some other mechanism, but clearly something causes these jobs to start. The use of Job Scheduler may also remind us that we need a way to say when these jobs start, and we need a log of job status so that we can know that they were completed successfully. ^[3]

Compare this case with the fire detector in our earlier example. It was easy to comprehend that the fire detector was an actor, so what is so special about time? The answer is “nothing.” Both the fire detector and the job sched-uler monitor external things, and when some particular event occurs, they cause something to happen inside the system. Sometimes it is more understandable to others to have actors with names that represent significant time events. For example, the system that controls the tidal barrier in London (a very large flood-defense system) may have to respond to high and low tide times. It may therefore be appropriate to use High Tide and Low Tide as the actors rather than the more abstract label Job Scheduler.

Teams often get distracted by the esoteric, focusing on the novel and unusual rather than the basic functionality of the system. In the example of the fire detection system, the greatest amount of discussion typically focuses on the sensors, whereas the recipients of the information that there is a fire (the fire department, the people in the building, and systems that control fire suppres-sion devices) are given short shrift.

In this case, the better strategy is to focus first on finding the human actors and then to look for the more obvious system actors. The esoteric cases are important, but not to the exclusion of the bulk of the behavior of the system. Consider the esoteric only after you have established a firm understanding of what the system will do. In the case of the fire detection system, recognizing that there is something that will report a fire (it could be a person activating an alarm) and calling this actor the Fire Detector is sufficient for the use-case model; the actual mechanisms that are used to detect or report a fire can be handled much later.

Although many textbooks and guidelines (including this one) present the finding of actors as separate from the finding of use cases, in reality the two activities go hand in hand and are usually undertaken simultaneously and iteratively. Once an initial set of use cases has been identified to support the primary actors, many other actors will be identified that are required to support the use cases. These additional actors are required to support the use case by:

It is very difficult to find these actors at the outset of the modeling activities before the use cases themselves have been identified and outlined. Instead, the use-case model will evolve and become more detailed as more and more of the actors and use cases they require are outlined and explored. Typically, the modeling will start by identifying the primary actors and the use cases required to support their goals and needs. These use cases are then looked at in more detail, leading to the identification of more actors that are required to support these use cases. This, in turn, leads to considering whether these supporting actors themselves require more use cases to satisfy their needs and so on.

Do not expect to find all of the actors for a system on the first pass, especially if this pass is not considering the detail of all of the use cases required to support these actors.

The first thing you have to do when you find actors is to name them. When you name an actor, make sure that the name describes the role that the actor plays in relation to the system. Consider the other actors in the system and ensure that there is sufficient distinction between the actors to justify the creation of the new actor. If you are having difficulty reaching agreement on the name, list the alternative proposals and assess them for similarity. Also list the responsibilities of the actor with respect to the system. Sometimes a good name emerges naturally from the actor’s responsibilities.

Good actor names are descriptive of their responsibilities. They describe the role the actor plays in relation to the system. An example of a good actor name would be ATM Operator for the person that keeps the ATM stocked with cash and paper, keeping the ATM in good working order. A poor actor name for this person would be Repair Person, because the actor’s role goes quite a bit beyond simply repairing the machine.

A trap to avoid, however, is to simply restate the name of the use case in the form of an actor name. As an example, if we have a use case Withdraw Cash it would seem silly to have an actor Cash Withdrawer (instead of Bank Customer), but it is not uncommon to see such examples as an actor named Order Shipper that interacts with a use case called Ship Orders. In this example, the actor name is not simply a reflection of the name of the use case. The actor name is probably adequate (see the next section for an explanation), but the use case name is probably wrong—orders result from a customer buying something, and it’s that end-to-end experience that provides the real value. A better solution would be to have a use case called Order Goods that is started by a Customer and communicates to the order shipper to deliver the goods to the customer.

Make a special effort to ensure that the actor name does not resemble some job title in the organization; if there is a similarity, change the name to make it clear that the actor is a role adopted with respect to the system and not a job title. Job titles are much more likely to be reflected in the set of user types than in the set of actors. Often, it is hard to find actor names that don’t sound like job titles. If you are developing a system to manage the delivery of packages, you might naturally identify an actor you call Shipping Clerk. The only problem with this is that there is probably a person in the organization that has that job title. And so starts a good deal of confusion and misery.

In the use-case model, actors are really roles that a person (or system) plays when using the system. So the person with the job title Shipping Clerk also plays the role described by the actor Shipping Clerk. This is confusing, to be sure—no matter how hard we try, it’s almost impossible to keep from equating the actor with the job title. The best thing to do, if possible, is to avoid the problem entirely: Use a different name for the actor.

In our package delivery system, we could sidestep the problem by choosing a slightly different, more role-based name for the actor, such as Package Shipper. The different name emphasizes how the actor uses the system versus the responsibilities of the person playing the actor role. In this case, Package Shipper is actually a better name for an actor. When we look at the role carefully, we find that many different people may ship packages, not just a shipping clerk. Package Shipper is a more general name anyway, and it avoids the confusion of job title with actor name.

Sometimes it’s not so easy to differentiate between the role and the job title. Consider a use case used by a Project Manager to plan a project. It’s not easy to think of another name for the actor other than Project Manager. We could try Project Planner, and this may be acceptable to the readers of the use case. But most people are conditioned to think of the project manager as the one who plans the project, so the natural tendency is to drift back toward an actor name that is the same as the job title of the person who plays the actor role. The real problem is that job titles have evolved out of the roles that people play. We can only come up with a finite number of names for these roles, so often actor names will sound very much like job titles. That’s to be expected, but just remember that they are two different things, and similar names cause confusion. Strive to be clear about the differences and anticipate the potential confusion.

Example

In one company, which sold software development tools, there were sales teams that addressed certain vertical sectors. Each sector had a Sales Administrator. In reality, the Sales Administrator had multiple responsibilities, including maintaining team diaries, processing orders, handling customer queries, allocating temporary licenses, processing expenses, and so on.

Imagine if we were developing a system to support the day-to-day working of the team. We might come up with a partial use-case model like the one shown in Figure 4-2.

Figure 4-2. Using job titles in the use-case model

Using actors to represent job titles, or user types, rather than roles can cause problems for the long-term usage and stability of the use-case model as it ties the actors to the current organizational structure. Organizations, and the positions within them, change over time, but the underlying roles and responsibilities that people take on within the organization are often relatively stable. By using the actors to model the roles rather than the job titles, we end up with a system that is far more resilient over time.

A more role-based model is depicted in Figure 4-3. This figure more adequately expresses the underlying roles that the Sales Administrator is adopting when using the system and is far less brittle and inflexible. If the responsibilities of the Sales Administrator change within the business, the use-case model of the supporting system will still be correct.

Figure 4-3. Using roles instead of job titles as actor names

A problem related to the actor-name-as-job-title problem just described is overgeneralization of both actors and use cases. More than one team has followed this path to its illogical end, and it led them to having a single actor for the whole system: the “Performer” (or “User”). This actor was arrived at by taking to an extreme the admonition to use general role names and not specific job titles. The reasoning was that anyone using the system was “performing” some task and depending on the task’s result. Taking generalization to an extreme obscures the roles that people play when they use the system. In the case of the system with the single “Performer” actor, the teams had lost sight of a critical fact: Different people use the system for different purposes. Even the same people will play different roles as they use the system to accomplish different things.

When you feel that an actor may be too general, ask yourself whether the actor name describes a distinct role that people play when they use the system. When you name the actor, make sure that the actor is not simply a reflection of the use case (for example, deriving the actor Inventory Manager from the use case Manage Inventory). Although there is syntactically nothing wrong with naming actors this way, it will certainly reduce the communication capabilities of the model itself. It can also lead to lost opportunities for the simpli-fication of the use-case model that, typically, only become clear when you consider the full set of responsibilities allocated to each actor.

When defining the actors, don’t worry about relationships between actors (such as generalization); simply capture the people or things that will use the system. Overgeneralization of use cases is a different matter and is discussed in Chapter 10, Here There Be Dragons.

Be sure to write a short description for each actor. When the time comes to determine what the actor needs from the system, a few sentences that capture the actor’s role and responsibilities will help simplify discussions. The brief description should consist of no more than a few sentences that describe the role the actor plays with respect to the system. This last part is important—if the brief description starts sounding like a job description, you’re headed in the wrong direction. The brief description should capture the responsibilities that the actor has with respect to the system, and it should state the goals the actor expects to achieve by using the system.

The characteristics of an actor might influence how the system is developed, and in particular how an optimally usable user interface is visually shaped. The actor characteristics include

In most cases, a rough estimate of the number of users and frequency of use will suffice. A difference between 30 and 40 will not affect how the system is shaped, but a difference between 3 and 30 might.

Other actor characteristics can be derived directly from the user types by considering the following issues:

It is important to record the relationship between the actors and the user types, stakeholders, and stakeholder roles identified in the Vision document. Tracing the actors to the user types will help to capture and identify the actor’s characteristics. Tracing the actors to the stakeholders and stakeholder roles will enable the correct members of the stakeholder community to be consulted during the production, evolution, and validation of the use-case model. This traceability also provides a measure of the completeness of the model itself. If there are user types that are not traced to at least one actor, then either they are not users of the system or there are still more actors to be identified. If there are actors that do not trace to at least one user type, then either these actors are superfluous or there are still more user types to be identified.

For each actor identified, try to list the things that the actor needs to achieve by using the system. Sometimes you will need to combine these “proto use cases” because they are really different aspects of the same thing or slight alternatives or variations on some other use case. See Figure 4-4.

Figure 4-4. Identifying what actors need from the system

The actor is key to finding the correct use case, especially because the actor helps you avoid use cases that are too large. In the case of the ATM, focusing on several actors—the Bank Customer, the ATM Operator, and the Bank System—allows us to split the behavior of the system into a number of smaller subsets, making the system easier to understand and less complex. Each of these actors has individual demands on the system and therefore requires a separate set of use cases.

A use case should describe a task that has an identifiable value for the actor. This is very important in determining the correct level or granularity for a use case. “Correct level” refers to achieving use cases that are not too small; a use case that is too small does not, by itself, produce value for at least one of its actors. As an example, consider again the ATM, and ask yourself whether “Authenticate Bank Customer” (or “Verify PIN”) produces value for the Bank Customer; ask yourself whether you would be satisfied if the ATM allowed you to put in your banking card and enter a personal identification number (PIN), only to be told that you had entered the correct PIN. Such a use case clearly has no value on its own—it only adds value as a verification mechanism in some larger context. That larger context is a “real” use case of the system.

As well as looking at the things that the actors wish to achieve, it is also worth considering the information that they and the system will need access to in order to perform their tasks.

Think about the information the actor will need to obtain from the system. This can help to identify additional use cases focused on the provision and capture of this information. You will also need to consider whether there are any occurrences within the system that the actors will need to be informed about and how the system will know who is to be informed. This can lead to the identification of registration- and notification-style use cases.

From the system’s point of view, think about where the information it will need to carry out the use cases will come from. Is this information to be stored within the system or will an actor supply it? Regardless of where or how the information is stored, there will have to be use cases responsible for its entry into and retrieval from the system. You will also need to consider if there are any external events or changes that the system will need to be informed about. Again, there will have to be use cases to allow the actors to notify the system of external events.

Some use cases will appear to have common parts; this is to be expected. At this point, it is premature to worry about the structure of the model, because you haven’t yet discovered the entire content of the use cases. Wait until after the flow of events has been outlined before you bring up any discussions about use-case relationships. The techniques available for managing commonality between use cases are covered in Chapter 10, Here There Be Dragons.

The unfortunate visual similarity between use-case diagrams and dataflow diagrams sometimes leads people to define use cases that are really just functions or menu items. Whatever the reason, it’s probably the single largest mistake that people new to use-case modeling make. See Figure 4-5.

Figure 4-5. Incorrect use of use cases as menu options or functions

What’s wrong with Figure 4-5? Think back to our definition of a use-case description (“a story about some way of using the system to do something useful”). Are all of these “use cases” independently useful?

The answer, of course, is no. The figure depicts things that the system must do, but they are all related to one single thing that the customer wants to do on the system: placing an order. All of the remaining things are alternate flows in that one use case—they are things that might be done in the course of placing an order. Where there is only one useful thing being done, there is only one use case. The “solution” shown in Figure 4-5 is an example of functional decomposition, or (as one colleague puts it) an example of the “circled wagons” formation—one actor at the center of a circle of use cases. This problem is a common one. Why are people drawn to these sorts of solutions? We have an intrinsic need for order, and where none exists we impose it. In the case of functional decomposition, we have a natural tendency to try to break the problem down into smaller and smaller chunks, in a naïve belief that by so doing we can simplify the problem. This perception is wrong; when we decompose the use cases, we have actually compounded the problem.

Here’s why.

The purpose of a use case is to describe how someone or some thing will use the system to do something that is useful to it. It describes what the system does at a conceptual level so that we can understand enough about the system to decide if the system does the right thing or not. It helps us form a conceptual model of the system. Now ask yourself: Would I want to use this system only to inquire into the status of an order if I had never placed an order? It’s not very likely. Or would I need to change an order if I had never placed an order? No, probably not. All of these things are only useful to me if I have placed an order; all of them are necessary to the system’s ability to allow me to place an order.

Decomposing the system into smaller use cases actually obscures the real purpose of the system; at the extreme, we end up with lots of isolated, disconnected bits of behavior. We can’t tell what the system does. It’s just like looking at a car that’s been taken apart—maybe you can tell that it’s a car, and you know that the parts must be useful somehow, but you really can’t tell how. When working with use cases, remember that use cases are a way to think of the overall system and organize it into manageable chunks of functionality— chunks that do something useful. To get the right set of use cases, ask yourself the question, “What are the actors really trying to do with this system?”

In case you’re wondering what the improved version of the Figure 4-5 would look like, see Figure 4-6. These two use cases would encompass all the “functions” that the earlier diagram split out as use cases. You may ask why this is better. The answer is simple—it focuses on the value that the customer wants from the system, not on how we subdivide and structure the functionality within the system.

Figure 4-6. Use cases that combine functions to reflect the real value to the actor

The creation of lots of small use cases is a common problem, especially for teams with a strong background in (or covert sympathies for) functional decomposition. The names of their use cases read like a list of functions that the system will perform: Enter Order, Review Order, Cancel Order, Fulfill Order. This may not sound so bad at first, but there are likely to be many more. Even a small order-entry system generates a list of hundreds of use cases—ones for entering products, reviewing products, adjusting inventory, and on and on. If we stay on this path, we are soon drowning in use cases; if we have a “really big” system we end up with many hundreds of use cases, maybe thousands.

So what’s so wrong with this?

The problem is that the value of these use cases is lost. A use case is supposed to result in something of value to the actor, and at one level being able to enter an order is something that has value. But if the order is never fulfilled, would it still have value? Probably not.

Consider entering an order and modifying or perhaps even canceling it— all of those things are related to the real thing a customer wants to do, which is to receive the goods being ordered. They are also all necessary to what the company wants, which is to receive payment for the goods shipped. If the system appears to the users as a large set of disconnected functions to be performed without any apparent relationship, the system is going to be hard to use. Too many systems are just jumbles of features. Use cases help us to focus on what is really important—the things that have real value—and to define the system around those things. Use cases do not present a functionally decomposed picture of the system.

So be aware of the value the users of the system expect to obtain from the system, and define the system use cases to reflect these values.

When identifying use cases, look to the product vision statement for inspira-tion. Ask yourself for whom the system is being built and what problems the system is expected to solve, and then make sure that the system provides use cases that deliver this value. If the stakeholders for the system are not users of the system, ask yourself who will use the system on their behalf. Sometimes important stakeholders of the system are not users of the system. They expect to get value from the system even though they do not directly use it. They will need to be as involved in the creation and validation of the use-case model as the users themselves. Often, these various stakeholder perspectives will shape the structure and content of the use-case model as much as the users.

As you identify use cases, make sure that the use cases are compatible and complementary to the product vision statement and provide the behavior required to satisfy the stakeholder needs. Make sure that the use cases are capable of delivering all of the features defined for the system and conform to any constraints placed on the system. Great care must be taken to ensure that the vision and the use-case model are complementary and compatible. It is very easy to get carried away when use-case modeling and identify lots of use cases that, although they sound like good ideas at the time, do not actually contribute to fulfilling the project’s vision or conform to the project constraints.

If there is a business model of the system (a description of the business’s processes, potentially expressed in the form of business use cases ^[4]), this can serve the same purpose as the vision. You can derive use cases and actors from the workers used to describe the business processes. The responsibilities of the workers may need to be supported by the system, in which case there will be use cases that describe how the system supports the worker in performing the business process.

Once an initial set of use cases have been identified to support the primary actor goals, many other use cases will be identified that are required to support the system in the provision of these key use cases. These use cases are required to:

It is very difficult to find these use cases at the outset of the modeling activities before the key use cases have been identified and outlined. Instead, the use-case model will evolve and become more detailed as more and more of the actors and use cases are outlined and explored.

Supporting use cases are often overlooked because they do not represent what typically are the primary goals of the system. Neglecting these use cases may produce a system that cannot be easily used, installed, or upgraded. Although these things do not provide the core value of the system, they are essential to the smooth operation of the system.

Make sure you address the use cases required to run and maintain the system, such as system start-up and stop, adding new users, backing up information, and adding new reports. If the system itself is to be configurable, cus-tomizable, or upgradeable, then use cases will need to be defined to offer these facilities to the actors undertaking these tasks.

Remember that the activities related to the finding of use cases go hand in hand with those involved in the finding of actors. Exploring the requirements embodied by the use cases can lead to the identification of more actors, which can, in turn, lead to the need for more use cases. You should also make sure that every actor participates in at least one use case. Actors that do not may be superfluous, or some use cases may not have been identified. Do not expect to find all of the use cases for a system on the first pass.

While identifying the use cases, you may also identify requirements that do not easily fit into the use-case model. These should be captured as part of the Supplementary Specification, which should be evolved in parallel with the use-case model.

After you have identified a use case associated with one or more actors, create a diagram that shows the actors and the use case. Actors that initiate the use case should be shown with an arrow pointing from the actor to the use case. In cases where the system initiates contact with the actor, draw the arrow from the use case to the actor. An example of this is illustrated in Figure 4-7. The arrows represent associations between the actors and use cases that act, in effect, as conduits for information. These conduits are pathways for communication between the actor and the system.

Figure 4-7. The Withdraw-Cash use case from the ATM use-case model

When interpreting use-case diagrams, the arrows should not be inter-preted as directional flows of data. In almost every system, there is a bidirectional exchange of information between actor and use case. Some diagrams may even be shown without arrowheads on the associations; this is perfectly acceptable in the UML, but we prefer to use arrowheads to indicate the initiator of the communication and recommend that you do the same.

The name you give to a use case is important, and it should be chosen carefully. Names shape how we think about things, and the name you choose can make understanding the use case easier or more difficult. While you are brainstorming, allow the use cases to have long names. A newly identified use case may have a name as long as a sentence; this is a good start on the brief description of the use case, and it can be shortened later on. At this stage, it is more important to capture information, not to be succinct or pithy. An active use case name (one that implies action, such as Enter an Order) is a better choice than a passive name (such as Order Entry). Active names imply that something gets done, reinforcing the idea that use cases do something useful. Passive names end up sounding like functions or functional areas within an organization.

It’s usually possible to use active naming, but sometimes it requires a little creativity. Some examples are

You might wonder, “What’s so bad with passive names?” When passive names sound like a functional area within an organization, the use case becomes confused with the activity of the functional area. Functional areas within an organization do many things, and it would be unusual for a single use case to capture all the things that people within the functional area need from the system. Passive names usually send ambiguous messages about the value they provide. For example, what is the value delivered by “Customer Service”? Using passive phrases also makes it more difficult to notice when use cases are missing. For example, what about the situation where a customer wishes to register a complaint or return faulty goods? The passive could be obfuscating the problem. For example:

We know immediately the purpose of “Return Faulty Goods,” but we can’t tell much of anything about the purpose of “Customer Service.” Another characteristic of better-quality names is the ability to concatenate the actor and use case names to produce a meaningful sentence. For example: “Customer Service” is pretty meaningless, whereas “Customer returns faulty goods” is completely understandable.

Are passive names completely without merit? The answer is no, they can be used to group together a collection of use cases with similar intent and purpose. This kind of use case packaging is looked at in more detail in Chapter 6, The Life Cycle of a Use Case.

Each use case must include a paragraph that describes the purpose of the use case and the value produced for its actors or stakeholders. The brief description justifies the use case’s existence.

The brief description should be drafted at the time the use case is identified. A lot of time can be saved in the long run if a few sentences are captured early on that describe the purpose and value of the use case; much confusion is spared when everyone can easily understand the value that a specific use case provides. For each use case, make sure that the brief description captures

Keep the description succinct, but ensure that it is clear and unambiguous. Doing so when you identify the use case pays dividends later on by improving clarity and communication.

It is very difficult to assess the complexity or fully understand the scope of a use case just by looking at its brief description. The goal of the use case may be very simple and clear, but the narrative it contains may be very complex and convoluted. There is little relationship between the complexity of the brief description and that of the use case it describes.

Remember it is not uncommon for the length of the use-case descriptions in a single system to vary from as short as half a page to as long as 30 pages. Each use-case description has to be long enough to clearly tell its story. It has to explain the basic and alternative flows in a form that satisfies all of the stakeholders. For a very simple, data-capture use case with few or no alternatives, it can be a few sentences long, and in other cases—say, for a complex interaction involving many actors with many alternatives—it will require a lot of text.

To get a better idea of the complexity and scale of a use case, you should produce an outline of the use case to complement the brief description. The focus of the outline is to capture the scale, structure, and complexity of the use case rather than the requirements that it will contain. This outline will provide the starting point for the use-case description. See Figure 4-8. Start by listing the steps of the basic flow. Write down the different actions in order. Don’t try to figure out how things are done—just work with the basic flow of events and don’t worry about alternatives. Enumerate the steps 1, 2, 3, 4, . . . . Try not to get too mired in the detail of the use case, generally 5 to 10 steps is sufficient to outline the basic flow.

Figure 4-8. Outlining a use case

Once you’ve agreed on the steps in the basic flow of events, walk through it and identify alternative steps. Enumerate the alternative flows A1, A2, A3, A4, . . . . At this stage the outline is just serving as a sketch of the use case. The intention is that this sketch will be fleshed out and elaborated when the real use-case authoring starts. This step in the evolution of the use case is a very informal and broad-brush stroke. It is just brainstorming to obtain an idea of the shape of the use case and the effort that will be needed to complete its authoring.

The outlining of the use cases in this way will enable the stakeholders and use-case authors to focus on the true requirement-related issues and provoke a lot of discussion about the appropriateness of the set of use cases selected. This discussion is essential to the healthy construction of an effective use-case model. The outlines will make the use-cases more real to the stakeholders and allow them to more effectively join in discussions about the model. There is no point in sitting alone and trying to outline the use cases without first obtaining input from the stakeholders.

As can been seen from the example, decisions are already being made about what is the core functionality of the use case and what is extra, complementary functionality. For example, if it was required that receipts are always dispensed, then A12 would not be an alternative flow but would be included as a step in the basic flow.

The outline will also allow us to start to do some scope management on the use cases, as we can descope some of the nonessential alternative flows. Perhaps there is no requirement for Bank Customers to be able to make withdrawals from any accounts other than the primary account associated with the card. If this is the case, then A13 is not required and can be descoped.

Generally, there are more stakeholders and stakeholder representatives interested in a use case than those that can be deduced directly from the actors involved in the use case. It is important to record the relationship between the use cases and the stakeholders and stakeholder roles that have an explicit interest in the use case. This will help ensure that you are involving the correct people in the development and review of the use cases. In many cases, the stakeholders will have secondary goals for the use cases above and beyond those of the actors directly involved in them. Explicitly recording these relationships will help ensure that these different viewpoints are not overlooked and ignored. Introducing this traceability will allow you to ensure that the interests of each stakeholder are represented in at least one use case.

The use cases collectively provide all of the behavior required of the system. It is essential that they are in accord with the vision, and the objectives and high-level requirements that it contains. Tracing the use cases to the features and constraints defined for the system provides validation of both the use-case model and the vision itself.

There are always a number of high-level requirements that cannot be connected to any use case:

There may also be use cases with no requirements. This could be because the use case is not required or because the functionality was overlooked when the vision was constructed. This situation will need to be resolved with the help of the stakeholder representatives, as there may be issues related to the customer’s awareness of what it needs and its willingness to pay for functionality it didn’t request.

Note: The relationship between the high-level requirements (needs, features, and constraints, etc.) and the use cases is many-to-many. A single feature may give rise to multiple use cases, and a single use case may contribute to the delivery of many features. We will look at the nature of the traceability inherent in use-case modeling in more detail in Chapter 7, The Structure and Contents of a Use Case .

Knowing which needs, features, and constraints are traced to which use case also provides essential context for the people asked to complete the authoring of the use cases. This information will complement, and provide justification for, the brief descriptions and outlines produced when the use cases were first identified.