Why Don’t Use Cases Just Go Away?!


Part 1: Use Case Diagrams

Use case models have been around for decades. Long after Information Engineering was all the rage and through object-oriented analysis and design they hung around. They threatened to disappear when Agile methods gained popularity, but here they are. Discussed, dissected, blogged about—why don’t they just go away?!

They do not go away because they are, in our opinion, among the most useful tools/techniques we have in our business analysis toolkit. Without going into the history, [i]use case models, both the diagram and the narrative text, provide a structured way to think about our work, work that we’ve always had to do in software development, but which has been simplified with use case models.

We use the model in two very different ways. We find use case diagrams immeasurably helpful in understanding a project’s scope and the use case narrative invaluable for getting the detail needed to build the software. And before continuing, let us preempt one inevitable question—can they be used for other projects besides software development? The answer is “we don’t know” because we have only used them for software applications.

What is a use case? Before we look at the use case diagram, let’s begin with a working definition of what a use case is. We like to think of it as the conversation back and forth between actors and a system. Which is all well and good if we know what actors are and what the system is. Let us explain.

  • The system contains all the work we want to do on the project. It could be manual or automated processing, but we find it most useful for automated systems or equipment like a car or microwave. Elizabeth likes to use the microwave as an example. Theoretically the microwave system might include all interactions with the microwave, including our processes, but that does not make much sense. It’s cleaner and simpler to think of ourselves as an actor interacting with the microwave system. Which brings us to actors.
  • Actors are always outside the system and always interact directly with the system. They can initiate a use case, provide input to it, and/or receive outputs from it. Actors can be people, other systems, time triggers, or event triggers.

So if actors are always external to the system and always interact directly with the system, in the following examples, am I an actor?

  1. The system is a banking deposit system. I walk by a bank lobby on my way to work. One day I decide to take a check to deposit it in the bank. I stand in line with the deposit, and finally when it’s my turn I hand it to a teller who enters the transaction into the automated deposit system. In this case, I am not an actor. I do not interact directly with the system as we’ve defined it. The teller, however, is an actor because they do.
  2. In the above example, let’s broaden the definition of a system to include everything surrounding the teller work, including manual processes and the automated system. As above, I hand my check to the teller who enters it into the system. Because of how we’ve defined our system, in this example I interact directly with the “system” so I am an actor.
  3. The next time I have a check to deposit I don’t want to stand in line, so I go to an ATM and deposit the check. Am I an actor? Possibly. Until we have defined our “system,” we won’t know who our actors are.

Which brings us to use case diagrams, how they help define the scope of our system, and why we like to narrow the system to the automated system. Use case diagrams are one of the several techniques we use to help scope the final product. We find that the use case diagram structures our thinking and helps us remember functionality we might otherwise have forgotten. The use case diagram not only is an easy way to engage business stakeholders, but is almost universally appreciated by the development team. So let’s quickly review the components of the diagram.

  • Boundary box. We like to start with a box that has the name of the system, again our preference being an automated system or piece of equipment. See Figure 1.


  • Actors and use cases are defined iteratively. Defining actors helps us discover use cases and defining use cases helps us discover more actors. Let’s start with actors, which can be people, other systems, time triggers, or event triggers. Actors provide some kind of actions that the system responds to. See Figure 2 below.


  • Use cases describe the ways actors want to use the system. They are processes and eventually the use case narratives will describe each of the use cases. Because use cases are processes, they use the standard process “Verb-Noun” naming convention like “Make Deposit” or “Close Account.” The ovals in Figure 3 show five uses cases in our example.
  • Interfaces allow actors to communicate with the system and the system to talk back to the actor. Using our ATM example, a customer needs to explain what kind of transaction is wanted and the ATM needs to be able to tell when it’s done, giving out money and a receipt perhaps, and asking if another transaction is needed. Interfaces are important. Our system will not be complete until we’ve built them. They are part of the product scope and Figure 3 shows a complete depiction of the scope in our example.


Use case diagrams are usually completed iteratively and fleshed out as more becomes known. Contrary to urban legend about scope, it does change, even after the original baseline. It changes on Agile projects and it changes on more traditional projects. Use case diagrams change, too, and keeping them current is helpful to all stakeholders on the project.

In this article we have defined use cases and looked at use cases and at the components which represent the scope of our product. In Part 2 we will continue with a discussion of use case narratives.

Authors: Elizabeth Larson and Richard Larson, Watermark Learning

