The best UML “Use Case” definition I know

By Alvin Alexander. Last updated: October 2, 2021

Every time I read an article or book about UML “Use Cases” I cringe a little bit. Every author says something like “Jacobson left the definition of a Use Case too open,” and then they try to work through some elaborate scheme of what a Use Case means to them. IMHO, the best use case definition was created in the early 1980s, long before Jacobson coined the term.

The best UML “Use Case” definition

Here’s the best Use Case definition I know:

“A UML Use Case is the smallest unit of activity that is meaningful to the user. A Use Case must be self-contained, and leave the business of the application in a consistent state.”

That’s pretty good, isn’t it? I can say that because I didn’t come up with it.

Wonder where it came from (and when)?

Source of my Use Case definition

This Use Case definition comes from my knowledge of counting Function Points, more specifically the technique known as Function Point Analysis, or FPA.

You see, the Use Case definition I just set forth is actually the definition of an elementary process in Function Point Analysis. Interestingly, this simple description, along with descriptions of External Inputs, External Outputs, and External Inquiries fits perfectly well with the concept of a UML Use Case, and in fact, it simplifies and even resolves the situation.

I’ll go even further and say that for my own purposes, I’ve created a tool named FPTracker, and in FPTracker I have successfully considered a Use Case and an Elementary Process to be identical — for over six years now, and dozens of projects.

Oh, and one other thing: The first drafts of the FPA documentation were created way back in 1981 — pre-dating the UML by at least 13 years.

I don't know why there is no standard “Use Case definition” after all this time, but if you’ll take the time to read the Function Point Counting Practices Manual, I think you’ll see that a standard UML Use Case definition already exists.

Three more definitions to help with UML Use Cases

UPDATE:

I’ve come back here to update this Use Case definition article with three more FPA definitions that might help you:

An external input (EI) is an elementary process that processes data or control information that comes from outside the application boundary. The primary intent of an EI is to maintain one or more ILFs and/or to alter the behavior of the system.

An external output (EO) is an elementary process that sends data or control information outside the application boundary. The primary intent of an external output is to present information to a user through processing logic other than, or in addition to, the retrieval of data or control information. The processing logic must contain at least one mathematical formula or calculation, create derived data maintain one or more ILFs or alter the behavior of the system.

An external inquiry (EQ) is an elementary process that sends data or control information outside the application boundary. The primary intent of an external inquiry is to present information to a user through the retrieval of data or control information from an ILF of EIF. The processing logic contains no mathematical formulas or calculations, and creates no derived data. No ILF is maintained during the processing, nor is the behavior of the system altered.

As you can see by their definitions, each of these processes are an “elementary process,” which in my world, is the same as a UML Use Case.