Vague and ambiguous use cases revisited
Join Camp Gritty
Oh no, not again: the industry's gone and divided into two camps. In Camp Purity, there's the group insisting that use cases must be abstract and free of any specific technology or UI feature. Simply heavenly! Useless, but heavenly.
Then in Camp Gritty, there's the group politely whispering that use cases work better when they're concrete, specific and tuned into the design. I'm firmly in Camp Gritty (but as you can see from the responses to this linked article, many people aren't).
Of course, it's horses for courses really. The term "use case" has evolved to mean more than one type of specification, and – crucially – is applied at varying stages in the development lifecycle. So use case advice only makes sense if you first establish exactly which type of use case you're talking about, and at what stage it should be applied – oh, and who's actually involved in writing the use cases and the "document ping-pong" that follows while the details are ironed out.
According to the Camp Puritans, "the user clicks the Submit button on the Details page" is an unforgivably evil statement, because it imposes the concept of buttons and clicking on the final UI – and the final UI may not use buttons (not if Steve Jobs is involved in the design, at any rate). Worse, the example implies a web-based system, and surely you want to keep those use cases pure, because the eventual system may not be web-based at all.
If the use cases comprised your first written specification for the system (which they probably shouldn't), then it would make sense to omit the technical details: after all, you're defining the "what" and the "why", not the "how". But it's more likely that the project's first written specification of any weight will be a functional spec: "The system shall allow humanoid entities to update customer details." This is an important document, but handing it directly to the programmers/designers is likely to result in much guesswork, and an eventual system that is almost, but not quite, entirely unlike the customer's own vision of the finished article. ("What we demand is a total absence of solid facts.")
This is where use cases really come into their own - pinning down the specifics. Not to use them in this way would be a terrible shame, as they're so good at it. And if you combine use cases with robustness analysis and a domain model to bridge the gap between analysis and design, then there's little room left for ambiguity and guesswork.
So, who writes the use cases? Usually a non-technical person who spends a lot of time talking to the customers and end-users. But use case writing works best as a collaborative and iterative process. The first-draft text won't be the last. Robustness analysis (aka preliminary design, aka use case realisation, which definitely involves the developers) may result in a virtual rewrite of the use case text; not necessarily changing the scope, but wringing out ambiguity and making sure that the behavioural scenarios are written in the context of the domain model, from which the eventual class design will flow.
Use cases are also useful as a user experience description, exploring the user's path through the UI to complete specific tasks. While a "pure" use case that doesn't pin down the UI might seem like a good thing (rather like several layers of separation in a multi-tiered design), in practice it isn't really much use.
So... at some point in the project you'll need to hunker down and start committing to technical/architectural decisions, so why not make it the use case stage? Join Camp Gritty, you know it makes sense.
Matt Stephens is the co-author, with Doug Rosenberg, of Use Case Driven Object Modeling with UML: Theory and Practice.
Sponsored: Customer Identity and Access Management