Why (No Use) Cases?

There seems to be a real reluctance in the industry to draw Use Cases. The excuses seem to take the following forms:

1. A general skirting around the subject; e.g. you'll ask a project manager or BA for use cases, and they'll nod quietly, but they'll never produce them. If they do, they'll be so trivial as to be useless; all of the BAs I've worked with have never understood, or produced, use cases;
2. "It's not necessary: use cases add no value." - this usually comes from developers; if the dev already has a spec, and understands the requirements, and will have no interaction with customers and testers, then perhaps this point is valid; in all other cases, however, I generally don't agree with this statement;
3. "I do XP, baby" - I'll discuss the differences between user stories and use cases in a future post; this post presupposes use of standard methodologies (XP still isn't that widespread...).

I think all 3 of the excuses listed above derive from ignorance of what use cases are for, and what they're about. When you try to produce your first use case as a developer, you'll try to create some kind of flowchart, containing absolutely everything there is to know about a system, to the greatest level of detail. This is not the correct approach, and you'll wind up creating something unreadable, and finally abandon it.

At the other end of the extreme, you'll wind up with what I like to call "Stick men holding balloons" - these diagrams are useless. The diagram will consist of the actor symbol (the "stick figure"), connected to a single use case that says something like "do stuff". They're just another way of stating the obvious, and I've generally seen them produced by folks who are vainly trying to "show off" their UML knowledge. If a use case (or any UML diagram) doesn't communicate anything, then it's failed in its purpose.

Use cases are designed to be simple, to be easily followed by non-technical people. They show the behaviour (features, functionality, whatever you want to call it) of a system, at a high level. They were not designed to show logic, error conditions, branching, etc that you might be inclined to shove into a flowchart. In UML, you use activity diagrams (and sequence diagrams) to model the logic.

So what's the use of use cases?

• They provide you with an instant view of the system and specifically what it should do; implementation is left out of the equation, so the user will be able to understand and verify the diagrams;
• You can hand the use cases to a tester, and they will be able to generate a test plan and scripts based on the diagrams;
• You can hand the use cases to a dev, and they can use them to help clarify points directly with the user / BA, and they can then either start coding, or break the diagrams down further with activity and sequence diagrams;
• You can hand them to a project manager, and they will be able to create a task list in project based on the use cases, and then break these into subtasks; estimates can be negotiated based on discussing the use cases with devs, and they can work out what's in scope for a release by talking them through with the users.

XP-ers will see lots of parallels with user stories... but obviously there are doctrinal differences between use cases and stories, primarily due to UML being considered non-agile. I'll talk about this soon...

Next: What do Use Cases Look Like?