Episode 2: Who Ya Gonna Call?

Thursday, September 25, 2008 – The UML Guy really gets into Use Case Diagrams!






Some useful Use Case Diagrams

In this diagram, we see some truly useful Use Case Diagrams. These diagrams are about requirements in context. Too often, we receive requirements as just a bulleted list of features, or a bulleted “The system shall…” list: “The system shall allow users to file receipts. The system shall reconcile receipts against outstanding invoices. The system shall become so convoluted and ill-defined that there’s no chance you’ll ever implement it correctly.”

These bullet lists aren’t bad (well, some are…), but they’re incomplete. They don’t tell you who requires specific features, nor what goals they want to accomplish through those features. As a description of requirements, they’re a starting point at best. Too often, they’re a trap: seemingly complete, but not.

Use Case analysis is all about putting requirements into a context. Who needs this feature? Why do they need it? How will they use it? What will they produce with it? How will they know it’s correct? How often will they use it? What steps will they follow? What rules and constraints apply? Who else will be involved?

There are a lot of techniques in good Use Case analysis, much more than can be captured in a simple diagram (or in a comic strip). Cockburn has a lot to teach on that subject. [1] But good Use Case Diagrams are a starting point. And busy teams may find they can’t squeeze in time for the Full Cockburn on every Use Case, but can use the diagrams to discuss which Use Cases require more detailed analysis. Agile teams in particular may prefer this approach, because Agile Development emphasizes the minimum documentation needed to successfully meet the requirements. Obsessively following the Full Cockburn (perhaps due to management dictate) can end up with 15 pages of documentation for Log In, without any actual code. It’s more Agile to start with Use Case Diagrams, and then add more detail where you find it’s necessary. Don’t underanalyze, but definitely don’t overanalyze.

I should add: there’s no UML reason I couldn’t have put all these Use Cases and Actors into one big diagram. I see it done all the time. And most of the time, it’s a mistake (in my opinion). The diagram gets too big, with too much going on. Individual details get lost in the confusion. Even though you drew it as one diagram, readers end up reading it as smaller diagrams within the diagram, focusing just on one Actor and that Actor’s Use Cases at a time. So it’s better to draw it as separate diagrams in the first place. (You’re not gonna listen to me. I know that. But I’m telling you what my experience has been.)

[1] Alistair Cockburn, Writing Effective Use Cases (ISBN 0201702258).




Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.