Elizabeth Larson, CBAP, PMP, CSM and Richard Larson, CBAP, PMP are Co-Principals of Watermark Learning, a globally recognized business analysis and project management training company. With over 30 years of industry experience each, they have used their expertise to help thousands of BA and PM practitioners develop new skills. Their speaking history includes repeat appearances at IIBA and PMI Global Congresses, chapter meetings, and professional development days, as well as BA World conferences.

They have co-written the acclaimed CBAP Certification Study Guide and The Practitioners’ Guide to Requirements Management. They have been quoted in PM Network and CIO magazine. They were lead contributors to the BABOK Guide® Version 2.0, as well as the PMBOK Guide® – Fourth edition.

[i] Elizabeth saw an Ivar Jacobson presentation on use cases about 10 years ago. Jacobson, of course, is one of the ‘three amigos” (with Grady Booch and James Rumbaugh) who founded Rational Software and the Unified Modeling Language. I had been working with use case models for several years at the time of his presentation. If I remember right, one of the things I learned was that the idea for use cases was rattling around Jacobson’s mind since his work at Ericsson, many decades before this presentation.”

Like this article:
  32 members liked this article


mmonteleone posted on Monday, January 20, 2014 10:00 AM
Thank you for the article.

I have been a big fan of use case for several years. In places where I have heard discouraging words about use case, it was due to an untrained analyst using the technique (i.e., any technique can be misused). For example, the untrained analyst may
• Write very long narratives rather than short dialogues (subject of your Part 2 article)
• Cite actors on the diagram that are not interactive such as receivers of email or printers of reports

I have noted that many agile development teams report using use case to breakdown their product backlog for iterative development. During their dialogue with the client, they start with user stories and transform them into detailed use cases.

In teaching the use case technique, I always seem to have questions concerning the actor TIME. I believe this is because many system analysts equate this actor to a batch scheduler where there is no interaction; the actor TIME merely triggers an event. Perhaps you can shed some light on this?
• How does TIME fit the interactive definition?
• TIME is outside the system, but where is the interaction other than the initial trigger?
• Is TIME really an exception to the actor definition of being outside the system and being interactive?

My experience is also that use cases are used only for interactive-operational systems; not for strategic analytical systems. This is due to the nature of use case construction. Essentially, the use case developer must know what are the actor inputs and the appropriate system responses to those inputs. In building analytical systems (e.g., statistics, correlations, forecasting, data and text mining, optimization, experimental design), the input and responses are unknown. Do you know where use case has been used for developing analytical systems?

Thanks again for the submission.
dwwright99 posted on Monday, January 20, 2014 1:41 PM
The use case technique can be used at different levels of analysis. I often write 'business' use cases which detail what a business needs to do to reach a goal. It includes interaction with parties outside the business, like customers, and includes manual steps along with using systems.

use cases are good for analyzing what is done, but not for analytical systems; the focus shifts from what is done to 'what questions do you want answered '. That requires different techniques, so use cases are a good technique when used for the right thing.
duttasaab posted on Tuesday, January 21, 2014 5:39 AM
In line with the above comments, would like to understand a real world example of BOTH time triggers as well as event triggers as Actors.
Thank you
elarson0315 posted on Tuesday, January 28, 2014 3:52 PM
@mmonteleone and @duttasaab
So here are some examples of a Time actor
Reports are run regularly, like weekly or monthly or year-end or whatever. These reports can be online or batch. It’s time that triggers the generation of the report.
I use my bank’s Bill Payment function. I have certain payees set up on a regular basis and when that date occurs (time trigger) my bank sends out the check to that payee. For example, the bank will send a check to my mortgage company each month. The sending of the check is triggered by the date (time actor).
My thermostat is an example of both a time and an event actor. When a “temperature event” occurs, such as the temperature in the house falling below the temperature registered on my thermostat, the heat comes on. In addition, the heat comes on and goes off at certain times of the day (time trigger).
mmonteleone posted on Wednesday, January 29, 2014 8:43 AM
Thank you for your response. BTW, I attended your session on building trust at last year’s BBC Conference; I enjoyed it very much.

The way I view the TIME actor is that it is “passive” (i.e., it only receives requests from the system). In the use case narrative, the system iteratively requests the TIME actor for the current time. When the current time equals the trigger time specified within the system, the system initiates some action. The use case narrative for generating daily reports would be:

