Feeds

Use case style means handbags at 30 paces

Style is all that matters

Intelligent flash storage arrays

In February, I wrote a Reg Developer article which caused some consternation. The article's message distils down to: Don't write vague use cases, write concrete, specific use cases that leave nothing to the imagination instead. Controversial stuff.

head shot of Matt Stephens smiling

Matt Stephens.

It turns out, I believe, that use case style hides a miasma of strong feelings and conflicting opinions far in excess of anything seen in the programming world.

Programmers have it easy: curly brace positioning, level of commenting, variable naming style etc. The Great Napoleonic Curly Brace Positioning War of 1803 was a schoolyard tussle compared with the political infighting that goes on around how to write use cases.

There are some elements of use case style that can seem important, but which ultimately don't make a shred of difference (except to slow the project down while everyone bickers) - like whether to structure your use case in the "narrative paragraphs" or "numbered list of steps" styles, or whether to link your use cases using "includes", "extends", or "invokes" stereotypes.

But there are some elements that really do matter, because they affect the ease with which the developers will be able to interpret your specification. Here are a few of them:

Active versus passive voice: Here's a passively worded description: "The capability is provided for users to log in, using a password-protected authorisation scheme." And here it is in active voice: "The user enters her username and password, and then clicks the Login button. The system looks up the user profile using the username and checks the password. The system then logs in the user."

If you write your use cases in active voice, you'll find that you write less ambiguously, and you'll prevent your reader from falling asleep face-first in her double chocolate chip muffin, which she'll thank you for.

Functional versus behavioural descriptions: Use cases are behavioural requirements specs, each one describing a user's interaction with the system. Mixing in functional requirements ("The system shall be capable of detecting intruders by their typing speed") is a common malpractice. Of course, functional requirements do have their place, but that place isn't in your use case descriptions.

How many 'rainy day' scenarios is enough? Ten. Three. One hundred. Of course, there is no magic number. The correct number of rainy day scenarios is simply when you've brainstormed and quizzed the end-users and can't think of any other variations or ways in which the 'sunny day' scenario could go wrong.

Comprehensive versus Minimal Templates: What else can we add to our template? Preconditions, post-conditions, scope, minimal guarantees, level, context of use... The list of fun and entertaining subheadings to add to your template is endless. But keep in mind that the more "blanks" you add that need to be filled in for each use case, the longer each use case will take to write; and, the less bang for your buck you'll get out of them.

Whether to reference domain classes by name: By domain classes I mean names for real-world or problem domain objects referenced in the project, e.g. trade, ledger. Some analysts feel that even this level of detail is too concrete for a use case.

Whether to reference UI elements (screen/page names, buttons etc.): This particular piece of religious touch paper is the catalyst for much of the disagreement about the purpose of use cases; so I'll return to this subject in my next article.

With some style elements, most people will agree wholeheartedly that there's a right and a wrong way to write them. Just no one can really agree on what's right and what's wrong. Check back in a couple of weeks... ®

head shot of Matt Stephens smiling Matt Stephens is the co-author, with Doug Rosenberg, of Use Case Driven Object Modeling with UML: Theory and Practice.

Top 5 reasons to deploy VMware with Tegile

More from The Register

next story
Preview redux: Microsoft ships new Windows 10 build with 7,000 changes
Latest bleeding-edge bits borrow Action Center from Windows Phone
Google opens Inbox – email for people too thick to handle email
Print this article out and give it to someone tech-y if you get stuck
Microsoft promises Windows 10 will mean two-factor auth for all
Sneak peek at security features Redmond's baking into new OS
UNIX greybeards threaten Debian fork over systemd plan
'Veteran Unix Admins' fear desktop emphasis is betraying open source
Google+ goes TITSUP. But WHO knew? How long? Anyone ... Hello ...
Wobbly Gmail, Contacts, Calendar on the other hand ...
DEATH by PowerPoint: Microsoft warns of 0-day attack hidden in slides
Might put out patch in update, might chuck it out sooner
Redmond top man Satya Nadella: 'Microsoft LOVES Linux'
Open-source 'love' fairly runneth over at cloud event
prev story

Whitepapers

Choosing cloud Backup services
Demystify how you can address your data protection needs in your small- to medium-sized business and select the best online backup service to meet your needs.
Forging a new future with identity relationship management
Learn about ForgeRock's next generation IRM platform and how it is designed to empower CEOS's and enterprises to engage with consumers.
Security for virtualized datacentres
Legacy security solutions are inefficient due to the architectural differences between physical and virtual environments.
Reg Reader Research: SaaS based Email and Office Productivity Tools
Read this Reg reader report which provides advice and guidance for SMBs towards the use of SaaS based email and Office productivity tools.
Storage capacity and performance optimization at Mizuno USA
Mizuno USA turn to Tegile storage technology to solve both their SAN and backup issues.