Use cases can be difficult to talk about, because they immediately invoke so many different preconceptions and prejudices. High school English teachers know that some words aren’t just words – they are symbolic, and represent ideas. They had us write essays like “Who do I think is a hero” and everyone picks a different person, for different reasons.
This can be very powerful as just throwing out a loaded term like hero or use case communicates a lot more information than the handful of letters would explain. This is also very dangerous, when you throw a different idea than the one that the listener catches.
If you throw “brave fireman who saved my cat”, and your listener catches “big sandwich with mustard“, you’re in trouble.
Use cases suffer from this symbolic blessing-curse, but added to that are people’s past experiences. Executives may have a hazy recollection of “that big project that ran over budget had a bunch of use cases” and be predisposed to not wanting us to invest a lot of time in them.
Or even worse, people are likely thinking of firemen and kittens – everyone seems to have a different definition for use case.
In the next few posts, we will look at different ways to think about use cases, and pull together some of the more accepted definitions into one place, where we can contrast them and understand the differences.
Quick links to posts in this series
- Use case series: Introduction
- Use case series: Formal use case
- Use case series: Informal use case
- Use case series: UML 2.0 use case diagrams
- Free Informal Use Case Template
Latest Articles
Comments on all Articles
