The top ten use case mistakes
We’re reiterating the top five use case mistakes from Top five use case blunders and adding five more. For details on the first five, go back to that post.
There’s also a poll at the end of this post – vote for the worst mistake.
- Inconsistency.
- Incorrectness.
- Wrong priorities.
- Implementation cues.
- Broken traceability.
- Unanticipated error conditions. The error conditions are explicitly called out in a formal use case as exception courses. When we fail to think about how things can go wrong, we take a bad situation (an error) and make it worse by leaving our users with no reasonable way to deal with the errors.
- Overlooking system responses. When people use computers, the computers respond. It is a cause and effect relationship – and ideally one that is predictable and comfortable to the user. Reading a use case should be like watching a tennis match, with activities being performed alternately by the user and the system. “The user does X, the system does Y, the user does Z…”
- Undefined actors. Novice and expert users have different ways of using an application. Different design tradeoffs will be made to accomodate for these users. Understanding the domain of the user can also be important. Imagine a calculator application – the use case of “get a quick answer to a calculation while doing something else” will be very different for a loan application officer than it will be for a research scientist.
- Impractical use cases. We have to remember to validate with our developers that they can implement the use cases, given the current project constraints. As a former co-worker is fond of saying – “It’s software – we can do anything” which is true. But considering the skills of the currently staffed team, the budget and timeline for the project, and the relative priority of the use case is prudent.
- Out of scope use cases. If we don’t define the system boundaries, or scope of our effort, we risk wasting a lot of time and money documenting irrelevant processes. Starting with the specious argument – although our user has to drive to the office in order to perform her job, we don’t include her commute in the scope of our solution. An online fantasy sports league application would certainly include a use case for picking players for individual teams – it may or may not include researching player-statistics. Knowing where the boundary is will prevent us from defining and building undesired or unnecessary functionality.
More discussion on common use case mistakes
I liked this article by Susan Lily on use case pitfalls. Susan goes into more detail on out of scope use cases(#10 above), where she talks about defining the system boundary in UML use case diagrams as a means of helping to avoid out of scope use cases. She also encourages using a standard template for use cases (Inconsistency – #1) and proposes a minimum set of criteria for creating your own templates. She provides a good argument against CRUD use cases – in a nutshell, they do not represent primary user goals (but rather tertiary goals).
At one point she proposes a compromise of including low-fidelity screen mockups in use cases as a means to make them easier to understand and more efficient to communicate. I disagree with her here – this is at best a slippery slope, and more likely the use case equivalent of my requirements documentation mistake. Because images can be so powerful – even the simplest screen design elements will provide design guidance (Implementation cues – #4) to the developers – IMHO, it is unavoidable.
—
We’ve added a new feature to Tyner Blain – polls on individual posts! We’re going back and adding polls to the most popular posts, and including them in many of the new ones. Each poll can have up to 7 entries – if an item isn’t displayed, hover over the up or down arrows and the list will scroll. If the text for an entry appears truncated, hover over it with the mouse and the text will scroll. Vote early and vote often, and thanks for your vote!
—
Poll: The worst use case mistake is
If you selected ‘Other – not on the list’ please add a comment and tell us why!
It’s certainly true that “if it’s incorrect, nothing else matters.” Incorrectness, however, tends to get noticed and fixed (at least in my experience). Wrong priorities can last a long time, driving non-optimal behavior for months.
Thanks very much to Susan Lilly who sent us a very nice response in email to this post. She gave us permission to post a synopsis of her thoughts today (7 years after writing the initial article).
1. She never includes screenshots with use cases, and agrees with our previous statements about why they are bad. She clarified that she does occasionally use them as a very potent way to help drive brainstorming responses. A great complement to our post on brainstorming techniques.
2. She also provides a great tip about overlooking system responses (#7). When she emphasizes to novice use case writers that if the system doesn’t have steps in their use cases, the system doesn’t have to do anything. I love it!
Thanks again, Susan!
Scott