Feeds

Vague and ambiguous use cases revisited

Join Camp Gritty

Business security measures using SSL

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.

New hybrid storage solutions

More from The Register

next story
New 'Cosmos' browser surfs the net by TXT alone
No data plan? No WiFi? No worries ... except sluggish download speed
'Windows 9' LEAK: Microsoft's playing catchup with Linux
Multiple desktops and live tiles in restored Start button star in new vids
iOS 8 release: WebGL now runs everywhere. Hurrah for 3D graphics!
HTML 5's pretty neat ... when your browser supports it
Mathematica hits the Web
Wolfram embraces the cloud, promies private cloud cut of its number-cruncher
Google extends app refund window to two hours
You now have 120 minutes to finish that game instead of 15
Intel: Hey, enterprises, drop everything and DO HADOOP
Big Data analytics projected to run on more servers than any other app
Mozilla shutters Labs, tells nobody it's been dead for five months
Staffer's blog reveals all as projects languish on GitHub
SUSE Linux owner Attachmate gobbled by Micro Focus for $2.3bn
Merger will lead to mainframe and COBOL powerhouse
iOS 8 Healthkit gets a bug SO Apple KILLS it. That's real healthcare!
Not fit for purpose on day of launch, says Cupertino
prev story

Whitepapers

Providing a secure and efficient Helpdesk
A single remote control platform for user support is be key to providing an efficient helpdesk. Retain full control over the way in which screen and keystroke data is transmitted.
WIN a very cool portable ZX Spectrum
Win a one-off portable Spectrum built by legendary hardware hacker Ben Heck
Storage capacity and performance optimization at Mizuno USA
Mizuno USA turn to Tegile storage technology to solve both their SAN and backup issues.
High Performance for All
While HPC is not new, it has traditionally been seen as a specialist area – is it now geared up to meet more mainstream requirements?
Security and trust: The backbone of doing business over the internet
Explores the current state of website security and the contributions Symantec is making to help organizations protect critical data and build trust with customers.