The 10 Biggest Mistakes We Make with Use Cases
Use cases are tremendously useful, but they are distressingly subjective. They are not defined by a rigorous grammar as are our programming languages. We have no use case compilers that will parse our use cases and tell us if they are valid, well-formed and meaningful to our business.
Because the concept of a use case is so qualitative, we have a plethora of examples in books and on the web that demonstrate every conceivable variation of content, from high-level business processes to ultra-low level technical specifications.
This essay addresses 10 specific mistakes made by use case writers, and projects creating use cases. Hopefully, this discussion will illuminate the qualitative challenges that we must resolve so we can write effective use cases.
Mistake #1: Not writing use cases at all
The #1 mistake I have observed in my consulting practice is those projects that do not write use cases at all. With the few exceptions listed in Mistake #2 below, almost all projects benefit from the focus that use cases bring to describing the behavior that a software system exhibits to meet the business goals of its users. This also applies to projects writing user stories. Not writing use cases leaves a contextual void for those user stories.
Mistake #2: Writing use cases where they are not appropriate
There are some software systems that do not benefit from use cases. For example, an application that runs as a batch process is not a viable candidate for a use case. Your primary actor is a clock, that invokes a use case called Run Application. The application may interact with a database or ERP system, but beyond that, what user-interaction would your use case describe?
There are some simple system behaviors that can be described by use cases, but a better approach might be a data flow diagram and a screen mock-up. Two recurring examples are Logon/Logoff use cases, and Print Report use cases. The exception to this would be that your Logon, or Print Report, function has significant exception-handling behavior. If so, then a use case format will be useful in specifying that behavior.
Mistake #3: CRUD-Based use cases
CRUD refers to the four functions of a database: Create, Read/Retrieve, Update, and Delete. CRUD-based use cases invariably occur when the use case designer decides that the most important goal of the system is to manipulate the data in the system database. If you are writing a database user-interface, this indeed might be the most important goal. But for a typical business application, the data manipulation is inside the system design and is invisible in the use case. Your application does not exist to read and write to a database. It exists to provide value to its users. If you find yourself naming use case as “Create <data item>”, “Read <data item>”, etc., you are already racing down this unforgiving path. Start over at the top: name your use cases for what the user needs, not what the developer wants to design.
Mistake #4: Writing your use case as a design specification
No, no…a thousand times No! Use cases are not design artifacts. They are, however, inputs to subsequent design activities. Your use cases should not expose your user interface design, or the widgets and controls on your screens or web pages. They should not discuss data formats, technical interfaces, protocols, or any other design-appropriate topics. They should describe what your system needs to provide to its users, so the UI designer, and data designer, and programmer can determine how they should design their areas.
Mistake #5: Mistaking steps in a use case as use cases themselves
When a team have little understanding of the scope or scale of a use case, they too often default to thinking that every behavior they identify for a system must be represented as a use case. This results in an explosion of use cases, most of which are 2-4 lines long, invariably represent low-level technical functions, and your business people will have to wade through many tiny use cases to try to piece together a complete process. Not everything a system does is a use case, and a use case should not be used to describe a single technical transaction such as “Read record” or “Validate Input Field”.
Mistake #6: Having the wrong people write the use cases
This is a management mistake, and is usually a result of expedience: someone is designated to write the project use cases because a) they are the only person available, or b) no one else wants to write the use cases. This is almost always a disaster. Being available, or gullible, does not denote understanding of use cases, or writing skill.
Mistake #7: Incorrectly categorizing your primary actors (users)
Use cases are, by definition, user-centric. But choose your how you name your users, that is, primary actors, carefully. The common mistake made on human primary actors is to name them according to job title, rather than the role that human is in. For example, using the title “CFO” (Chief Financial Officer) rather than a role such as “Financial Report Requestor”, or “Financial Analyst”. A lesser form of this mistake occurs when secondary actors are named according to their technology service. For example, naming a secondary actor “RDBMS” rather than “Loan Repository”, or using “SAP” rather than “Customer Relationships”, which is the part of SAP we are interested in accessing. I say this is a lesser form of error because secondary actors provide services to our use cases, and there is certainly a hint of technical emphasis on interacting with them. But avoid job titles on primary actors or you will have dozens of job-title actors all accessing a given use case.
Mistake #8: Developing directly from use cases
If a set of use cases is all that a developer has, he or she will write code because that is what developers do. But they will also write code from a single-sentence product description, and in both of these cases your chances of getting the product you expect are vanishingly small. Use cases are not a direct input to coding, but they are one essential input to the development process.
Mistake #9: Putting all your requirements into use cases
After 16 years since Jacobson introduced use cases, I still see this happening. The force causing this seems to be a lack of understanding that there are qualitatively different types of requirements: business requirements, user requirements, functional requirements, non-functional requirements, system and business constraints, and business rules. Not only are these all qualitatively distinct, there is no simple hierarchical relationship among these requirements types. Use cases, in particular, should describe only the behavior of a system as it interacts with its users. Don’t put all of these other requirements into your use cases.
Mistake #10: Putting too much effort into the use case diagram
The use case diagram has little business value. It does serve admirably as a table of contents, showing which actors are involved with which use cases. But the ovals on your use case diagram are simply names. The names do not tell you the content of the process the use case is naming. If you do construct a use case diagram, let it assist you in arranging your thoughts about your actors and use case names. Keep it simple and readable; don’t indulge your fascination with <<include>> and <<extend>> relationships, or (especially not) use case generalization. Don’t force this little diagram to carry a burden it cannot handle: focus on the use case descriptions. That’s where the value lies.