Feeds

Vague and ambiguous use cases revisited

Join Camp Gritty

The essential guide to IT transformation

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).

head shot of Matt Stephens smiling

Matt Stephens.

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.

Secure remote control for conventional and virtual desktops

More from The Register

next story
Apple promises to lift Curse of the Drained iPhone 5 Battery
Have you tried turning it off and...? Never mind, here's a replacement
Mozilla's 'Tiles' ads debut in new Firefox nightlies
You can try turning them off and on again
Linux turns 23 and Linus Torvalds celebrates as only he can
No, not with swearing, but by controlling the release cycle
Scratched PC-dispatch patch patched, hatched in batch rematch
Windows security update fixed after triggering blue screens (and screams) of death
This is how I set about making a fortune with my own startup
Would you leave your well-paid job to chase your dream?
prev story

Whitepapers

Endpoint data privacy in the cloud is easier than you think
Innovations in encryption and storage resolve issues of data privacy and key requirements for companies to look for in a solution.
Implementing global e-invoicing with guaranteed legal certainty
Explaining the role local tax compliance plays in successful supply chain management and e-business and how leading global brands are addressing this.
Advanced data protection for your virtualized environments
Find a natural fit for optimizing protection for the often resource-constrained data protection process found in virtual environments.
Boost IT visibility and business value
How building a great service catalog relieves pressure points and demonstrates the value of IT service management.
Next gen security for virtualised datacentres
Legacy security solutions are inefficient due to the architectural differences between physical and virtual environments.