1. The system requests the current time from the TIME actor.
2. Current time equals the trigger time (e.g., “10 AM local time”).
3. The system generates daily reports.
4. Return to step 1.
2a. Current time does not equal the trigger time.
2a.1. Resume main scenario at step 1.

The AC/Heating thermostat example works the same way. The TIME actor and TEMPERATURE SENSOR actor are passive. The system iteratively requests measurements from both the TIME and TEMPERATURE SENSOR actors and takes the appropriate action when the current time/temperature is equal to the trigger time/temperature specified within the system.
MattTaylor posted on Tuesday, February 11, 2014 9:45 PM
This seems to me to be an abuse of use cases in a couple of ways - first the system boundary is superfluous as you have two elements, Actors (outside the system by definition) and use cases (the system), it is the association between an actor and a use case that defines the system boundary.

More importantly the Time/Event actors are not actors as neither has a goal that is to be satisfied by the conduct of the use case (neither can have a goal as they are constructs not agents). So to take your examples:
1. Reports are run regularly, like weekly or monthly or year-end or whatever. These reports can be online or batch. It’s time that triggers the generation of the report.

In both cases (online or batch), the actor is the role requiring the information provided in the report. There might be an intervening system which is a secondary actor so the primary actor is actually a role using the other system.

2. I use my bank’s Bill Payment function. You are the actor since you are the one that requires the automated bill payment service which is a mechanism for achieving the requirements described by the Pay Bill use case. Time gets nothing out of this.
3. Again the thermostat is merely a mechanism for achieving the requirements implied by the Maintain Specified Room Temperature use case.

This kind of woolly thinking is what led use cases into some disrepute. To illustrate - you example of the thermostat - why is this component picked on to have the role of actor. In a room heating/cooling mechanism there are many more important objects such as heat exchangers that conspire to keep the temperature even.
redkins posted on Wednesday, February 12, 2014 6:25 AM
I don't think I could make a better argument of why use cases should go away, than the comment made in the first paragraph of the first response - "untrained" analysts.

If you need to be trained to write requirements in this way then its reasonable to infer that you also need some level of training to consume requirements written in that way. Expecting that all your stakeholders could look at these and understand what they mean is a big leap. So who is the audience? The purpose of writing requirements is to convey expected behaviour of a "system" to stakeholders in as unambiguous a way as possible. In my experience, for those "business" stakeholders concerned with the functionality, it's to prove you've understood what they want. For those stakeholders building the solution, it's to provide them with the information they need to create it.

The very existence of agile at all is down to the fact that these types of notation and ways of writing requirements simply didn't work for the majority of projects outside a closed enterprise ecosystem where everyone knew the notation. Even if people do understand the notation you still have a fundamental problem that natural language has a million ambiguities built in. It is subject to interpretation by the reader and the chances of you nailing the requirements with 100% accuracy with no omissions, first time, and conveying that to all your stakeholders is slim to zero for anything other than the simplest things.

