Use Case Diagrams

For years, I did not see the point of Use Case diagrams.  They were just a bunch of bubbles with stick figures that listed the capabilities of the system.  The Use Case descriptions held the real value.  They described what the system was supposed to do.

A colleague of mine, Dr. Peter Hoffmann, changed my opinion.  Peter preaches that the we should think of the Use Case diagram the way we think of a table of contents of a book.  It gives a quick and concise way to show a system's capabilities -- think section 3.3.1 of an IEEE specification.

A common question  many customers ask about Use Case diagrams is where does one draw the boundary.  I answer that how one displays Use Cases on a Use Case diagram is a function of the model's purpose and the modeler's perspective.  Let me explain.  For Systems Engineers, the boundary box represents everything that you bill to the customer.  Therefore, if you are delivering computer equipment, include it inside the boundary and show the actor as the User.

For Software Engineers, show the boundary at the edge of your work focus.  In other words, if your part of the code interfaces with an API, web service, firmware or physical hardware, show these as actors.

Another common question is how to show the Use Case description.  Again, my answer is to consider your audience.  Use Case description are a great way to share your understanding of the system with the stakeholders.  For one project I worked for the United States Postal Service, I gave Use Cases to the head technician so that he could confirm that the machine worked the way I understood it to work.  He was very comfortable with ladder logic, so I gave him Activity Diagrams.  For another project, the stakeholder was a marketing/sales exec.  He was more comfortable with a text description.  Both methods worked well for the intended audience.