Use Case

Use cases are a wonderful idea that has been vastly overcomplicated. Over and over again, I have seen teams sitting and spinning in their attempts to write use cases. Typically, such teams thrash on issues of form rather than substance.

The real trick to use cases is to keep them simple. Don't worry about use case forms; simply write them on black paper or on a blank page in a simple word processor or on blank index cards. Don't worry about filling in all the details. Details aren't importance until much later. Don't worry about capturing all the use cases; that's an impossible task. The one thing to remember about use cases is: tomorrow, they are going to change.

Writing Use Cases

We write use cases; we don't draw them. Use cases are not diagrams. Use cases are textual descriptions of behavioral requirements, written from a certain point of view. UML does have use case diagrams. However, those diagrams tell you nothing at all about the content of the use cases.

A use case is a description of the behavior of a system. That description is written from the point of view of a user who has just told the system to do something in particular. A use case captures the visible sequence of events that a system goes through in response to a single user stimulus. Use cases don't describe hidden behavior at all.

Typically, a use case is broken up into two sections. The first is the primary course. Here, we describe how the system responds to the stimulus of the user and assume that nothing goes wrong.

For example, here is a typical use case for a point-of-sale system.

Check Out Item:

1. Cashier swipes product over scanner; scanner reads UPC code.

2. Price and description of item, as well as current subtotal, appear on the display facing the customer. The price and description also appear on the cashier's screen.

3. Price and description are printed on receipt.

4. System emits an audible "acknowledgment"  tone to tell the cashier that the UPC code was correctly read.

That is the primary course of use case! Nothing more complex is necessary.

Alternate Courses

Some of those details will concern things that can go wrong. During the conversations with the stakeholders, you'll want to talk over failure scenarios. Later, as it gets closer and closer to the time when the use case will be implemented, you'll want to think through more and more of those alternative courses.

What Else?

What about actors, secondary actors, preconditions, postconditions, and the rest? Don't worry about all that stuff. For the vast majority of the systems you will work on, you won't need to know about all those other things.

Diagramming Use Cases

Of all the diagrams in UML, use case diagrams are the most confusing and the least useful. I recommend that you avoid them entirely, with the exception of the system boundary diagram.

The underside figure shows a system boundary diagram. The large rectangle is the system boundary. Everything inside the rectangle is part of the system under development. Outside the rectangle are the actors that act on the system. Actors are entities outside the system and provide the stimuli of the system. Typically, actors are human users. They might also be other systems or even devices, such as real-time clocks.

 

   

      Inside the boundary rectangle are the use cases: the ovals with names inside. The lines connect the actors to the use cases they stimulate. Avoid using arrows; nobody really knows what the direction of the arrowheads means.

     This diagram is almost, but not quite, useless. It contains very little information of use to the programmer, but it makes a good cover page for a presentation to stakeholders.

Conclusion

     If once you proceed down the dark path of use case complexity, forever will it dominate your destiny. Use the force, and keep your use case simple.

(From " Agile Principles, Patterns, and Practices in C#")