We all innately share a common tool we need to convey information - language. The challenge is to remove the ambiguity, misunderstandings and misinterpretations that come with it. Sometimes that can be via diagrams, or possibly even a commonly shared and understood notation (see...I'm not saying use cases would never work in any situation). However, I think the iteration and incremental steps embraced by typical agile project to gradually chip away at the omissions and misunderstandings, are a far better answer for most situations than restricting yourself to proprietary notations that form a barrier rather than an aid to conveying information.
driep01 posted on Wednesday, February 12, 2014 9:00 AM
Hi @redkins, this is the reason why use cases fits so perfectly into the Agile iterative concept. You set up the Use Case, discuss with stakeholders, adapt the Use Case until ambiguities are removed. This can typically happen in a requirements gathering sprint that runs parallel to a development sprint by the team.

By next Sprint, you (as product owner/lead BA/only BA) takes the UC to the sprint planning meeting as the user story. The team interrogates the PO about the UC and again an iterative cycle.
pVuollet posted on Wednesday, February 12, 2014 6:31 PM
I agree with the cautionary views about using use cases with system design. The example of a thermostat would be implementation details, not a use case. The use case is "user sets temp to maintain","user sets temp to lower from t1-t2". And the examples about TIME where the system asks for the time is definitely implementation details. It could be some other system that dictates that part, the user doesn't know or care generally. What the user does care about is how they interact with the time event. Can they change it? Do they receive output from the system? I would consider output a use case; if you miss that one you'll be scrambling to find a way to get the data out of the system later. I'm a software developer, cheers and thanks!
Rich_Larson posted on Thursday, February 13, 2014 10:12 AM
@mmonteleone and others - thanks for your comments. Regarding passive actors, I would say specialized types like Time or Events are trigger-type actors. After they trigger a business process, their job is done (meaning they cannot receive the output of a use case). If time or an event is important to the business, these actors belong in your use case model because they represent a feature or requirement. (Real-word example: our Training Management System had a requirement to generate daily emails of registration activity. The daily time actor was on our use case diagram to represent that. How the developer implemented the daily email (with a Chron job) was not a requirements concern and not part of our use case.)
Rich_Larson posted on Thursday, February 13, 2014 10:33 AM
@MattTaylor - to your points:
Point 1. Actors do not need to have a goal to be included in a use case. Some actors receive the output of a use case and don't have a goal per se. But if you wanted to stretch the analogy far enough, you could say the goal of a time or event trigger was to make something happen.
Point 2. Agreed, the user who wants to pay the bill is an actor and initiates a “Pay Bill” use case. Time would come into play to trigger a “Send Payment” type of use case. This use case has the end-user being a secondary actor who receives notification that the bill has been paid.
Point 3. A mechanism is another way of saying interface. I see the Thermostat as being the interface between the actor who sets the temperature and the heating/cooling system. A “change of temp”’ event takes place that causes the system to turn on or off. In our Training Management System, an important event for us is when a website visitor downloads a template or views a recorded webinar. We want it to trigger the system to alert us of that event. A valuable event for us and not sure how that could be woolly thinking, Matt!
Rich_Larson posted on Thursday, February 13, 2014 11:14 AM
@driep01, we think your comment about how use cases fit the iterative Agile approach is spot on. Our company has long taught that use cases are great iterative tools, from the diagram, to description/pre- and post-conditions, to successive narrative layers as needed. Thanks for elaborating even further.
Rich_Larson posted on Thursday, February 13, 2014 11:16 AM
@Redkins - I think you are raising an interesting point and one that many Agile proponents embrace. The delivery team needs detail to estimate and build the user story. They can either get that detail formally with a use case (ideally this grooming will occur prior to the sprint) or informally during the sprint.

We find that written narratives are most helpful to clarify when to begin the user story, when “done is done,” and the acceptance criteria. All projects, regardless of approach, need that. We agree a co-located Agile team needs less formal documentation. But, if project teams are dispersed across the country or the world, use cases can help bridge the gap in time and space.

In addition to use cases, we heartily endorse and use prototypes to “convey expected behaviour of a "system" to stakeholders in as unambiguous a way as possible” as you aptly put it. Used together with the written narratives, both tools clarify and reduce ambiguity. The use case diagram provides a visual overview of the important facets of a system as well. They can be the visual representation of your product backlog.
pVuollet posted on Thursday, February 13, 2014 4:32 PM
@Rich_Larson via @MattTaylor Point3: that's what my argument is about right there. You're designing a solution with your use case by stating that the system turns on or off in reaction to an event. The event is the byproduct of the use case of "maintain a set temperature". The implementation may not be a hard switch, that's an assumption about the system that you're building into your use case. That kind of use case is dangerous because it takes away from ingenuity by setting the bar according to a convention. What if the system was dynamic and simply changed as the temp approached the input value? Doesn't that achieve the same goal?

Add to it other goals such as "efficiency" and "tolerance" and you would have a more complete picture. So often those points are missed. We have a joke for this: "oh, you mean you want more than one user to be able to use the system? At the same time?". My point is about assumptions. Don't assume the details of the system itself, write use cases about outside actors interacting with the system.

"an important event for us is when a website visitor downloads a template or views a recorded webinar "
The degenerative case is that a user does something. Sure the user doesn't care bout the output, but that's the input. Those events involve a user as the actor. Any case of Actor can be associated to a specific type of user, even those that are triggered by "other systems". As soon as that system interacts with our system, it becomes part of it and some other human driven action drives all events at some earlier point. This is important because integrations can be complex and some events have less meaning or are flawed when not coupled to motivation. Stating the original human driven motivation in the use case can be a way of avoiding unnecessary flaws in the system as it integrates with larger systems.
elarson0315 posted on Friday, February 14, 2014 5:27 PM
@pVuollet, Let me take off my BA hat and put on my sponsor hat. All I know is as a sponsor, I want the products that I pay for to meet my requirements. Other than being maintainable and meeting other non-functional requirements, I don’t care how my requirements are implemented. I want my requirements met and I get very cranky when they are not met. As Rich noted, we recently implemented a new training system. We had completed a number of use cases and sent them to the contract programmers who were local but off-site. The requirements documented in use cases were met. Where we had not completed use cases, the developers made business decisions for us without consulting us. The end result is that here we are with a terrific system, but one that not only required expensive rework, but numerous, cumbersome workarounds.
baldrick posted on Tuesday, February 18, 2014 3:42 PM
Several comments regarding the comments following this article, as follows:
baldrick posted on Tuesday, February 18, 2014 3:48 PM
a) We like to start with a box that has the name of the system.

