Use Case

Typical interaction scenario from a user's perspective for system requirements studies or testing. In other words, "an actual or realistic example scenario".

Use case is pronounced to rhyme with "deuce case"?

See also UseCases. A use case describes the use of a system from start to finish. Use cases focus attention on aspects of a system useful to people outside of the system itself.

At the end of a use case value, has been provided to the user who initiated it. A use case captures a requirement the user places on the system.

IvarJacobson suggests use cases take a central role in SoftwareEngineering and BusinessProcessReengineering.

We widen the (informal) definition of UseCase on the Meatball:Twinpage to include business objects and services, thus building a terminology for ExtremeOpenBusiness. -- FridemarPache

I sense that Jacobson and his followers employ use cases for both success and "failure" legs. In telecommunications, as in many other fault-tolerant applications, the AbuseCase is the rule. For example, code that expects a 7-digit dial string should unceremoniously handle an on-hook midway through dialing. In fact, some such systems should behave properly if a power line falls across the phone line in the middle of dialing. By the AbuseCase/UseCase distinction, these would be examples of an AbuseCase. To the hearty telecommunications programmer, they're business as usual.

side note: I think ALL software should be written like this. For example, if you plan on reading data from a text file and parsing fields, give your code a large mp3 or something and see what happens. If data is written out to a file that is appended to on next restart, make sure you don't duplicate data. Make sure running 12 instances of it at once doesn't screw something up, etc. -- EvanLanglois

I've understood use cases to capture snippets of abstract activity that accommodate both success and failure. In a text editor, "delete character" might be a use case. Never mind that the cursor is sitting between lines so that nothing is deleted, but an error message is generated: that is in the purview of the use case. IvarJacobson and RebeccaWirfsBrock can probably offer more decisive answers. -- JimCoplien

I am skeptical of use cases because one underlying presumption is that software people should swim upstream, trying to discern requirements. A second assumption is that Requirements should be a list of testable assertions about the software and system capabilities. Both are fundamental errors. What is needed is a list of testable assertions about ways the business can be helped with automation of information and decision. We should be testing whether the the business is helped by the system not simply whether the system exhibits capabilities 1, 2, 3, etc., as listed in the requirements. Further, back to the first problem, these assertions should come from the ProblemSystemPerspective, not from those vested in designing the MIS. We were cautioned centuries ago about sending software authors out to interview users about requirements. It goes something like "-- the blind shall lead the blind and all fall in the ditch, together." -- JackRing

I agree that there's a big disconnect between the market and the coders today. I think we should strive for joint understanding between the user community and the programming community as a long-term solution with as few middlemen as possible. But it will take a long time to get there, and we need something in the mean time.

Use cases are one of many perspectives that help fill this gap. Yes, you need input on non-functional requirements and business ramifications, but I don't think any of these perspectives rises about any of the others in the general case. There's no substitute for a system of profound knowledge. Use cases are a piece of this puzzle. They've proven themselves to be a piece of this puzzle in many successful developments; they seem to enjoy a lot of successful application in telecommunications, the domain with which I'm most familiar.

There's a fairly well-known story about a DOD contract several years back. The contractor's walls were covered with DFDs for the design of the software to land the B1 (I think) bomber. The designers knew that's what they were doing, but they knew it only in the most abstract sense. The design was guided by constraints and desiderata that far outstripped the designers' familiarity with the domain.

So I'm not sure I understand what the testable assertions are that describe how this business can be helped with automation. And I'm not sure all pilots and ATCs could agree on them. They would agree, however, on the control scenarios for landing a plane.

Speaking of planes, I was flying back from Boston today, sitting next to a software consultant from Minneapolis. He just finished a contract working on warehouse management software for an east coast site. He did most of the work before visiting the site. Going there and just seeing the locks and tags and layout clarified things for him immensely. Oh, he had all the testable assertions about ways the business can be helped with automation of information and decision. But, somehow, that didn't quite do it. For example, such documents usually miss the AbuseCase's. Those are less important in some domains than others, but they're pretty important in telecom and in autopilot software. Maybe it's because we have these needs that we see the world differently than one finds in a ProblemSystemPerspective alone.

He also mentioned to me that one of his friends develops autopilot software. That friend flies in the planes that run the software under development. Certainly not use cases, but no platitudes about testable assertions and business advantages either. He lived it. We sometimes do the same thing with telecom systems: the users become the first customers of their own code. Sure beats a business or requirements document.

A lot of the early PatternPeople? came together to develop a body of literature that would accelerate mutual understanding between software authors and their customers. To me, that's the best direction to address this issue. It will take a while. That's much of what this site is about. But for the time being, we celebrate what we've seen work, use cases being a good example.

(Jack - though I believe use cases work for software, I'm much more empathetic with your perspective for use cases for BusinessProcessReengineering. They're the wrong cut.)

-- JimCoplien

At OOPSLA '98, there was a workshop on UseCasePatterns. Let's keep the conversation going...

Jacobson let it be known that in UML, "extends" will stay as (the mystery) it has always been, but that "uses" seems to have been misunderstood, so will now be replaced by "generalizes" and "includes". (Believe it or not, to me that is all clear and fair ... but I suspect it may not be that to everyone). -- AlistairCockburn

GradyBooch covers a weather station case study in ObjectOrientedAnalysisAndDesign in which he describes "storyboard scenarios".

Examples:

Each scenario has a goal, structure and describes interaction between the system and its users.

Each scenario consists of a title (as shown above) and numbered steps. Each step describes action undertaken in plain English, possibly with branching logic ("...if the user selected wind speed to this, else do that...") and indicates which step is to be performed next.

Are these scenarios use cases? Is there any legitimate reason not to classify these scenarios as use cases?

--

My own personal experience with the humble UseCase was in a student project as requirements lead. It seemed to involve turning a half-hour interview with the client, from which the various user types became quite clear, into a massive, incomprehensible pile of UseCaseDiagram?'s. Endless hours were spent drawing stick figures and lines, which were meaningless to the client, and caused problems when they became out of date as the use cases themselves moved on. Worse, the use cases described a level of detail and an implementation (the user logs on *then* selects a document and *then* chooses to view its properties and *then*...) which were never given as requirements. The designers of course ignored them totally, having better things to do than read some 40 pages of UCDs. I'm sure they have a purpose in the right situation.... -- SteveBennett

Personally, I do not consider UCDs to be use cases. I'm with your client and designers... and I'll bet both would be more inclined to read 40 pages of plain text that tells simple stories. -- ScottHightower?

Use Case Tutorial - http://www.parlezuml.com/tutorials/usecase/intro.htm

Use Case Tutorial - http://www.readysetpro.com/whitepapers/usecasetut.html Use Case Templates - http://www.readysetpro.com/

Compare and Contrast UserStory

EditText of this page (last edited November 13, 2014) or FindPage with title or text search
Meatball