Use Case Insights Series 2: Why Use Cases (Often) Drive Us Crazy – and the major pitfalls to avoid!
By: Simone Bernardi, Celeris AB
Welcome back! Last time, we introduced the chaos of bad use cases. Now, let’s dive into the details of three major pitfalls of use cases.
Pitfall 1: Data-Centric Use Cases (Losing the User Focus)
Does your use case list look like a menu of database operations? You know the ones: “Create Something, Update Something, Delete Something,” repeated for every object in the system. It’s the classic CRUD trap. These use case names “mean nothing to the users”. (Because I’m sure real users talk about “creating an issue” and “updating an issue” all day, right?) The problem: this approach describes low-level functions and data manipulations, not what the user actually needs to accomplish. The model ends up focused on the internal data rather than the user’s goal. The result? An “awkward, user-unfriendly” system. Users must jump between these mini-functions to get anything done, like piecing together a puzzle with no picture on the box. No surprise that weird gaps and bugs pop up when nobody has discussed the usage from end to end – one project famously required users to print and re-scan a document just to link it to an existing record due to a missing flow. In short, a data-centric use case model is a blueprint of confusion: lots of detailed operations, no clear story.
Pitfall 2: The Post-Condition Obsession (Too Much of a Good Thing)
Ah, the Post-Condition section – a perennial favorite in template-driven organizations. It comes from software design (great for debugging), so surely it must belong in requirements, right? 🙄 Many teams treat it as mandatory, yet often fill it with “N/A” or guesswork. The truth is, writing a correct post-condition for a use case is absurdly hard – it has to be true for all possible paths through the use case, not just the happy path. Most authors give up and jot down something that only holds for the main flow. An expert rhetorically asks: “What is the point with a post condition that is true in about 20% of the paths?”. Good question! We’ve seen attempts: even a simple ATM withdrawal use case ended up with 14 different post-condition scenarios ranging from “customer gets cash, card, receipt” to “customer gets nothing and the ATM eats the card”. Complete? Maybe. Readable? Not at all. Maintaining those conditions is double work – every time you update the use case flows, you must update the post-conditions, inevitably causing mismatches and confusion. It’s like writing the ending of a story 14 different ways and hoping one still matches the beginning. Instead of clarity, you get a document that no one (including the author) wants to read. So unless you enjoy turning simple requirements into a logic puzzle, over-reliance on post-conditions is a trap.
Pitfall 3: Fragmented Storylines (The “Star” Anti-Pattern)
Look at your use case diagram. Do you see little clusters of use cases around each actor, like isolated stars in a constellation? Each actor is the center of their own universe? If yes, you’ve fallen into the “Star” anti-pattern. It usually starts innocently: one team writes the part of the process their department handles, then hands off to the next team, which writes a separate use case for the next part, and so on. You end up with multiple short use cases instead of one coherent story. Sure, each fragment is neat and tidy on its own – but the big picture is lost. It’s as if each actor wrote a chapter of a book without reading the other chapters. When you try to run the whole process from start to finish, the handoffs between these “stars” are awkward at best and failing at worst. (Imagine a relay race where no one practiced passing the baton – not exactly a recipe for success.) The very purpose of use cases is to bridge these handoffs, so cutting the story into disjointed parts defeats the purpose. The outcome is predictable: bugs and missing steps that only surface when it’s too late. Users end up navigating a disjointed system, scratching their heads at steps that don’t quite flow. In short, fragmenting use cases by actor or department creates a beautiful star diagram – and a horribly fragmented user experience.