Regarding Matt Taylor's comment, agreed that the system boundary box is superfluous and was not part of use case notation for the majority of my experience. I can only imagine that it was introduced as a reading aid for people without experience of use case diagrams. In which case it's be nice if this was explained that it is purely aesthetic, and that it adds no additional information to the model.
baldrick posted on Tuesday, February 18, 2014 4:03 PM
b) Timer actors and when they are appropriate.

My first comment is that one should always try to find alternatives to timer actors if at all possible, but sometimes there is no alternative.

In order to understand when timer actors can be appropriate, one has to understand the difference between a business use case and a system use case. (When I see arguments for and against appropriateness usage in use cases, the sides are often discussing different types of (Business or System) use cases, so they may be both right.)

In a business use case the actors are people. BUCs are all about providing benefit to a group of people. They are not about making systems more efficient, because - it is entirely possible that in order to provide that benefit we don't even need a machine.

System use cases are about what changes are needed to this machine in order to satisfy the needs of the business. SUCs are all about machines, there are no human actions - in fact humans may not even be involved, we just think that they probably are.

The primary* actor of a SUC is the role that triggers or initiates the SUC.
The *primary actor of a BUC is the role that receives benefit.
(With this information I know that the article is describing system use cases.)

With these 2 distinctions in mind, now you can see that although a Timer is inappropriate for a BUC, it is a perfectly good actor for a SUC.

*See item c) for definition of Primary actor.
baldrick posted on Tuesday, February 18, 2014 4:06 PM
c) Primary and Supporting Actors

How can I tell from the above diagrams, which actors are the primary actors and which are supporting?

By primary I mean:
- if it is a BUC diagram which actor is getting benefit from the use case?
- if it is a system use case, which actor is triggering the use case?

Supporting actors are all other people or systems out side of the use case that assist with it s completion. They do not necessarily get any benefit, nor do they have to initiate any action by the use case.
baldrick posted on Tuesday, February 18, 2014 4:13 PM
d) Jacobson, 3 Amigos and UML.

Discussing use cases without mentioning IJ (which I see you did as a footnote), is akin to discussing the invention of the motor car without mentioning Henry Ford.

Jacobson joined Booch and Rumbaugh at Rational in the mid-90s.
I knew about use cases in the early 90's long before they were an established component of UML.

baldrick posted on Tuesday, February 18, 2014 4:19 PM
d) If you need to be trained to write requirements in this way then its reasonable to infer that you also need some level of training to consume requirements written in that way.

By this argument, one can make a case for not writing software or building a user interface for any computer system.

Everytime you take a paper artifact and transform it onto a computer user interface, there is a significant amount of training involve, so let's not do it and stick with the old paper method.

The reason why we write use cases is because to improvement of understanding to the customer (or other consumers), as a result of their minimal training greatly increases their understanding and hence lowers the production costs. I know of no more efficient way to get your requirements across to the right audience.
Rich_Larson posted on Tuesday, February 18, 2014 6:29 PM
@baldrick - to some of your points:
Point a: if a model’s convention like a boundary box can aid reading, we’re all for using it all the time.
Point b: we agree a timer should only be used when needed. We don't agree about separating business vs. system use cases.
Point c: There is no need or ability for distinguishing primary from secondary actors on a use case diagram. We've never seen the UML mention that. What you are talking about is handled better in use case narratives by providing actor details there. Our article only covers the diagram and we'll cover use case narratives at a later date.
Only registered users may post comments.

Latest Articles

The Core Question about Building Better Software
Apr 14, 2019
In recent years, agile software development has been the classic example of this pursuit of magic solutions, so I’ll use that as an example here...

Copyright 2006-2019 by Modern Analyst Media LLC